[yocto] Understanding dtb generation wrt uboot (with signing)

[Colin Helliwell]

> On 27 July 2017 at 17:48 colin.helliwell at 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'?