On Fri, Sep 17, 2021 at 10:21:38AM -0600, Simon Glass wrote:
Hi François,
On Wed, 15 Sept 2021 at 04:26, François Ozog francois.ozog@linaro.org wrote:
Le mer. 15 sept. 2021 à 12:13, Simon Glass sjg@chromium.org a écrit :
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@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/broadcomfiles 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.
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. For example, if U-Boot evolves to support more devices, they could not be supported. If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
Please use EDK2 when you refer to it and not by the interface it implements. And even if we read “If EDK2 is used” this is false as Socionext has a platform that can select ACPI or DT for its EDK2 implementation.
OK I will try to remember to use 'EDK2' to describe a UEFI implementation. Since all the other UEFI implementations are closed-source(?) I suppose it is the only one that is relevant here.
Just for the record, AMI recently announced they will be supporting aarch64, and yes with ACPI.