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.o...@linaro.org> wrote: > > > > > > > > Le mer. 15 sept. 2021 à 12:13, Simon Glass <s...@chromium.org> a écrit : > >> > >> 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. > >> > >> 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. -- Tom
signature.asc
Description: PGP signature
