[PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined
Sughosh Ganu
sughosh.ganu at linaro.org
Tue Dec 15 16:35:46 CET 2020
On Tue, 15 Dec 2020 at 18:25, Heinrich Schuchardt <xypron.glpk at gmx.de>
wrote:
> 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.
>
This does work. Thanks. I was referring to the document mentioned in the
README.fdt-overlays[1] and that does not have mention of target-path.
-sughosh
[1] -
https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt
More information about the U-Boot
mailing list