On 11/02/2020 10.54, Alex Kiernan wrote: > On Tue, Feb 11, 2020 at 9:49 AM Rasmus Villemoes > <rasmus.villem...@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