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

Heinrich Schuchardt xypron.glpk at gmx.de
Tue Dec 15 13:55:33 CET 2020


On 15.12.20 12:10, Sughosh Ganu wrote:
>
> On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.glpk at gmx.de
> <mailto: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>
>     > <mailto: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>>
>     >      > <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 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>>>
>     >      >     >> <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 <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://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>>
>     >      >
>     >     
>      <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.
>
>     Wouldn't it be the enough for testing to apply an overlay with the
>     public key using the fdt command?
>
>
> Is there a way I can build qemu such that the device-tree that is
> generated is with the __symbols__ node. Without this node, I am unable
> to apply the fdt overlay on the base platform devicetree.

According to
https://www.kernel.org/doc/Documentation/devicetree/overlay-notes.txt
__symbols__ is only needed if you refer to phandles in the overlay. When
using paths instead __symbols__ is not required.

I have not tested if this holds true for U-Boot too.

Best regards

Heinrich

>
> -sughosh 



More information about the U-Boot mailing list