[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR

From: Maxime Devos
Subject: [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR
Date: Mon, 22 Aug 2022 23:17:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0

On 22-08-2022 21:19, Pavel Shlyak wrote:
Re: [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR
Pavel Shlyak <>
22-08-2022 21:19
Maxime Devos <>
CC:,, Tobias Geerinckx-Rice <>

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

That web page does not claim that anywhere.

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 have never claimed that the GPU can run the kernel.

What does m1n1 have to do with anything here? m1n1 isn't extlinux and isn't packaged in Guix.

Bootloaders running on the GPU is something I'm not used to at all, it's not something I had expected, see later.

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.

I literally never wrote such a thing. In what sentences did I promote that?

Even if you meant 'implied' instead of 'literally', then that still doesn't make sense to me; I'm running Guix System, it's in my own interest to keep it bootable on my device.

DTs are a kernel thing, e.g. the Linux documentation mentions DT, also, Linux.  I could not find any information on bootloaders loading DTs.
Because you didn’t search for it.
I did search for it, figuring out an _appropriate_ query and finding relevant results is another matter.
No. It has monopoly and privacy problems.
 «device tree raspberry bootloader», the first link is about bootloader forming the device tree
Generating the DT is a different matter from loading the DT.  It's also about firmware, not the bootloader.
 Google «uboot device tree» to know how uboot manipulates them.
These overlays look rather manual, to be done by the user for individual models, I don't see the relevancy.
Moreover, Raspberry PI uboot uses DTB to boot on the board as in (Instead of using the embedded DTB as done in RPi3 we use the devicetree provided by the firmware.)
Going by the mention of 'defconfig' and 'arch/arm' and 'configs', this appears to be a patch to Linux, not uboot. As such, it appears that the device tree information is used by Linux here, there is no information there on whether it is used by U-Boot.
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

That's a setup I would not have expected.

AFAIK nothing is stopping Linux from sending some code to the separate core to figure out the relevant information and sending it back to Linux. But given the unusual setup, I would consider it plausible that Linux people want to delegate such responsibility to the bootloader.

Was this (i.e. "they are run on a separate core on the SOC ...") the case for the Raspberry device you are trying to support?

If so, figuring out the appropriate options to let U-boot pass the device tree to Linux seems reasonable to me.

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 specification and making is permanent we basically violate it. 

And is this a bad thing, and if so, perhaps FDTDIR could be added to the specification? Guix being in violation of some specification is not in itself a bug, for example the store model of Guix is not 'Linux Standard Base'.

It might be a bad thing, but there's a step missing in your argument.

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.

See the 'If so, figuring out the appropriate options ...' above.

Also, again, it's Guix, not GUIX. GUIX is a Microsoft thing.


Attachment: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]