Hi Roman,

Good luck! I must get a copy of that BOFH book.

Regards,
Simon



On Sun, 31 Oct 2021 at 22:30, Roman Kopytin <[email protected]> wrote:
>
> Hi, all
> Currently I am waiting some help from our IT infrastructure department.
>
> -----Original Message-----
> From: Simon Glass <[email protected]>
> Sent: Tuesday, October 26, 2021 4:28 AM
> To: Rasmus Villemoes <[email protected]>
> Cc: U-Boot Mailing List <[email protected]>; Alex Kiernan 
> <[email protected]>; Roman Kopytin <[email protected]>; 
> Masahiro Yamada <[email protected]>
> Subject: Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES
>
> Hi Rasmus,
>
> On Tue, 28 Sept 2021 at 02:57, Rasmus Villemoes <[email protected]> 
> wrote:
> >
> > The build system already automatically looks for and includes an
> > in-tree *-u-boot.dtsi when building the control .dtb. However, there
> > are some things that are awkward to maintain in such an in-tree file,
> > most notably the metadata associated to public keys used for verified
> > boot.
> >
> > The only "official" API to get that metadata into the .dtb is via
> > mkimage, as a side effect of building an actual signed image. But
> > there are multiple problems with that. First of all, the final U-Boot
> > (be it U-Boot proper or an SPL) image is built based on a binary
> > image, the .dtb, and possibly some other binary artifacts. So
> > modifying the .dtb after the build requires the meta-buildsystem
> > (Yocto, buildroot, whatnot) to know about and repeat some of the steps
> > that are already known to and handled by U-Boot's build system,
> > resulting in needless duplication of code. It's also somewhat annoying
> > and inconsistent to have a .dtb file in the build folder which is not
> > generated by the command listed in the corresponding .cmd file (that
> > of course applies to any generated file).
> >
> > So the contents of the /signature node really needs to be baked into
> > the .dtb file when it is first created, which means providing the
> > relevant data in the form of a .dtsi file. One could in theory put
> > that data into the *-u-boot.dtsi file, but it's more convenient to be
> > able to provide it externally: For example, when developing for a
> > customer, it's common to use a set of dummy keys for development,
> > while the consultants do not (and should not) have access to the
> > actual keys used in production. For such a setup, it's easier if the
> > keys used are chosen via the meta-buildsystem and the path(s) patched
> > in during the configure step. And of course, nothing prevents anybody
> > from having DEVICE_TREE_INCLUDES point at files maintained in git, or
> > for that matter from including the public key metadata in the
> > *-u-boot.dtsi directly and ignore this feature.
> >
> > There are other uses for this, e.g. in combination with ENV_IMPORT_FDT
> > it can be used for providing the contents of the /config/environment
> > node, so I don't want to tie this exclusively to use for verified
> > boot.
> >
> > Signed-off-by: Rasmus Villemoes <[email protected]>
> > ---
> >
> > Getting the public key metadata into .dtsi form can be done with a
> > little scripting (roughly 'mkimage -K' of a dummy image followed by
> > 'dtc -I dtb -O dts'). I have a script that does that, along with
> > options to set 'required' and 'required-mode' properties, include
> > u-boot,dm-spl properties in case one wants to check U-Boot proper from
> > SPL with the verified boot mechanism, etc. I'm happy to share that
> > script if this gets accepted, but it's moot if this is rejected.
> >
> > I have previously tried to get an fdt_add_pubkey tool accepted [1,2]
> > to disentangle the kernel and u-boot builds (or u-boot and SPL builds
> > for that matter!), but as I've since realized, that isn't quite enough
> > - the above points re modifying the .dtb after it is created but
> > before that is used to create further build artifacts still stand.
> > However, such a tool could still be useful for creating the .dtsi info
> > without the private keys being present, and my key2dtsi.sh script
> > could easily be modified to use a tool like that should it ever
> > appear.
> >
> > [1]
> > https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villemoes
> > @prevas.dk/ [2]
> > https://lore.kernel.org/u-boot/2184f1e6dd6247e48133c76205feeabe@kasper
> > sky.com/
> >
> >  dts/Kconfig          | 9 +++++++++
> >  scripts/Makefile.lib | 2 ++
> >  2 files changed, 11 insertions(+)
>
> Reviewed-by: Simon Glass <[email protected]>
>
> I suggest adding this to the documentation somewhere in 
> doc/develop/devicetree/
>
> Getting the key into the U-Boot .dtb is normally done with mkimage, as you 
> say. I don't really understand why this approach is easier.
>
> Also, is there any interest in using binman? It is designed to do the 
> 'packaging' step right at the end, when all the bits are available and just 
> need to be put together.
>
> I am trying to encourage people to move away from building from source 
> always, to a two-step process:
>
> - build all the bits
> - package them, update devicetree, etc.
>
> https://u-boot.readthedocs.io/en/latest/develop/package/index.html
>
> BTW if Roman can figure out how to send the patches I think that tool would 
> be useful too.
>
> Regards,
> Simon
>
>
>
> >
> > diff --git a/dts/Kconfig b/dts/Kconfig index dabe0080c1..593dddbaf0
> > 100644
> > --- a/dts/Kconfig
> > +++ b/dts/Kconfig
> > @@ -139,6 +139,15 @@ config DEFAULT_DEVICE_TREE
> >           It can be overridden from the command line:
> >           $ make DEVICE_TREE=<device-tree-name>
> >
> > +config DEVICE_TREE_INCLUDES
> > +       string "Extra .dtsi files to include when building DT control"
> > +       depends on OF_CONTROL
> > +       help
> > +         U-Boot's control .dtb is usually built from an in-tree .dts
> > +         file, plus (if available) an in-tree U-Boot-specific .dtsi
> > +         file. This option specifies a space-separated list of extra
> > +         .dtsi files that will also be used.
> > +
> >  config OF_LIST
> >         string "List of device tree files to include for DT control"
> >         depends on SPL_LOAD_FIT || MULTI_DTB_FIT diff --git
> > a/scripts/Makefile.lib b/scripts/Makefile.lib index
> > 78bbebe7e9..a2accba940 100644
> > --- a/scripts/Makefile.lib
> > +++ b/scripts/Makefile.lib
> > @@ -320,6 +320,8 @@ quiet_cmd_dtc = DTC     $@
> >  # Bring in any U-Boot-specific include at the end of the file
> > cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> >         (cat $<; $(if $(u_boot_dtsi),echo '$(pound)include
> > "$(u_boot_dtsi)"')) > $(pre-tmp); \
> > +       $(foreach f,$(subst $(quote),,$(CONFIG_DEVICE_TREE_INCLUDES)), \
> > +         echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
> >         $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) 
> > $(pre-tmp) ; \
> >         $(DTC) -O dtb -o $@ -b 0 \
> >                 -i $(dir $<) $(DTC_FLAGS) \
> > --
> > 2.31.1
> >

Reply via email to