embedded linux загрузка из u-boot

А какой конкретно embedded linux?

Билдрут же

buildroot

По проблеме хз, не сталкивался, но описание явно недостаточное.
Рабочее ядро собирается под билдрутом? Какой оно версии? Какой версии новое ядро? Как менял?

А где он стоит? На чем?

Переустанавливал…

вот на такой плате: http://zao-zeo.ru/dokuwiki/doku.php/tion-pro28

ну я перепрошиваю flash, все файлы загружаются, пергружаю железку и получаю даже не кернел паник, а вообще непонятно что.

Это-то понятно. Как сборочную систему на новое ядро натравил?

iMX287

Вроде особых проблем с ним быть не должно. .

Как как просто снес старое наверное и поставил новое

и старое и новое собирается в билдрут, старое ядро 4.14.67, новое 5.10.48, buildroot 2018.02.4, ядро собирается нормально

отредактировал несколько мейк файлов, изначально собираться не хотело, так как в билдрут поддерживаются ядра только версий, выпущенных ранее, чем сам билдрут.

Там же кастомная репа с патченым ядром в дефконфиге указана, ты его мержил или просто подкинул чистое?

Может потому что протухшую версию ядрышка меняют на новую

Сначала был патч мержнутый скорее всего а потом чистое вроде судя по обрывам логов надо менять патч на патч

Дефконфиг не редактировал с прошлого раза?

пипец ты непонятно пишешь.
Я вот про это, если что. Просто переключить в менюконфиге ядро на более новое не прокатит, надо выкачивать сабж и пытаться мержить с ванильным целевой версии.

мне билдрут достался от предшественника, там есть defconfig для ядра, который я показал в первом посте, во время сборки вот такие сообщения

Using /home/max/work/buildroot/buildroot-2018.02.4/output/build/linux-5.10.48/.config as base
Merging new_kernel_defconfig
Value of CONFIG_POSIX_MQUEUE is redefined by fragment tm4/soyuz_new_kernel_defconfig:
Previous value: # CONFIG_POSIX_MQUEUE is not set
New value: CONFIG_POSIX_MQUEUE=y

Value of CONFIG_EXT2_FS is redefined by fragment tm4/soyuz_new_kernel_defconfig:
Previous value: # CONFIG_EXT2_FS is not set
New value: CONFIG_EXT2_FS=m

Value of CONFIG_EXT3_FS is redefined by fragment tm4/soyuz_new_kernel_defconfig:
Previous value: # CONFIG_EXT3_FS is not set
New value: CONFIG_EXT3_FS=m
...

CONFIG_HAVE_GCC_PLUGINS=n
CONFIG_GCC_PLUGINS=n

*
* Restart config...
*
*
* GCC plugins
*
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) n
*
* Memory initialization
*
Initialize kernel stack variables at function entry
> 1. no automatic initialization (weakest) (INIT_STACK_NONE)
choice[1]: 1
Enable heap memory zeroing on allocation by default (INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) [N/y/?] n

при сборке появляются такие вопросы

Типичная ситуация, когда в конфиге не прописаны какие-то новые параметры.

dtb получил

вот тут непонятно, ты от старого ядра dtb сдампил?

Крч, у тебя всё грязное, работать с таким - занятие очень неблагодарное. Хз почему оно не работает в этом конкретном случае, но в целом ничего удивительного. Попробуй какнить более системно подойти, начиная с поиска документации от предшественника. Если нет - глянь, что с поддержкой твоего проца в майнлайне и много ли вендор в своей версии напатчил, может, выйдет взять ванильное и чутка обновить вендорский дефконфиг с оверлеями.

вот тут непонятно, ты от старого ядра dtb сдампил?

да, от старого, я думал, что эта информация не меняется от ядра к ядру, разве она меняется? Там патчи касались только uart, не думаю, что это влияет на работу, документации нет.

нашел в описании uboot

# fatload usb <dev>[:partition] <loadAddress> <bootfilename>

This command reads file bootfilename from device dev, partition partition of the USB flash disk into
the RAM address loadAddress.

в uboot есть команда printenv, вот что она показывает:

loadaddr=0x42000000
...
loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}

то есть, можно стчитать, что ядро загружено в ram по адресу 0x42000000 и регистр IP, в случае arm PC показывает на смещение в ядре относительно адреса 0x42000000, значит нам нужно взять адрес в PC и вычесть из него адрес 0x42000000, тогда мы получим адрес относительно начала сегмента кода в ядре, я правильно понял? тогда мы можем с помощью addr2line найти файл и строку в которой происходит сбой?

хотя наверно не получится, оно грузится по этому адресу с учетом заголовков

в общем, u-boot считывал в ram меньше, чем размер ядра, я что-то подобное и предполагал, очень странно было, что ядро крушилось без единого вывода в консоль.