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

[Sughosh Ganu]

On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:

> On 08.12.20 06:28, Sughosh Ganu wrote:
> >
> > On Mon, 7 Dec 2020 at 23:28, Heinrich Schuchardt <xypron.glpk at gmx.de
> > <mailto:xypron.glpk at 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.glpk at gmx.de <mailto:xypron.glpk at gmx.de>
> >     >> <mailto: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://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.


So, if qemu if the only platform where the device tree is generated on the
fly, and passed along, based on the comparison that i have stated above for
the two scenarios(overlay vs platform dtb), I feel that using the
platform's dtb and embedding the certificate is more easier to use than
using the overlay.

Even on the qemu platform, I retrieved the dtb from the platform, for the
given set of devices and interfaces used, and then ran the dtb through the
mkeficapsule utility.

-sughosh