[PATCH 2/3] tools: add fdt_add_pubkey

[Rasmus Villemoes]

On 11/02/2020 10.54, Alex Kiernan wrote:
> On Tue, Feb 11, 2020 at 9:49 AM Rasmus Villemoes
> <rasmus.villemoes at prevas.dk> wrote:
>>
>> Having to use the -K option to mkimage to populate U-Boot's .dtb with the
>> public key while signing the kernel FIT image is often a little
>> awkward. In particular, when using a meta-build system such as
>> bitbake/Yocto, having the tasks of the kernel and U-Boot recipes
>> intertwined, modifying deployed artifacts and rebuilding U-Boot with
>> an updated .dtb is quite cumbersome. Also, in some scenarios one may
>> wish to build U-Boot complete with the public key(s) embedded in the
>> .dtb without the corresponding private keys being present on the same
>> build host.
>>
> 
> Have you started looking at the required bitbake pieces? You're
> definitely dealing with a piece of pain that I'd like resolved!

Not really, but I know that something like this is a necessary first
part - and I'm glad to know I'm not the only one struggling with this.

For now I've come to the conclusion that kernel-fitimage.bbclass is not
worth the trouble (for example, I need to create two different fit
images with different initramfs, but a fit image without initramfs is
pointless in my case, and there's no way to use kernel-fitimage.bbclass
for that), so I just set KERNEL_IMAGETYPE to vmlinux, then have my own
extra tasks doing the objcopy -O binary, gzip, and mkimage the different
fit images I need.

[I'm also thinking that adding a companion tool for doing the signing
part might make sense at some point - it's somewhat counter-intuituve
that the .its contains some of the information (base name of key and
algorithm - mkimage currently just segfaults if key-name-hint is
accidentally omitted from the .its), while mkimage needs to be fed with
another part (directory holding the keys).]

Rasmus