[OE-core] [OE-Core][PATCH] kernel-fitimage: uboot-sign: Check UBOOT_DTB_BINARY before adding deps

[Michael Scott]

Hi Richard,

On 6/12/19 11:02 AM, Alex Kiernan wrote:
> On Wed, Jun 12, 2019 at 10:59 AM Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>> On Wed, 2019-06-12 at 09:15 +0100, Alex Kiernan wrote:
>>> Since UBOOT_DTB_BINARY empty means we don't need to inject signatures
>>> into the U-Boot DTB, we can remove the dependencies between consumers
>>> of
>>> these two classes and resolve a circular dependency between u-boot
>>> and
>>> kernel.
>>>
>>> Signed-off-by: Alex Kiernan <alex.kiernan at gmail.com>
>>> ---
>>>
>>>   meta/classes/kernel-fitimage.bbclass | 2 +-
>>>   meta/classes/uboot-sign.bbclass      | 2 +-
>>>   2 files changed, 2 insertions(+), 2 deletions(-)
>> Really wish we had tests and documentation for these classes...
>>
> I know... I have a dread anytime anyone touches it, me included... I
> sat on this change for a couple of weeks too.
>
> The truth is the pair of them are fragile and hopelessly intertwined,
> but without tests they're never going to get rewritten, so I might try
> and take some of that on (or get someone here to do it) as I still
> have multiple issues with them - signing doesn't really work the way I
> want, I still have a circular dependency I've not tracked down,
> doubtless other things I can't immediately bring to mind.
>
> If we were to add some tests around it, what would you pull out as the
> simplest thing that it could do which would be valuable?

Actually, you can ignore this patch.  We debugged the actual race 
condition contributing to the confusion, and that developer will submit 
a new patch with that fix.  We can review if that patch makes more sense 
(even without tests).

The test would need to follow:

1) Is there a pub key in the u-boot.dtb (symlinked file) in the deploy 
directory and is it the same as what is generated by mkimage when 
pointing at the fitImage in the deploy directory.
2) The race condition affects the build when there is a cached step 
built incorrectly.   The cached build step injects the u-boot.dtb prior 
to it being signed.

Hopefully that makes sense,

- Mike

>
-- 
Michael Scott
Embedded Software Engineer at Foundries.io
"microPlatforms™ for Connected Products"
E: mike at foundries.io
W: https://www.foundries.io