(Ответ для Антон Мидюков на комментарий #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.