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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> >> > --- >> > 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) >> > { >> > >> >
