Hi, I sent patches, please check. But before correct emails I sent several test emails.
-----Original Message----- From: Simon Glass <s...@chromium.org> Sent: Friday, November 5, 2021 5:02 AM To: Roman Kopytin <roman.kopy...@kaspersky.com> Cc: Rasmus Villemoes <rasmus.villem...@prevas.dk>; U-Boot Mailing List <u-boot@lists.denx.de>; Alex Kiernan <alex.kier...@gmail.com>; Masahiro Yamada <masahi...@kernel.org> Subject: Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES 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 <roman.kopy...@kaspersky.com> wrote: > > Hi, all > Currently I am waiting some help from our IT infrastructure department. > > -----Original Message----- > From: Simon Glass <s...@chromium.org> > Sent: Tuesday, October 26, 2021 4:28 AM > To: Rasmus Villemoes <rasmus.villem...@prevas.dk> > Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Alex Kiernan > <alex.kier...@gmail.com>; Roman Kopytin <roman.kopy...@kaspersky.com>; > Masahiro Yamada <masahi...@kernel.org> > Subject: Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES > > Hi Rasmus, > > On Tue, 28 Sept 2021 at 02:57, Rasmus Villemoes <rasmus.villem...@prevas.dk> > 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 <rasmus.villem...@prevas.dk> > > --- > > > > 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.villemo > > es > > @prevas.dk/ [2] > > https://lore.kernel.org/u-boot/2184f1e6dd6247e48133c76205feeabe@kasp > > er > > sky.com/ > > > > dts/Kconfig | 9 +++++++++ > > scripts/Makefile.lib | 2 ++ > > 2 files changed, 11 insertions(+) > > Reviewed-by: Simon Glass <s...@chromium.org> > > 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 > >
