Hi Roman, On Mon, 8 Nov 2021 at 08:43, Roman Kopytin <[email protected]> wrote: > > Hi, I sent patches, please check. > But before correct emails I sent several test emails.
OK I see them, not copied to me, but I see them in the mailing list, thank you. Regards, Simon > > -----Original Message----- > From: Simon Glass <[email protected]> > Sent: Friday, November 5, 2021 5:02 AM > To: Roman Kopytin <[email protected]> > Cc: Rasmus Villemoes <[email protected]>; U-Boot Mailing List > <[email protected]>; Alex Kiernan <[email protected]>; Masahiro > Yamada <[email protected]> > 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 <[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.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 <[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 > > >
