From: "Антон Мидюков" <midyukov-anton@ya.ru> To: Sergey Bolshakov <sbolshakov@altlinux.ru> Cc: Distributions development <devel-distro@lists.altlinux.org> Subject: Re: [devel-distro] Политика упаковки devicetree в ядрах Date: Mon, 4 Oct 2021 20:22:49 +0700 Message-ID: <c4f0562e-c671-fa43-96a0-8fa78b04d34f@ya.ru> (raw) In-Reply-To: <m3fsthrvhm.fsf@altlinux.ru> 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>
prev parent reply other threads:[~2021-10-04 13:22 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-04 6:42 Антон Мидюков 2021-10-04 13:22 ` Антон Мидюков [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=c4f0562e-c671-fa43-96a0-8fa78b04d34f@ya.ru \ --to=midyukov-anton@ya.ru \ --cc=devel-distro@lists.altlinux.org \ --cc=sbolshakov@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Distributions development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-distro/0 devel-distro/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-distro devel-distro/ http://lore.altlinux.org/devel-distro \ devel-distro@lists.altlinux.org devel-distro@lists.altlinux.ru devel-distro@lists.altlinux.com public-inbox-index devel-distro Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-distro AGPL code for this site: git clone https://public-inbox.org/public-inbox.git