Re: [PATCH] hw/arm/virt: Allow additions to the generated device tree

["François Ozog" <francois.ozog@linaro.org>]

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

Hi,

On Wed, 3 Nov 2021 at 14:17, François Ozog <francois.ozog@linaro.org> wrote:

> Hi,
>
> Thanks Alex to patch me in.
>
> I'd like to present another perspective on the motivation as I can't
> really comment on the actual "how".
>
> On real Arm boards, firmware is often assembled into a FIP.
> That FIP can contain quite a good deal of things, including an
> NT_FW_CONFIG, NonTrusted_FirmWare_CONFIGuration (NT_FW = BL33 which is
> U-Boot in our case).
> So the expected typical content for that section is a DT fragment/overlay.
> That section is to be used in different ways but one is
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> .
> For SystemReady systems we will almost inevitably put a device tree
> fragment in this section and have BL2 merge it with the board DT before
> handing it over to BL33 (U-Boot is one of them).
> In some real world examples based on carrier board + som for instance, it
> may contain SerDes configuration for U-Boot that will result in appropriate
> PCI lanes or MDIO lanes for the booted OS.
>
> So I could say there is precedence in Simon's effort.
>
> In any case, when we will have made the changes in TFA for the SystemReady
> boards we work on, booting the full SystemReady stack (TFA, OP-TEE, U-Boot)
> on Qemu will allow that late merge based through the FIP.
>
> Other boot flows such as VBE (without TFA but with TPL/SPL/U-Boot proper)
> need a similar facility.
>
>
Hence I am supporting Simon's proposal at least on the intent. On the how
> exactly, that is outside my skillset.
>
Responding to my own comment:
As the boot flow TFA+U-Boot works, it looks like a cleaner option is to
leave QEMU alone and have
U-Boot SPL do the same work as with TFA: use a section for the FIT for the
DT to be merged.



>
future comments below
>
>
> On Wed, 3 Nov 2021 at 12:48, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>> > On Mon, 27 Sept 2021 at 16:18, Simon Glass <sjg@chromium.org> wrote:
>> >> On Mon, 27 Sept 2021 at 02:48, Peter Maydell <peter.maydell@linaro.org>
>> wrote:
>> >> > So what is missing in the QEMU-provided DTB that it needs?
>> >>
>> >> Quite a lot. Here are some examples:
>> >>
>> >> U-Boot has limited pre-relocation memory so tries to avoid
>> >> binding/probing devices that are not used before relocation:
>> >>
>> >>
>> https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#pre-relocation-support
>> >
>> > It's up to u-boot to decide what it wants to touch and
>> > what it does not. QEMU tells u-boot what all the available
>> > devices are; I don't think we should have extra stuff saying
>> > "and if you are u-boot, do something odd".
>> >
>> >> There is a configuration node (which is likely to change form in
>> >> future releases, but will still be there)
>> >>
>> >>
>> https://github.com/u-boot/u-boot/blob/master/doc/device-tree-bindings/config.txt
>> >
>> > I think u-boot should be storing this kind of thing somewhere
>> > else (e.g. as part of the binary blob that is u-boot itself,
>> > or stored in flash or RAM as a separate blob).
>> >
>> >> Then there are various features which put things in U-Boot's control
>> >> dtb, such as verified boot, which adds public keys during signing:
>> >>
>> >>
>> https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt#L135
>> >>
>> >> More generally, the U-Boot tree has hundreds of files which add
>> >> properties for each board, since we try to keep the U-Boot-specific
>> >> things out of the Linux tree:
>> >>
>> >> $ find . -name *u-boot.dtsi |wc -l
>> >> 398
>> >
>> > If any of this is actual information about the hardware then you
>> > should sort out getting the bindings documented officially
>> > (which I think is still in the Linux tree), and then QEMU can
>> > provide them.
>> >
>> >> Quite a bit of this is to do with SPL and so far it seems that QEMU
>> >> mostly runs U-Boot proper only, although I see that SPL is starting to
>> >> creep in too in the U-Boot CI.
>> >>
>> >> So at present QEMU is not able to support U-Boot fully.
>> >
>> > My take is that this is u-boot doing weird custom things with
>> > the DTB that aren't "describe the hardware". You should be able
>> > to boot u-boot by putting those custom DTB extra things in a
>> > separate blob and having u-boot combine that with the
>> > actual DTB when it starts.
>>
>> It's not entirely without precedent - for SPL (which I hope is secondary
>> program loading) we have things like the guest loader which expands the
>> plain HW DTB with some information needed by the bootloader and the
>> primary OS to load additional blobs which have been put into memory.
>>
>> In effect the DTB is being expanded as a signalling mechanism similar to
>> things like fw_cfg and other things we use to control boot up. Whether
>> this affects the "purity" of DTB as a "just the HW" description is
>> probably a philosophical question.
>>
>> More than a philosophical question: a key aspect of supply chain that
> need change from
> quite inflexible and tightly coupled to loosely coupled.
>  A key aspect of it is to maintain "pure" hardware description DTBs at
> rest.
> Composition of DTBs at build time (for products) or runtime (for
> development boards) should be a simple thing.
> Another aspect to take into account is System Device Trees. U-Boot only
> deal with Cortex-As on a platform,
> so there are multiple device trees for each compute domain. Communities
> are working on System Device Tree
> to define the overall platform with its power and clock domains. A tool
> "lopper" is being developed to slide the SDT into diverse domain DTs.
> One of them being included into the FIP as the basis for the computing
> element (Carrier, SoM...).
> Those attempts to cleanup passed DTBs from configuration data (drivers,
> bootloaders...) is not incompatible
> with merging fragments at runtime (for dev boards) or build time (for
> products).
>
>> I agree with Peter that just allowing the merging of arbitrary data into
>> the QEMU generated DTB is going to lead to confusion and breakages.
>> Indeed I wrote the guest-loader because instructions for booting Xen up
>> until that point involved dumpdtb and hand hacking the data which was
>> silly because this is stuff QEMU already knew about.
>>
>> >
>> > -- PMM
>>
>>
>> --
>> Alex Bennée
>>
>
>
> --
> François-Frédéric Ozog | *Director Business Development*
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
>
>

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

[-- Attachment #2: Type: text/html, Size: 12480 bytes --]