LINUX.ORG.RU
ФорумAdmin

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

 , ,


0

1

в общем, есть проблема, есть buildrootв котором собирается ядро 4.14.67, ядро собирается с таким defconfig

CONFIG_POSIX_MQUEUE=y
CONFIG_EXT2_FS=m
CONFIG_EXT3_FS=m
CONFIG_SERIAL_MXS_AUART=m
CONFIG_SERIAL_MCTRL_GPIO=m
CONFIG_SND_MXS_SOC=m
CONFIG_SND_SOC_MXS_SGTL5000=m
CONFIG_SND_SOC_SGTL5000=m
CONFIG_CONFIGFS_FS=y
CONFIG_DEBUG_INFO=n
CONFIG_DEBUG_KERNEL=n
CONFIG_USB_OTG=y
CONFIG_USB_OTG_FSM=y
CONFIG_USB_ACM=y
CONFIG_U_SERIAL_CONSOLE=y
CONFIG_USB_G_SERIAL=m
CONFIG_USB_U_ETHER=m
CONFIG_USB_ETH=m
CONFIG_RTC_DRV_DS1307=y
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_NET_IPIP=m
CONFIG_NET_IP_TUNNEL=m
CONFIG_NET_UDP_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_L2TP=m
CONFIG_TUN=m
CONFIG_NF_CONNTRACK=y
CONFIG_NF_NAT_REDIRECT=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NF_CONNTRACK_IPV4=y
NF_LOG_IPV4=y
NF_REJECT_IPV4=y
CONFIG_NF_NAT_IPV4=y
CONFIG_NF_NAT_MASQUERADE_IPV4=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_RAW=y
CONFIG_HZ_250=y
CONFIG_HZ=250
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
встала задача, поменять ядро, собираю из билдрута с этим дефконфигом, при загрузке только
Starting kernel ...

data abort
pc : [<42000134>]          lr : [<28c82330>]
sp : 424cf570  ip : 900a40a6     fp : d6e26852
r10: 2687e604  r9 : c0dabbc0     r8 : 47b1b000
r7 : 000009e3  r6 : 424ce540     r5 : 420000a0  r4 : 40008000
r3 : 21162500  r2 : 29a2d619     r1 : 03b63138  r0 : e12c87c4
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...
никаких отладочных сообщений, если бы какие-то сообщения были, но нет вообще ничего. В чем может быть причина?

★★★

Ответ на: комментарий от izzholtik

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

IvanR ★★★ ()
Ответ на: комментарий от Dumppper001

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

izzholtik ★★ ()
Ответ на: комментарий от izzholtik

мне билдрут достался от предшественника, там есть 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
...
смущет одна вещь, в defconfig есть строки:
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
еще после того, как заменил ядро, ругался на файл dts, я заменил файл таким образом: скомпилировал dtc под arm, загрузил его на железку и выполнил команду, не помню уже какую, в общем получил dts файл из /proc/device-tree и подсунул этот файл ядру, вроде с варнингами, но dtb получил.

IvanR ★★★ ()
Ответ на: комментарий от IvanR

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

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

dtb получил

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

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

izzholtik ★★ ()
Последнее исправление: izzholtik (всего исправлений: 3)
Ответ на: комментарий от izzholtik

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

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

IvanR ★★★ ()
Ответ на: комментарий от izzholtik

нашел в описании 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 найти файл и строку в которой происходит сбой?

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

IvanR ★★★ ()
Последнее исправление: IvanR (всего исправлений: 2)
Ответ на: комментарий от izzholtik

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

IvanR ★★★ ()