Re: Problem with U-boot | Configuration Signature not being checked while booting

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 3214 bytes --]

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/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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]