[devel-distro] Политика упаковки devicetree в ядрах

[Антон Мидюков]

04.10.2021 16:26, Sergey Bolshakov пишет:
>>>>>> "Антон" == Антон Мидюков <midyukov-anton �� ya.ru> writes:
> 
>  > Здравствуйте, коллеги
>  > Хотел бы обсудить два вопроса упаковки devicetree в наших ядрах
> 
>  > 1. devicetree у нас располагаются в одном каталоге /lib/devicetree/<ядро>/
>  > без распределения по подкаталогам на каждого вендора. В других дистрибутивах
>  > (например, Armbian) devicetree распределены по вендорам (allwinner/ nvidia/ rockchip/
>  > и т.д.).
> 
> Это верно только для arm64, в arm всё на одном уровне.
> У нас так, как есть, по историческим причинам -- цель dtbs_install
> в ядре, на которую можно было бы рассчитывать в качестве стандартной,
> появилась сравнительно недавно.
> 
>  > Хотелось бы иметь совместимость со сторонними u-boot, так как это позволит,
>  > не записывать u-boot, а использовать уже имеющийся в eMMC или SPI flash.
>  > Причина такого желания состоит в том, что пользователи могут желать сохранить
>  > в eMMC Armbian или другой дистрибутив.
>  > Замена штатного u-boot на u-boot Альта в свою очередь приведёт к тому, что не загрузятся
>  > другие дистрибутивы, использующие распределение dtb по вендорам.
> 
>  > Для достижения совместимости с другими дистрибутивами достаточно создать
>  > симлинки с именами вендоров на текущий каталог в каталоге /lib/devicetree/<ядро>/
>  > ln -s . <имя_вендора>
> 
>  > Подойдёт ли такая реализация? Если да, то как бы её лучше реализовать?
> 
> Я не вижжу проблем в такой реализации, как впрочем и не вижу в ней нужды --
> разве что с целью через год-два, когда смысла беспокоиться о старых ядрах
> поубавится, выровнять поведение наших u-boot с майнлайном.

Нужду я описал. На плате u-boot желает вендор/имя.dtb, а заменить по каким-то причинам нельзя,
сложно или не охота. Если это несложно реализовать, то давайте сделаем. Это востребовано
пользователями.

> 
>  > 2. Другая проблема - невозможность использования зашифрованного корня при выделенном
>  > незашифрованном разделе /boot. Для того, чтобы это было возможно, необходимо
>  > наличие devicetree в /boot.
>  > Предлагаю начать паковать devicetree в /boot/devicetree/<ядро>/, и создавать для
>  > обратной совместимости симлинк:
>  > ln -s /boot/devicetree/<ядро> /lib/devicetree/<ядро>
> 
>  > devicetree не сильно много места занимают, так что /boot не разбухнет слишком сильно:
>  > du -h lib/devicetree/5.10.70-std-def-alt1
>  > 8,7M	lib/devicetree/5.10.70-std-def-alt1
> 
>  > du -h lib/devicetree/5.14.9-un-def-alt1/
>  > 14M	lib/devicetree/5.14.9-un-def-alt1/
> 
>  > Но тенденция к разрастанию, конечно, заметная.
> 
> Я думаю, что энтузиасту шифрования всего на свете сорок вёрст не крюк,
> предоставим ему возможность самому сделать отдельный /boot,
> положить туда нужный dtb и отстрелить себе^W^W радоваться творению
> рук своих.
> 

Проблема то шире, чем я подумал сначала. У нас сейчас вообще не поддерживается загрузка с отдельного раздела /boot
при загрузке при помощи extlinux.conf.
Мало перетащить devicetree в /boot, нужно ещё исправить генерацию extlinux.conf в installkernel, заменить
абсолютные пути на относительные:
-	kernel /boot/vmlinuz-%s
-	initrd /boot/initrd-%s.img
-	fdtdir /lib/devicetree/%s
+	kernel ../vmlinuz-%s
+	initrd ../initrd-%s.img
+	fdtdir ../devicetree/%s

А отдельный раздел /boot нужен также и для расположения корня на lvm.

-- 
С уважением, Антон Мидюков <antohami �� altlinux.org>