From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id kAHTLH4YBWMMPwEAbAwnHQ (envelope-from ) for ; Tue, 23 Aug 2022 20:12:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id SKm5LH4YBWM2ewAAauVa8A (envelope-from ) for ; Tue, 23 Aug 2022 20:12:14 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 6E88A3E007 for ; Tue, 23 Aug 2022 20:12:14 +0200 (CEST) Received: from localhost ([::1]:34992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQYNp-0003oV-5c for larch@yhetil.org; Tue, 23 Aug 2022 14:12:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35816) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQYNf-0003oH-Hs for guix-patches@gnu.org; Tue, 23 Aug 2022 14:12:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:55289) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQYNf-0001jK-7n for guix-patches@gnu.org; Tue, 23 Aug 2022 14:12:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oQYNd-0004JD-QT for guix-patches@gnu.org; Tue, 23 Aug 2022 14:12:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR Resent-From: Vagrant Cascadian Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 23 Aug 2022 18:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57070 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Pavel Shlyak , Maxime Devos Cc: 57070@debbugs.gnu.org, Tobias Geerinckx-Rice Received: via spool by 57070-submit@debbugs.gnu.org id=B57070.166127828316515 (code B ref 57070); Tue, 23 Aug 2022 18:12:01 +0000 Received: (at 57070) by debbugs.gnu.org; 23 Aug 2022 18:11:23 +0000 Received: from localhost ([127.0.0.1]:45038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQYN1-0004IJ-8v for submit@debbugs.gnu.org; Tue, 23 Aug 2022 14:11:23 -0400 Received: from cascadia.aikidev.net ([173.255.214.101]:37826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQYMy-0004I3-Jk for 57070@debbugs.gnu.org; Tue, 23 Aug 2022 14:11:21 -0400 Received: from localhost (unknown [IPv6:2600:3c01:e000:21:7:77:0:20]) (Authenticated sender: vagrant@cascadia.debian.net) by cascadia.aikidev.net (Postfix) with ESMTPSA id 308E71AC2D; Tue, 23 Aug 2022 11:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=debian.org; s=1.vagrant.user; t=1661278271; bh=40qmPmL+/gun3ptWBmHqRG8H49qFOfOTLPkzU0/Pwx4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XwStUPVLVt4p9M7CrLfg8gjFEBiDFyzL/cNmInLTk8ttF/lSpqfSxiKVyrbuGDKkm UqtErhy8SzsGnVI72q//2rHVVa5/eFXK+hg4TU/HHOtgLsXe2I2wIpXIswPlujbuqI hiu4bGILc+wBDGlbXAPvMQSMiOyw/n/+lB9LeynJrx46w3wI3TA5QQAHkvmSQxXdix HspOuoJn6BqxO/zNcdH+YJvVGBeXBjG+k3E6hUtXg3aywKdnKA3dMiBgYlki2GRgK2 9vmxKZ9H/tWYETsnaB2+SeTvVLvpPX08glFPVzhrRR8FdMo96e2jGrZ+krG2iH7WyU VqRi29NlIK2JQ== From: Vagrant Cascadian In-Reply-To: <13223735-7417-4785-81F8-43715A135574@pantherx.org> References: <20220809145730.435ef8d0@pantherx.org> <483BAA4D-ADDE-43C2-B1E3-BADAD7C43E7D@pantherx.org> <85904cd4-576d-81d0-2cfc-05ff0ab802a6@telenet.be> <13223735-7417-4785-81F8-43715A135574@pantherx.org> Date: Tue, 23 Aug 2022 11:11:06 -0700 Message-ID: <871qt6bzk5.fsf@contorta> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1661278334; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=NuNdeNGaPQnYIk5aFpw/wtLWcQJ+CZLjHhcVjVBOE74=; b=T/u8t/sPgIawa/3Y+vu8wGC77Uq1Fhm2c6jt6SRliyOngqhal54HmDaywI7HkiFQTtm6jv xARx9pML9lODNAj+i3AZUxReLpj6wTufEgS5gLqRavctRkLf2SLnqbgnzDPQzROf/siH0q m2bkSlblSvBQ3YotmIG9qeJaNUIxV6dLrJuvaZU3rsHwwZz9XxpjuG6NeLY5bEN6nHf5xG QQhEesZhDoR3w7a0lvlqm+MUfS75E2fu2YZolMgxybvdfU2oDyUcnjldh9g1YzWYv/Htfg 2kT9qm/lDFhLa1CMZrg7/k6mDJKy3nyeqxqMZLzzKqxGS5R0Hp5kcqbXP+9X6A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1661278334; a=rsa-sha256; cv=none; b=lBrQvyf63pl+ceRpiCs1dCEU/VuAhDepe7BdLiwYiZtpqbJ+JfRk7fp3utEMmJKWZni/5y RztEVVm9eR4KG0Ud6E/dCtgQmPsO0rBnR9uTlh4HrDUnPO5SV95yb5p/LtMskN5W8hYgcf irlWPh3/n2arOXI1lDM+lgfoqZ3U7trLUJ1dxtnlVa9fbFNqY1tK+qnrOrjlzvI7qfPfbv xZ2wZeTiaYY86ZjQtNmAUNd5T8DyPLgD8Su0ehDHPkQOVGdicDcr7/650NT+ux6L5J0r04 HVGg0xTUTv+8poJ42H/HLeXqLcwpyHk9J/n2/CyAhSxnFearg88SssgpDa+TXA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=debian.org header.s=1.vagrant.user header.b=XwStUPVL; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -0.90 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=debian.org header.s=1.vagrant.user header.b=XwStUPVL; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 6E88A3E007 X-Spam-Score: -0.90 X-Migadu-Scanner: scn0.migadu.com X-TUID: o+Lxpuadl/mG --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2022-08-22, Pavel Shlyak wrote: >> Could you point me at the documentation or code that claims or does >> that? I am not finding any evidence that device trees are generated >> at boot. I don't know exactly where in the code off the top of my head, but u-boot definitely has support for modifying the device-tree it passes to the kernel, and in some cases (e.g. memory layout, framebuffer) *requires* modifying the device-tree that is passed to the kernel. FWIW, I say this as someone who's maintained u-boot in debian (and to some degree guix) for years... Also, for some virtual platforms (qemu-riscv64?) the device-tree is created on-the-fly when bootstrapping the virtual machine; in these cases you have to rely on the device-tree passed via the boot "firmware" as you shouldn't need to recompile the kernel just to pass a different set of qemu arguments! There are cases where the kernel cannot possibly track the combinatorial explosion of potential add-on hardware modules (rpi hats, beagleboard capes, etc.) that need to be represented in the device-tree in order to work, sometimes before the kernel is even booted. There is some support for device-tree overlays both in-kernel and in u-boot (and plausibly other bootloaders) kernel to handle this, but in many cases, a simpler and more reliable method is to provide a single custom device-tree. > And for other devices that behave the same way? You=E2=80=99re literally > promoting making GUIX not bootable on all devices alike. > >> DTs are a kernel thing, e.g. the Linux documentation >> https://www.kernel.org/doc/html/latest/devicetree/usage-model.html >> mentions DT, also, Linux. Yes and no. Device-trees are used in, by and for both bootloaders and kernels alike. There is long-standing debate around device-tree should being treated as a boot firmware thing rather than a kernel thing. There are some pretty simple questions: You don't see ACPI tables for every supported x86 board in the kernel, why should boards using device-tree be any different? Why is the linux kernel the source of device-trees for, say, the Hurd, *BSD, etc.? So yes, it is de-facto where most device-trees come from at the end of the day, but ... that doesn't necessarily mean it *should* be. >> I could not find any information on bootloaders loading DTs. Well, that's what the FDTDIR and FDT settings for extlinux do; it tells the bootloader (e.g. u-boot) to load a device-tree. Grub also has a devicetree option, though no correlary to FDTDIR. If grub isn't passed a devicetree argument, it passes whatever devicetree that was passed from the boot firmware, as I understand it. >> My point is that supporting more devices would be nice, but this patch i= sn't the way to do it. > > Well, there is no other way to support devices that require DTB not to be= loaded with uboot. The solutions you suggest are not possible. > > Moreover, keep in mind FDTDIR is not in the http://www.freedesktop.org/wi= ki/Specifications/BootLoaderSpec/ specification and making is permanent we = basically violate it.=20 Hrm, that's unfortunate. I daresay supporting FDTDIR is a good thing, as it allows you to use the same boot media to boot multiple different devices, presuming they all have a .dtb present for the relevent boards. Booting arm systems have come a long way from you need a specifically compiled kernel for every different board, but it is still a horrible mess. Sometimes things are implemented in kernel, sometimes in the bootloader, sometimes in the boot firmware, with possibly 3-4 different boot firmware layers... and exactly where may be specific to a particular board. There are arguments that any particular thing might be better implemented at any of those layers, and maybe there is a convincing reason to move something from one layer to another... At the end of the day, the reality is that board support for some platforms (e.g. arm* and possibly riscv*) is a mess of inconsistancy and the usually you need to support multiple different ways of doing seemingly the same things. I think this tends to be hidden from view for x86 as quirks are just worked around in the kernel, whereas with some platforms where more of the boot firmware is free software it is possible to fix it in a more appropriate layer... or whatever layer the someone just happens to get it to work at first! If adding an option to drop the FDTDIR extlinux configuration allows booting more platforms, I see no fundamental reason why it is wrong, as long as it doesn't break existing platforms... the implementation details, I'll leave to people more savvy with scheme. :) live well, vagrant --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYwUYOwAKCRDcUY/If5cW qhV0AQC8N604ajTkp+Jeo30asfRuzvJ3XqvmyHxuboRPzqj+owD/TsKMAbmJRnR/ TCD46jwmVRj10spalBXSGdAfq6KEpA8= =v/wn -----END PGP SIGNATURE----- --=-=-=--