Hi Pelle That's something where I did not yet look into all the details. But this needs to be considered for new architecture. Would you mind to document this aspect on this bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=12912? It's what I tried to mention with
"However, signing u-boot and kernel might cause some tricky dependencies which cannot be simplified. But understanding all these details needs a PoC implementation, I guess." in my comment from today https://bugzilla.yoctoproject.org/show_bug.cgi?id=12912#c3. It looks like you looked already deeper into this detail. Adrian On Wed, 2024-12-11 at 00:33 -0800, Pelle Windestam via Lists.Yoctoproject.Org wrote: > Thanks for the tips Adrian, I will look into that fitimage.bbclass. I > was also thinking about the dependency between u-boot and linux > kernel. It seems to be required since uboot-sign.bbclass "re-signs" > the fitImage (and puts the public key in the u-boot dtb with the same > command) and then does a verification to check that the key works. > But is the re-signing really required? As far as I could tell trying > to navigate the uboot-sign.bbclass the re-signed image is never used > except for doing the verification. If one would skip the verification > step, I think it would suffice to to put the public key into the u- > boot dtb and thus be able drop the dependency on the kernel recipe? > Doing the verification is of course a good idea to make sure you do > not end up with a non-bootable fitImage, but it could work as a > temporary work-around.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#64431): https://lists.yoctoproject.org/g/yocto/message/64431 Mute This Topic: https://lists.yoctoproject.org/mt/110031442/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
