Hi Mark, On Wed, 15 Sept 2021 at 05:52, Mark Kettenis <mark.kette...@xs4all.nl> 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. > > > 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.
Not in general. I hope I have covered this in enormous detail in the devicetree patch. But if you don't need verified boot, SPL or some other feature that needs config, then perhaps you will get away with it. > > 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. Indeed, since AFAIK there is no way to use U-Boot as a first-stage bootloader on rpi. > > > 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 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 ;). It is a constant risk. > > > 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. François made the same point and I'm pretty sure you are talking about booting a kernel using devicetree. Here, we are talking about setting up the U-Boot control dtb correctly and my point was that UEFI does not use a control dtb, so far as I know. > > > So perhaps the only remaining issue is with qemu on ARM / Risc-V? > > Maybe somebody can add device tree overlay support to QEMU? Yes. I'm actually willing to do this once we get the UEFI embedded signature reverted. I think it is pretty clear now that it is a dead end. Regards, Simon
