Hi Tom, On Wed, 15 Sept 2021 at 07:35, Tom Rini <tr...@konsulko.com> wrote: > > On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote: > > > From: Simon Glass <s...@chromium.org> > > > Date: Wed, 15 Sep 2021 04:13:24 -0600 > > > > Hi Simon, > > > > > Hi Mark, > > > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kette...@xs4all.nl> > > > wrote: > > > > > > > > > From: Moiz Imtiaz <moizimti...@gmail.com> > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > > > > > > > > > Hi Simon, > > > > > > > > > > Thanks for the reply. I already followed the steps mentioned in > > > > > "doc/uImage.FIT/beaglebone_vboot.txt". > > > > > > > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but > > > > > instead one provided by the earlier-stage firmware? > > > > > > > > > > Not sure, but seems like this is the case. I checked and there isn't > > > > > any > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I > > > > > tried to > > > > > add the dtb and other dts dtsi > > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE > > > > > and > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot > > > > > and > > > > > it would just give a blank screen*. I wonder why there isn't any > > > > > device > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported > > > > > by > > > > > RPI4? > > > > > > > > The issue with the rpi4 is that the addresses of devices move around > > > > based on the version of the Raspberry Pi firmware you're using. And > > > > possibly on the amount of memory on the board as well. So U-Boot > > > > pretty much has to use the device tree passed by the firmware since > > > > the device tree in the U-Boot tree would be wrong for many > > > > combinations of firmware and hardware. > > > > > > > > Simon, this sort of thing is exactly the reason why I think the idea > > > > of having all U-Boot configuration information in a single device tree > > > > with the hardware description doesn't work everywhere. > > > > > > >From my reading of this thread, it rather reinforces the need to > > > provide a way to give U-Boot the config it needs, in the devicetree. > > > > As long as that configuration is optional, yes, maybe. > > Lets be a little careful. We don't want to have two ways to provide the > information for a given feature. But some configuration properties are > certainly optional. > > > > It seems that rpi is actually OK in this regard. If you think about > > > it, it would be pretty hopeless if first-stage firmware assumed that > > > it could provide a devicetree to whatever is next. > > > > Not hopeless. If that device tree provides a hardware description > > that is complete enough to boot Linux, it should be good enough to run > > U-Boot. > > And keep in mind that one of those long stated goals is that the device > tree for a platform lives physically on the platform and doesn't require > being replaced entirely at run-time with a new/different device tree. > > > And yes, the Raspberry Pi has a nice way to load overlays to do > > additional hardware configuration and support add-on hardware that > > connects to the GPIO header on the Pi. Replicating all this in U-Boot > > would make very little sense. > > Note that in U-Boot we do have functionality to figure out and apply DT > overlays for a platform, and it's generic enough that platforms can > plugin their logic to detect what overlays are appropriate. This is > under CMD_EXTENSION. It's not appropriate for Pi as they did all of > this in their in-house firmware instead of using U-Boot. > > > > For example, if U-Boot evolves to support more devices, they could > > > not be supported. > > > > Unless the device in question has a mechanism to load device tree > > overlays like the Pi, this would require a firmware update. > > In that CMD_EXTENSION is about updating the tree for the next stage, and > not ourself, yes. But this is also the same problem that OSes have that > lead to overlays, at least in part. But also why it's so hard to > support a static device tree on hardware, and have an evolving kernel. > I'm not sure there's many / any good examples of wholly static and also > feature complete device trees and OSes today, on a recent / semi-recent > piece of hardware. > > > In practice, the device tree provided by the firmware will have more > > stuff than U-Boot will ever need though. Unless you're advocating > > that U-Boot evolves into a full-fledged OS ;). > > > > > If UEFI is used, the devicetree would have no effect, since it doesn't > > > support devicetree. > > > > That is not true. UEFI supports device trees just fine. All the > > arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER > > support use device trees. The idea that UEFI implies ACPI is a > > misconception. > > > > > So perhaps the only remaining issue is with qemu on ARM / Risc-V? > > > > Maybe somebody can add device tree overlay support to QEMU? > > Having gone through this thread, I wonder if U-Boot generating a device > tree overlay (and also the keeping the source of it, before > preprocessing if we can) isn't part of the solution here. Heinrich had > suggested in another thread, and Simon had strongly disagreed with > overlays being how we perhaps solve some portions of the overall "what > should U-Boot require of the DT?" problem. I'm thinking that might be > the right answer, in some cases.
Note that my objection here is adding runtime to U-Boot. If the prior stage wants to arrange things that way, it seems OK to me. In particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot tree to merge with what it generates. Regards, Simon
