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

[François Ozog]

HI Simon,

On Fri, 17 Sept 2021 at 18:21, Simon Glass <sjg at chromium.org> wrote:

> Hi François,
>
> On Wed, 15 Sept 2021 at 04:26, François Ozog <francois.ozog at linaro.org>
> wrote:
> >
> >
> >
> > Le mer. 15 sept. 2021 à 12:13, Simon Glass <sjg at chromium.org> a écrit :
> >>
> >> Hi Mark,
> >>
> >> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis at xs4all.nl>
> wrote:
> >> >
> >> > > From: Moiz Imtiaz <moizimtiaz1 at 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.
> Not that EDK2 actually supports very many boards, so far as I can tell
> from the source tree.
>
> I recall people complaining about libfdt being needed in EDK2 (I
> assume, perhaps it was some other UEFI?) Are you saying that EDK2 can
> use devicetree for its configuration? If not, thenI think you
> misunderstood my point.
>
I effectively did misunderstood your point. EDK2 configuration elements
come from very different sources. It consumes HOBs from the pre-EFI world,
has ACPI parameters, and even private storage. UEFI variables are used to
control some functional elements but if you want to talk about PCI
bifurcation control for instance it is not in ACPI, not in UEFI: just
private structures may be stored in an EEPROM or other element.

>
> > TF-A has fat less drivers than U-Boot. There is no problem in having a
> “verified” platform DT stored in BL33_CONFIG part of a FIP, verified by TFa
> and handed over by U-Boot to OS.
> > That can be the same thing in RPI4 case or FPGA boards.
> >>
>
> OK. I think you are saying that we can use TF-A on rpi and have it
> provide a suitable devicetree for U-Boot. That's fine. However it
> happens is fine. It just needs to support the features U-Boot
> supports, not provide a partial devicetree forcing U-Boot to put its
> config elsewhere.
>
> This is how I implemented LinuxBoot on MacchiatoBin: DT for the platform
in the FIP.
For the RPI, I would just consume what has been assembled through
config.txt overlays and other adjustments.
But again, TFA shall ignore the exact nature of the BL33 (U-Boot,
LinuxBoot, Xen...).
That said I agree there is a need of a clearer/richer contract at the entry
of BL33 (the HOBs/bloblist proposal by Harb is part of this extended
contract discussion).  The DT that TFA passes to BL33, may list a
restricted set of devices because BL33 may not need all devices, or it may
contain the same list of devices but with different bindings (I remember ST
suggesting a display may need 4 parameters for BL33 while it may be
thousands of bytes long for the full OS). This aspect is still open on the
DT technical report from Linaro DTE project (Device Tree Evolution).
U-Boot has a nice "environment" that can host parameters, it can even
include a base64'ified DT. As I said earlier, any program can use DT to
store self describing data. U-Boot can be one of them and use the FDT
format to store its configuration data. It will not be visible by upstream
or downstream firmware component. It is not an overlay of any sort.
It feels an elegant way to store program specific configuration data. Let's
just not make it a global thing on the platform.

>
> >>
> >>
> >> So perhaps the only remaining issue is with qemu on ARM / Risc-V?
>
> Regards,
> Simon
>


-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog