Bug 41479 - Не может загрузить ядра un-def 5.15.5, 5.15.6 на Raspberry Pi 3B Plus и Raspberry Pi 4B
Summary: Не может загрузить ядра un-def 5.15.5, 5.15.6 на Raspberry Pi 3B Plus и Raspb...
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel-image-un-def (show other bugs)
Version: unstable
Hardware: aarch64 Linux
: P5 normal
Assignee: Vitaly Chikunov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 33000
  Show dependency tree
 
Reported: 2021-12-01 23:35 MSK by Антон Мидюков
Modified: 2022-11-07 06:18 MSK (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Антон Мидюков 2021-12-01 23:35:00 MSK
Не работает загрузка ядра 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 загружается.
Comment 1 Anton V. Boyarshinov 2021-12-02 12:51:05 MSK
(Ответ для Антон Мидюков на комментарий #0)

> Если fdtdir из extlinux.conf убрать, то ядро un-def грузится успешно.

А что настравает этот параметр? То есть имеется ли предположение, что именно не так в этом ядре?
Comment 2 Антон Мидюков 2021-12-02 13:15:02 MSK
(Ответ для 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, не починилось.
Comment 3 Anton V. Boyarshinov 2021-12-02 13:49:07 MSK
(Ответ для Антон Мидюков на комментарий #2)

> fdtdir указывает каталог, в котором u-boot ищет dtb (devicetree).

А какой каталог указан в этом параметре (и с которым, соответственно, не работает)?

> Если не указать, то используется dtb загруженный в память raspberry pi-шным
> firmware до начала загрузки u-boot.
> 
> Проверил ядро 5.15.6-alt1, не починилось.
Comment 4 Антон Мидюков 2021-12-02 13:54:26 MSK
(Ответ для 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 то работает. Надо бы понять, дело в версии или в том, как собрано.
Comment 5 Anton V. Boyarshinov 2021-12-02 16:57:22 MSK
(Ответ для Антон Мидюков на комментарий #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, так как движение вперёд более естественно.
Comment 6 Anton V. Boyarshinov 2021-12-02 17:04:33 MSK
На arm и aarch64 используется один и тот же файл dts.
Изменений между 5.15.4 и 5.15.5 в нём не было
Comment 7 Антон Мидюков 2021-12-08 16:33:23 MSK
(Ответ для Anton V. Boyarshinov на комментарий #6)
> На arm и aarch64 используется один и тот же файл dts.
> Изменений между 5.15.4 и 5.15.5 в нём не было

dtb ни при чём. Я пробовал разные. Результат один и тот же.

Прошу ядро в p10 не пускать, пока проблему не устраним.
Comment 8 Антон Мидюков 2021-12-16 11:25:15 MSK
(Ответ для Антон Мидюков на комментарий #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?
Comment 9 Anton V. Boyarshinov 2021-12-16 12:39:59 MSK
(Ответ для Антон Мидюков на комментарий #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, насколько я понимаю, не включено вообще.
Кроме того, некоторые опции конфигурации влияют на размер генерируемого кода сами по себе (и несколько раз по несколько процентов может получиться немало). Но теперь по крайней мере ясно куда копать.
Comment 10 Anton V. Boyarshinov 2021-12-20 15:37:09 MSK
(Ответ для 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
Comment 11 Антон Мидюков 2021-12-20 15:57:19 MSK
(Ответ для Anton V. Boyarshinov на комментарий #10)
> Попробуйте, пожалуйста, ядро из задания #291610, это 5.15 собранное на p10

Загрузилось. Адрес end=2400000.
Comment 12 Sergey V Turchin 2021-12-20 18:05:27 MSK
А давайте уже 5.15 в p10?
Comment 13 Anton V. Boyarshinov 2021-12-21 15:43:34 MSK
(Ответ для Sergey V Turchin на комментарий #12)
> А давайте уже 5.15 в p10?

Да! Я, совственно, приостановил процесс его пропихивания в p10 именно из-за этой ошибки, которая, оказывается, не проявляется в p10
Comment 14 Антон Мидюков 2022-02-07 18:55:18 MSK
Проблему решили отключением конфигов ядра:
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
Comment 15 Антон Мидюков 2022-10-27 17:58:53 MSK
Проблема на ядрах 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 получалось более компактным.
Comment 16 Vitaly Chikunov 2022-10-27 18:30:29 MSK
(In reply to Антон Мидюков from comment #8)
> Для ядра un-def end=2680000, а это больше, чем переменная u-boot
> fdt_addr_r=0x02600000.
> Если задать fdt_addr_r=0x02690000, то загрузка проходит успешно.

А почему нельзя увеличить этот параметр?
Comment 17 Антон Мидюков 2022-10-27 18:43:14 MSK
(Ответ для 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 при обновлении системы.
Comment 18 Vitaly Chikunov 2022-10-27 19:35:54 MSK
Предположу, что самое простое решение - отключить на arm
  CONFIG_DEBUG_INFO_BTF=y
Но будет жаль, что это будет откат в технологиях.
Comment 19 Vitaly Chikunov 2022-10-27 23:11:47 MSK
Для будущих поколений: попробовали сжать ядро просто `gzip -9`, как в Федоре, результат -- не грузится с "kernel_comp_addr_r or kernel_comp_size is not provided!"
Comment 20 Vitaly Chikunov 2022-10-29 00:22:51 MSK
Влияние отключения 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
Comment 21 Антон Мидюков 2022-11-07 06:18:34 MSK
(Ответ для 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.