[PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined
Sughosh Ganu
sughosh.ganu at linaro.org
Wed Dec 9 06:25:40 CET 2020
On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> On 12/8/20 10:19 AM, Sughosh Ganu wrote:
> >
> > On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt <xypron.glpk at gmx.de
> > <mailto: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>
> > > <mailto: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>>
> > > >> <mailto: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://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
> >
> > >
> > <
> 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
>
> As I understand the whole series is not about productive firmware
> updates for QEMU but about a demonstration how it could be used and
> allowing testing.
>
True, but the process of embedding the public key certificate into the
platform's dtb for use in capsule authentication can be common for all
platforms. If you are fine, we can keep this patch to be used on other
non-qemu platforms, while i work on the overlay method for qemu. Will you
be fine with this approach.
-sughosh
More information about the U-Boot
mailing list