41479 2021-12-01 23:35:00 +0300 Не может загрузить ядра un-def 5.15.5, 5.15.6 на Raspberry Pi 3B Plus и Raspberry Pi 4B 2022-11-07 06:18:34 +0300 1 1 4 Development Sisyphus kernel-image-un-def unstable aarch64 Linux CLOSED FIXED P5 normal --- 33000 1 antohami vt aen asheplyakov iv jqt4 kernelbot placeholder sbolshakov vt qa-sisyphus oldest_to_newest 205562 0 antohami 2021-12-01 23:35:00 +0300 Не работает загрузка ядра 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 загружается. 205586 1 boyarsh 2021-12-02 12:51:05 +0300 (Ответ для Антон Мидюков на комментарий #0) > Если fdtdir из extlinux.conf убрать, то ядро un-def грузится успешно. А что настравает этот параметр? То есть имеется ли предположение, что именно не так в этом ядре? 205589 2 antohami 2021-12-02 13:15:02 +0300 (Ответ для 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, не починилось. 205593 3 boyarsh 2021-12-02 13:49:07 +0300 (Ответ для Антон Мидюков на комментарий #2) > fdtdir указывает каталог, в котором u-boot ищет dtb (devicetree). А какой каталог указан в этом параметре (и с которым, соответственно, не работает)? > Если не указать, то используется dtb загруженный в память raspberry pi-шным > firmware до начала загрузки u-boot. > > Проверил ядро 5.15.6-alt1, не починилось. 205595 4 antohami 2021-12-02 13:54:26 +0300 (Ответ для 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 то работает. Надо бы понять, дело в версии или в том, как собрано. 205612 5 boyarsh 2021-12-02 16:57:22 +0300 (Ответ для Антон Мидюков на комментарий #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, так как движение вперёд более естественно. 205615 6 boyarsh 2021-12-02 17:04:33 +0300 На arm и aarch64 используется один и тот же файл dts. Изменений между 5.15.4 и 5.15.5 в нём не было 205871 7 antohami 2021-12-08 16:33:23 +0300 (Ответ для Anton V. Boyarshinov на комментарий #6) > На arm и aarch64 используется один и тот же файл dts. > Изменений между 5.15.4 и 5.15.5 в нём не было dtb ни при чём. Я пробовал разные. Результат один и тот же. Прошу ядро в p10 не пускать, пока проблему не устраним. 206088 8 antohami 2021-12-16 11:25:15 +0300 (Ответ для Антон Мидюков на комментарий #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? 206095 9 boyarsh 2021-12-16 12:39:59 +0300 (Ответ для Антон Мидюков на комментарий #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, насколько я понимаю, не включено вообще. Кроме того, некоторые опции конфигурации влияют на размер генерируемого кода сами по себе (и несколько раз по несколько процентов может получиться немало). Но теперь по крайней мере ясно куда копать. 206227 10 boyarsh 2021-12-20 15:37:09 +0300 (Ответ для 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 206228 11 antohami 2021-12-20 15:57:19 +0300 (Ответ для Anton V. Boyarshinov на комментарий #10) > Попробуйте, пожалуйста, ядро из задания #291610, это 5.15 собранное на p10 Загрузилось. Адрес end=2400000. 206229 12 zerg 2021-12-20 18:05:27 +0300 А давайте уже 5.15 в p10? 206263 13 boyarsh 2021-12-21 15:43:34 +0300 (Ответ для Sergey V Turchin на комментарий #12) > А давайте уже 5.15 в p10? Да! Я, совственно, приостановил процесс его пропихивания в p10 именно из-за этой ошибки, которая, оказывается, не проявляется в p10 207530 14 antohami 2022-02-07 18:55:18 +0300 Проблему решили отключением конфигов ядра: 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 216583 15 antohami 2022-10-27 17:58:53 +0300 Проблема на ядрах 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 получалось более компактным. 216584 16 vt 2022-10-27 18:30:29 +0300 (In reply to Антон Мидюков from comment #8) > Для ядра un-def end=2680000, а это больше, чем переменная u-boot > fdt_addr_r=0x02600000. > Если задать fdt_addr_r=0x02690000, то загрузка проходит успешно. А почему нельзя увеличить этот параметр? 216585 17 antohami 2022-10-27 18:43:14 +0300 (Ответ для 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 при обновлении системы. 216587 18 vt 2022-10-27 19:35:54 +0300 Предположу, что самое простое решение - отключить на arm CONFIG_DEBUG_INFO_BTF=y Но будет жаль, что это будет откат в технологиях. 216591 19 vt 2022-10-27 23:11:47 +0300 Для будущих поколений: попробовали сжать ядро просто `gzip -9`, как в Федоре, результат -- не грузится с "kernel_comp_addr_r or kernel_comp_size is not provided!" 216671 20 vt 2022-10-29 00:22:51 +0300 Влияние отключения 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 216972 21 antohami 2022-11-07 06:18:34 +0300 (Ответ для 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.