On 08.12.20 06:28, Sughosh Ganu wrote: > > On Mon, 7 Dec 2020 at 23:28, Heinrich Schuchardt <xypron.g...@gmx.de > <mailto:xypron.g...@gmx.de>> wrote: > > 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.g...@gmx.de <mailto:xypron.g...@gmx.de> > >> <mailto:xypron.g...@gmx.de <mailto:xypron.g...@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://lists.denx.de/pipermail/u-boot/2019-October/387653.html> > > https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A&archive=both > > <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. > > > What i meant was that the process to generate the fdt overlay on the > host, embed it with the public-key certificate is more cumbersome than > the current solution. So, for comparing the embedding the pub-key cert > in the fdt overlay, as against the platform dtb > > Embedding the certificate in the overlay > 1) Generate a skeleton overlay dts file > 2) Convert it to a dtb > 3) Run it through the mkeficapsule utility to embed the pub-key > certificate in the overlay(dtb) > 4) Store the overlay dtb on some nv storage on the platform(ESP partition?) > 5) Load the overlay and apply it to the platform's dtb > 6) Retrieve the certificate from the dtb at the time of capsule > authentication > > Embedding the certificate in the platform's dtb > 1) Run the platform's dtb through the mkeficapsule utility to embed > the pub-key certificate > 2) Boot the platform with the platform's dtb > 3) Retrieve the certificate from the dtb at the time of capsule > authentication > > You had mentioned OpenSBI passing the dtb to u-boot. Does the OpenSBI > generate the device tree for the platform on the fly even for non-qemu > platforms. If it does not, the dtb that OpenSBI uses can be run through > the mkeficapsule utility to embed the certificate.
OpenSBI applies fix-ups before passing the device-tree. The prototype device-tree can either be built into OpenSBI or can be passed from an earlier firmware stage. Best regards Heinrich > > -sughosh