> On 27 July 2017 at 17:48 colin.helliw...@ln-systems.com wrote:
>
> I'm working on 2.2/Morty, with a custom board.
> Ultimate goal is to create a FIT image with a signed configuration. But I'm
> trying to just work through step by step and understand the relationships
> between u-boot, kernel, dtb, and the fit image - would appreciate any
> guidance!
> So far, I've built and booted a fitImage.
>
...
>
> First thing I'm puzzled by is that the dtb *is* in
> tmp/deploy/images/mymachine/ , but is called
> "zImage--4.4-r0-mymachine-20170727160613.dtb". Also with a symlink
> "zImage-mymachine.dtb". (If I'm understanding things right, this is because
> the fitImage contains a compressed kernel...?)
>
> Then I set UBOOT_SIGN_ENABLE = "1", and re-bitbake the u-boot target. It
> only gets as far as re-building the kernel, which fails on the
> do_assemble_fitimage stage because uboot-mkimage is being told to use
> "u-boot.dtb"
>
After studying things in more depth, I've now grasped that the relationships
with the uboot-sign class are, not circular, but a bit to-and-fro between
kernel and u-boot. Please correct me if I've got any of this wrong:
The 'final' signed dtb, for use by U-Boot, consists of the U-Boot dtb (i.e. the
traditional U-Boot hardware blob) plus the fitimage dtb tree;
The latter encompasses the kernel and the hardware blob from the *kernel*.
It seems a bit tortured to have two hardware device blobs involved in this, but
I kinda get the issues of keeping sync between two
(https://stackoverflow.com/questions/30711327/why-device-tree-structure-dts-file-is-needed-both-in-bootloader-and-kernel-sou).
The first complication I have is that my [manufacturer-dervied] U-Boot doesn't
seem to compile a dtb - instead the manufacturer just uses the one built with
the kernel. I don't mind this too much - I don't particularly need a separate
dtb to be built within U-Boot, and its arguably easier to *not* have to
maintain two sets of sources.
However this does aggravate the uboot-sign'ing, since there's no .dtb for
kernel-fitimage.bbclass to use ("Step #7").
Is there some means already hooked into the class(es) whereby I can easily have
the kernel dtb used in 'Step #7' instead?
I thought I might be able to do this by setting UBOOT_DTB_IMAGE but it looks
like the kernel's dtb hasn't yet, at this point in the build sequence, been
installed into ${DEPLOYDIR}. Should I be aiming to make use of 'EXT_DTB'?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
