* Re: [devel-distro] Политика упаковки devicetree в ядрах
@ 2021-10-04 13:22 ` Антон Мидюков
0 siblings, 0 replies; 2+ messages in thread
From: Антон Мидюков @ 2021-10-04 13:22 UTC (permalink / raw)
To: Sergey Bolshakov; +Cc: Distributions development
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>
^ permalink raw reply [flat|nested] 2+ messages in thread