From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1633353771; bh=O3OSXb7nValQm+DPvRHTTvoyURBH7SP1+yLcxN3GS1s=; h=In-Reply-To:From:To:Subject:Cc:References:Date:Message-ID; b=MgfhIdgKA9+CfqsHnFQ3MMtLXpwDR/tDFfYTXsP/QD+wtLrI54sV6mj0wFkf0oXcU R0fE+y/mtNNdia9LtCXAp2+EvaNmbZq2nmd9EsgGE3YHQ2i8kTg/eqW+OVM36Pafwb JEVnXwt/xD47OD6iI0KNcWou70KyNu2xvIyHNkOs= Authentication-Results: sas1-df7c155f48c6.qloud-c.yandex.net; dkim=pass header.i=@ya.ru Message-ID: Date: Mon, 4 Oct 2021 20:22:49 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Content-Language: ru To: Sergey Bolshakov References: From: =?UTF-8?B?0JDQvdGC0L7QvSDQnNC40LTRjtC60L7Qsg==?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Distributions development Subject: Re: [devel-distro] =?utf-8?b?0J/QvtC70LjRgtC40LrQsCDRg9C/0LDQutC+0LI=?= =?utf-8?b?0LrQuCBkZXZpY2V0cmVlINCyINGP0LTRgNCw0YU=?= X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 13:22:55 -0000 Archived-At: List-Archive: 04.10.2021 16:26, Sergey Bolshakov пишет: >>>>>> "Антон" == Антон Мидюков 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. -- С уважением, Антон Мидюков