[PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES

[Simon Glass]

On 25/01/2022 00.50, Simon Glass wrote:
> Hi Rasmus,
>
> On Mon, 24 Jan 2022 at 15:15, Rasmus Villemoes
> <rasmus.villemoes at prevas.dk> wrote:
>>
>> On 24/01/2022 18.57, Simon Glass wrote:
>>
>>>> And the thing about "adding the signature" - yes, indeed, _signing_ can
>>>> and should be done after building. But that is not at all what this
>>>> started with, this is about embedding the metadata that U-Boot (or SPL)
>>>> will need for _verifying_ during the build itself - when the private key
>>>> may not even be available. Again, I think that it's a fundamental design
>>>> bug that generating and adding that metadata in the form needed by
>>>> U-Boot can only be done as a side effect of signing some unrelated image.
>>>
>>> It is a side effect of signing *the same* image, i.e. the image that
>>> holds the signature and the public key. There is only one image, the
>>> firmware image produced by binman.
>>
>> Huh? Are we talking about the same thing? What you write makes no sense
>> at all.
>
> Perhaps it is a terminology thing. For me:
>
> image: the final firmware image with everything in it
> binary: a component of the image
>
> So there is only one image.

It still makes no sense. I'm talking about the -K option to mkimage,
which modifies the .dtb-which-is-to-be-used-by-U-Boot while building a
FIT image containing kernel, initramfs and whatnot. That's certainly two
very different images (or, in your terminology, one image and an
entirely distinct binary destined to be included in another image).

Or for that matter, if one wants to do the same dance during SPL ->
U-Boot, this could be the FIT image containing U-Boot proper and its
control dtb (which must, of course, already have had the
public-key-for-verifying-the-kernel embedded) vs the SPL's control .dtb,
again two entirely different beasts.

The point is, I should not _need_ to sign anything in order to get the
public key info into the control .dtbs. That's why I call it a design bug.

I have explained all of this several times, including in the commit
message.

And the more you push for everyone to be using binman to generate the
final images, the more important it is that the U-Boot .dtb contains the
public-key-info before it gets used to build the final U-Boot image
(whether that's itself a FIT or just a concatenation of u-boot.bin and
u-boot.dtb). If I was assembling the final U-Boot image myself, I would
just need the u-boot recipe to produce u-boot.bin and u-boot.dtb, and
then I could have a separate step that updated u-boot.dtb. But when
binman is in charge of doing that assembly, there's no such place to
hook in, so I just want a way to ensure that the u-boot.dtb that gets
generated is already the final one - which is what this patch is
supposed to help with.

Rasmus

Applied to u-boot-dm, thanks!