all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Pavel Shlyak <p.shlyak@pantherx.org>
To: Maxime Devos <maximedevos@telenet.be>
Cc: vagrant@debian.org, 57070@debbugs.gnu.org,
	Tobias Geerinckx-Rice <me@tobias.gr>
Subject: [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR
Date: Mon, 22 Aug 2022 22:19:29 +0300	[thread overview]
Message-ID: <13223735-7417-4785-81F8-43715A135574@pantherx.org> (raw)
In-Reply-To: <fe96081c-1420-82ba-69ed-5faca7294698@telenet.be>

> 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.

Google «device tree raspberry bootloader», 1st result https://forums.raspberrypi.com/viewtopic.php?t=329799

> If the bootloader can, surely the kernel can.

Bootloader runs on GPU on Raspberry. It cannot run kernel. 
Also, check m1n1 on Apple. It has docs.

> I believe the kernel folks will appreciate a patch fixing the DT for RPI3b+ and Compute Module 4.

And for other devices that behave the same way? You’re 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.  I could not find any information on bootloaders loading DTs.

Because you didn’t search for it. Google «device tree raspberry bootloader», the first link is about bootloader forming the device tree https://forums.raspberrypi.com/viewtopic.php?t=329799. Google «uboot device tree» https://u-boot.readthedocs.io/en/latest/usage/fdt_overlays.html to know how uboot manipulates them.
Moreover, Raspberry PI uboot uses DTB to boot on the board as in https://patchwork.ozlabs.org/project/uboot/patch/20191106144104.28177-1-matthias.bgg@kernel.org/ (Instead of using the embedded DTB as done in RPi3 we use the devicetree provided by the firmware.)

> bootloaders don't magically have access to more information than kernels

They do, if they are run on a separate core on the SOC that linux or arm core has no access to.  Check https://github.com/christinaa/rpi-open-firmware

> My point is that supporting more devices would be nice, but this patch isn'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/wiki/Specifications/BootLoaderSpec/ specification and making is permanent we basically violate it. 

Since we’ve not come to any understanding here, I kindly invite Vagrant and Tobias to join the discussion. They seem to be familiar with the relevant parts of GUIX.

Sincerely,
Pavel



  reply	other threads:[~2022-08-22 19:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-09 10:27 [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR Reza Alizadeh Majd
2022-08-09 10:30 ` Reza Alizadeh Majd
2022-08-15  9:27   ` Mathieu Othacehe
2022-08-16 18:10   ` Reza Alizadeh Majd
2022-08-25 17:35     ` Mathieu Othacehe
2022-08-28  8:19       ` Reza Alizadeh Majd
2022-08-28 15:49         ` Mathieu Othacehe
2022-08-29 18:17           ` Reza Alizadeh Majd
2022-08-30  6:53             ` bug#57070: " Mathieu Othacehe
2022-08-10  9:31 ` [bug#57070] " Maxime Devos
2022-08-15 10:57   ` Tobias Geerinckx-Rice via Guix-patches via
2022-08-10  9:32 ` Maxime Devos
2022-08-16 17:08   ` Reza Alizadeh Majd
2022-08-16 18:44     ` Maxime Devos
2022-08-10 14:37 ` Pavel Shlyak
2022-08-11 10:00   ` Maxime Devos
2022-08-11 11:13     ` Pavel Shlyak
2022-08-10 14:46 ` Pavel Shlyak
2022-08-20 10:15 ` Pavel Shlyak
2022-08-22  8:54   ` Maxime Devos
2022-08-22 10:52     ` Pavel Shlyak
2022-08-22 18:57       ` Maxime Devos
2022-08-22 19:19         ` Pavel Shlyak [this message]
2022-08-22 21:17           ` Maxime Devos
2022-08-22 21:29             ` Pavel Shlyak
2022-08-23 18:11           ` Vagrant Cascadian
2022-08-25 19:16 ` Pavel Shlyak
2022-08-30  6:52   ` Mathieu Othacehe

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=13223735-7417-4785-81F8-43715A135574@pantherx.org \
    --to=p.shlyak@pantherx.org \
    --cc=57070@debbugs.gnu.org \
    --cc=maximedevos@telenet.be \
    --cc=me@tobias.gr \
    --cc=vagrant@debian.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.