Не работает загрузка ядра un-def 5.15.5-alt1 на платах Raspbery Pi 4B и Raspbery Pi 3B Plus при помощи u-boot с использование extlinux.conf В последовательной консоли для Raspbery Pi 4B ошибка такая: U-Boot 2021.10 (Oct 06 2021 - 12:02:44 +0000) DRAM: 3.9 GiB RPI 4 Model B (0xc03111) MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 777 bytes read in 25 ms (30.3 KiB/s) ALTLinux Boot Options 1: linux 2: 5.10.82-std-def-alt1 3: 5.15.5-un-def-alt1 Enter choice: 1: linux Retrieving file: /boot/initrd.img 11463458 bytes read in 504 ms (21.7 MiB/s) Retrieving file: /boot/vmlinuz 36788736 bytes read in 1559 ms (22.5 MiB/s) append: root=UUID=e0ef556a-de24-4773-a2e0-1b47662897d7 ro usbcore.autosuspend=-1 console=tty1 ttyS0,115200 Retrieving file: /boot/dtb/bcm2711-rpi-4-b.dtb 26401 bytes read in 214 ms (120.1 KiB/s) Moving Image from 0x80000 to 0x200000, end=2680000 ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree Ядро std-def грузится успешно. Ядро un-def 5.14.21 грузится успешно. Ядро mp 5.15.4 грузится успешно. Если fdtdir из extlinux.conf убрать, то ядро un-def грузится успешно. Проблема только на aarch64, на armh загружается.
(Ответ для Антон Мидюков на комментарий #0) > Если fdtdir из extlinux.conf убрать, то ядро un-def грузится успешно. А что настравает этот параметр? То есть имеется ли предположение, что именно не так в этом ядре?
(Ответ для Anton V. Boyarshinov на комментарий #1) > (Ответ для Антон Мидюков на комментарий #0) > > > Если fdtdir из extlinux.conf убрать, то ядро un-def грузится успешно. > > А что настравает этот параметр? То есть имеется ли предположение, что именно > не так в этом ядре? fdtdir указывает каталог, в котором u-boot ищет dtb (devicetree). Если не указать, то используется dtb загруженный в память raspberry pi-шным firmware до начала загрузки u-boot. Проверил ядро 5.15.6-alt1, не починилось.
(Ответ для Антон Мидюков на комментарий #2) > fdtdir указывает каталог, в котором u-boot ищет dtb (devicetree). А какой каталог указан в этом параметре (и с которым, соответственно, не работает)? > Если не указать, то используется dtb загруженный в память raspberry pi-шным > firmware до начала загрузки u-boot. > > Проверил ядро 5.15.6-alt1, не починилось.
(Ответ для Anton V. Boyarshinov на комментарий #3) > (Ответ для Антон Мидюков на комментарий #2) > > > fdtdir указывает каталог, в котором u-boot ищет dtb (devicetree). > > А какой каталог указан в этом параметре (и с которым, соответственно, не > работает)? dtb нормально загружается, ошибка происходит сразу после при переносе в заданную область памяти: Retrieving file: /boot/dtb/bcm2711-rpi-4-b.dtb 26401 bytes read in 214 ms (120.1 KiB/s) Moving Image from 0x80000 to 0x200000, end=2680000 ERROR: Did not find a cmdline Flattened Device Tree А ядра un-def 5.15.4-alt1 нет? Собрать можно? mp 5.15.4 то работает. Надо бы понять, дело в версии или в том, как собрано.
(Ответ для Антон Мидюков на комментарий #4) > (Ответ для Anton V. Boyarshinov на комментарий #3) > > (Ответ для Антон Мидюков на комментарий #2) > > > > > fdtdir указывает каталог, в котором u-boot ищет dtb (devicetree). > > > > А какой каталог указан в этом параметре (и с которым, соответственно, не > > работает)? > > dtb нормально загружается, ошибка происходит сразу после при переносе в > заданную область памяти: > Retrieving file: /boot/dtb/bcm2711-rpi-4-b.dtb > 26401 bytes read in 214 ms (120.1 KiB/s) > Moving Image from 0x80000 to 0x200000, end=2680000 > ERROR: Did not find a cmdline Flattened Device Tree > > А ядра un-def 5.15.4-alt1 нет? Собрать можно? mp 5.15.4 то работает. Надо бы > понять, дело в версии или в том, как собрано. Я бы лучше посмотрел на 5.15.5-mp, так как движение вперёд более естественно.
На arm и aarch64 используется один и тот же файл dts. Изменений между 5.15.4 и 5.15.5 в нём не было
(Ответ для Anton V. Boyarshinov на комментарий #6) > На arm и aarch64 используется один и тот же файл dts. > Изменений между 5.15.4 и 5.15.5 в нём не было dtb ни при чём. Я пробовал разные. Результат один и тот же. Прошу ядро в p10 не пускать, пока проблему не устраним.
(Ответ для Антон Мидюков на комментарий #0) >[...] >Moving Image from 0x80000 to 0x200000, end=2680000 Для ядра un-def end=2680000, а это больше, чем переменная u-boot fdt_addr_r=0x02600000. Если задать fdt_addr_r=0x02690000, то загрузка проходит успешно. Могу лишь предположить, что адрес зависит от размера ядра. Ядро un-def стало больше ещё на 2,7 MiB (35,1 MiB против 32,4 MiB), в результате адресное пространство для fdt ядра вышло за пределы дефолтного адресного пространства u-boot. К сравнению ядро mp 27,5 MiB. Возникает закономерный вопрос, почему ядро un-def такое большое, при условии, что очень многое вынесено в модули, в отличии от того же ядра mp?
(Ответ для Антон Мидюков на комментарий #8) > (Ответ для Антон Мидюков на комментарий #0) > >[...] > >Moving Image from 0x80000 to 0x200000, end=2680000 > > Для ядра un-def end=2680000, а это больше, чем переменная u-boot > fdt_addr_r=0x02600000. > Если задать fdt_addr_r=0x02690000, то загрузка проходит успешно. > Могу лишь предположить, что адрес зависит от размера ядра. Ядро un-def стало > больше ещё на 2,7 MiB (35,1 MiB против 32,4 MiB), в результате адресное > пространство для fdt ядра вышло за пределы дефолтного адресного пространства > u-boot. К сравнению ядро mp 27,5 MiB. Спасибо, это важная информация, которая, я надеюсь, поможет решить проблему! > Возникает закономерный вопрос, почему ядро un-def такое большое, при > условии, что очень многое вынесено в модули, в отличии от того же ядра mp? Сложно сказать. Там вообще очень много чего включено, чего в mp, насколько я понимаю, не включено вообще. Кроме того, некоторые опции конфигурации влияют на размер генерируемого кода сами по себе (и несколько раз по несколько процентов может получиться немало). Но теперь по крайней мере ясно куда копать.
(Ответ для Anton V. Boyarshinov на комментарий #9) > (Ответ для Антон Мидюков на комментарий #8) > > (Ответ для Антон Мидюков на комментарий #0) > > >[...] > > >Moving Image from 0x80000 to 0x200000, end=2680000 > > > > Для ядра un-def end=2680000, а это больше, чем переменная u-boot > > fdt_addr_r=0x02600000. > > Если задать fdt_addr_r=0x02690000, то загрузка проходит успешно. > > Могу лишь предположить, что адрес зависит от размера ядра. Ядро un-def стало > > больше ещё на 2,7 MiB (35,1 MiB против 32,4 MiB), в результате адресное > > пространство для fdt ядра вышло за пределы дефолтного адресного пространства > > u-boot. К сравнению ядро mp 27,5 MiB. > > Спасибо, это важная информация, которая, я надеюсь, поможет решить проблему! > > > Возникает закономерный вопрос, почему ядро un-def такое большое, при > > условии, что очень многое вынесено в модули, в отличии от того же ядра mp? > Сложно сказать. Там вообще очень много чего включено, чего в mp, насколько я > понимаю, не включено вообще. > Кроме того, некоторые опции конфигурации влияют на размер генерируемого кода > сами по себе (и несколько раз по несколько процентов может получиться > немало). Но теперь по крайней мере ясно куда копать. Очень похоже, что это toolchain. Одно и то же ядро получается при сборке на Сизифе на несколько мегабайт больше, чем на p10. Попробуйте, пожалуйста, ядро из задания #291610, это 5.15 собранное на p10
(Ответ для Anton V. Boyarshinov на комментарий #10) > Попробуйте, пожалуйста, ядро из задания #291610, это 5.15 собранное на p10 Загрузилось. Адрес end=2400000.
А давайте уже 5.15 в p10?
(Ответ для Sergey V Turchin на комментарий #12) > А давайте уже 5.15 в p10? Да! Я, совственно, приостановил процесс его пропихивания в p10 именно из-за этой ошибки, которая, оказывается, не проявляется в p10
Проблему решили отключением конфигов ядра: CONFIG_ARCH_EXYNOS CONFIG_ARCH_MEDIATEK https://git.altlinux.org/gears/k/kernel-image-un-def.git?p=kernel-image-un-def.git;a=commit;h=64d550263c6b6ddd589a4b4f02ba75c46ff69337
Проблема на ядрах un-def опять. Проверил 6.0.3-alt1 и 6.0.5-alt1. Адреса для dtb сечас такие: 6.0.3-alt1: Moving Image from 0x80000 to 0x200000, end=2610000 6.0.5-alt1: Moving Image from 0x80000 to 0x200000, end=2640000 Т.е. конечные адреса опять больше установленного в u-boot fdt_addr_r=0x02600000. У ядра 5.19.16-alt2 был адрес 25d0000. Размеры ядра в байтах: 5.19.16-alt2 - 36149760 6.0.3-alt1 - 36422144 6.0.5-alt1 - 36618752 Т.е. адрес растёт пропорционально росту размера ядра. Вопрос состоит в том, есть ли другой способ уменьшить адрес, кроме как отключив чего-нибудь в ядре. Также интересно проверить каким получится ядро, собранное для p10. Ядро 5.15 получалось более компактным.
(In reply to Антон Мидюков from comment #8) > Для ядра un-def end=2680000, а это больше, чем переменная u-boot > fdt_addr_r=0x02600000. > Если задать fdt_addr_r=0x02690000, то загрузка проходит успешно. А почему нельзя увеличить этот параметр?
(Ответ для Vitaly Chikunov на комментарий #16) > (In reply to Антон Мидюков from comment #8) > > Для ядра un-def end=2680000, а это больше, чем переменная u-boot > > fdt_addr_r=0x02600000. > > Если задать fdt_addr_r=0x02690000, то загрузка проходит успешно. > > А почему нельзя увеличить этот параметр? Переадресую вопрос мантейнеру пакета u-boot-rpi3 Сергею Большакову. Но проблема в любом случае останется в ранее выпущенных образах, так как у нас не происходит обновление u-boot при обновлении системы.
Предположу, что самое простое решение - отключить на arm CONFIG_DEBUG_INFO_BTF=y Но будет жаль, что это будет откат в технологиях.
Для будущих поколений: попробовали сжать ядро просто `gzip -9`, как в Федоре, результат -- не грузится с "kernel_comp_addr_r or kernel_comp_size is not provided!"
Влияние отключения CONFIG_DEBUG_INFO_BTF (до и после): -rw-r--r-- 1 root root 36618752 Oct 26 16:14 /boot/vmlinuz-6.0.5-un-def-alt1 -rw-r--r-- 1 root root 31506944 Oct 28 21:45 /boot/vmlinuz-6.0.5-un-def-alt2
(Ответ для Vitaly Chikunov на комментарий #20) > Влияние отключения CONFIG_DEBUG_INFO_BTF (до и после): > -rw-r--r-- 1 root root 36618752 Oct 26 16:14 > /boot/vmlinuz-6.0.5-un-def-alt1 > -rw-r--r-- 1 root root 31506944 Oct 28 21:45 > /boot/vmlinuz-6.0.5-un-def-alt2 Проблему это решило. Исправлено в 6.0.6-alt1 * Sat Oct 29 2022 Kernel Bot <kernelbot at altlinux.org> 1:6.0.6-alt1 - v6.0.6 (2022-10-29). - config: Disable DEBUG_INFO_BTF on aarch64.
