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

[Simon Glass]

Hi,

On Fri, 5 Nov 2021 at 09:51, François Ozog <francois.ozog@linaro.org> wrote:
>
> 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
>

I am pinging this thread again as it has come up on the U-Boot mailing list[1].

Please can you reconsider this patch. It would greatly help the
collaboration between QEMU and U-Boot.

Regards,
Simon

[1] 
https://lore.kernel.org/u-boot/CAFEAcA-TH96CG1gi4toAQXpnxs4kxsPCSSfZrXbo2QF8CoE=XA@mail.gmail.com/T/#m1b41b54e3ca5dda1fcb8fdd189ac472ec7e4a96d