[PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined

[Heinrich Schuchardt]

On 07.12.20 13:50, Heinrich Schuchardt wrote:
> On 07.12.20 06:15, Sughosh Ganu wrote:
>> hello Heinrich,
>>
>> On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt <xypron.glpk at gmx.de
>> <mailto:xypron.glpk at gmx.de>> wrote:
>>
>>     On 11/26/20 7:40 PM, Sughosh Ganu wrote:
>>     > The Qemu platform emulator generates a device tree blob and places it
>>     > at the start of the dram, which is then used by u-boot. Use this dtb
>>     > only if CONFIG_OF_BOARD is defined. This allows using a different
>>     > device tree, using the CONFIG_OF_SEPARATE option. This dtb is attached
>>     > to the u-boot binary as a u-boot-fdt.bin file
>>
>>     Dear Sughosh,
>>
>>     thank your for this series which will allow us to better demonstrate and
>>     test capsule updates.
>>
>>     I am not sure if the approach that you take at device-trees here is the
>>     right one.
>>
>>     On QEMU the device-tree is generated on the fly by the QEMU binary
>>     depending on which devices the user has specified.
>>
>>     Your idea is to replace this device-tree completely to be able to add
>>     extra elements (the EFI signature list, see patch 2/14). Thus a
>>     device-tree might be loaded that does not match the user selected
>>     devices.
>>
>>     An alternative approach would be to apply all additions to the
>>     device-tree as an FDT overlay (or fixup). This would allow the dynamic
>>     parts of the QEMU device-tree still to be passed through.
>>
>>
>> I will take a look at storing the public key as part of the fdt overlay,
>> with a runtime fixup. Although, I think the issue that you are pointing
>> to would be specific to Qemu and not other platforms. But I do see the
>> merit in having the public-key certificate stored as part of an overlay.
>> If I hit any issues while implementing this, I will get back to you. Thanks.
>>
>> -sughosh
>
> OpenSBI can supply a device-tree to U-Boot. So this would be an
> equivalent case.
>
> Best regards
>
> Heinrich

<sng_>: "I am unable to think of a simple and elegant way to generate
the overlay dtb, since this would require creation of a corresponding
dts file, compiling it into a dtb and then using this on the platform."

Jean-Jacques' patch series introduced some of the necessary code:

[PATCH PATCH v6 00/13] Add support for applications of overlays in SPL
https://lists.denx.de/pipermail/u-boot/2019-October/387653.html
https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A&archive=both

CONFIG_OF_OVERLAY_LIST is used to specify the overlays to be compiled.
You will have to remove the CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY and
CONFIG_SPL_LOAD_FIT dependency.

Best regards

Heinrich

>
>>
>>
>>     Could you, please, assess the pros and cons of the two approaches with
>>     respect to:
>>
>>     * usability for capsule updates
>>     * applicability for non-QEMU systems
>>     * integration of DTB overlays with FIT images for other use cases
>>
>>     Best regards
>>
>>     Heinrich
>>
>>
>>     >
>>     > Signed-off-by: Sughosh Ganu <sughosh.ganu at linaro.org
>>     <mailto:sughosh.ganu at linaro.org>>
>>     > ---
>>     >   board/emulation/qemu-arm/qemu-arm.c | 2 ++
>>     >   1 file changed, 2 insertions(+)
>>     >
>>     > diff --git a/board/emulation/qemu-arm/qemu-arm.c
>>     b/board/emulation/qemu-arm/qemu-arm.c
>>     > index f18f2ed7da..e146d1cc50 100644
>>     > --- a/board/emulation/qemu-arm/qemu-arm.c
>>     > +++ b/board/emulation/qemu-arm/qemu-arm.c
>>     > @@ -89,11 +89,13 @@ int dram_init_banksize(void)
>>     >       return 0;
>>     >   }
>>     >
>>     > +#if defined(CONFIG_OF_BOARD)
>>     >   void *board_fdt_blob_setup(void)
>>     >   {
>>     >       /* QEMU loads a generated DTB for us at the start of RAM. */
>>     >       return (void *)CONFIG_SYS_SDRAM_BASE;
>>     >   }
>>     > +#endif
>>     >
>>     >   void enable_caches(void)
>>     >   {
>>     >
>>
>