On 6/12/19 3:21 PM, richard.pur...@linuxfoundation.org wrote:
On Wed, 2019-06-12 at 14:17 -0700, Michael Scott wrote:
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).
Well, this patch merged earlier this evening as tested passed. Is that
a problem?
Not a problem at all. I believe we also kept this change when we
debugged the actual race condition.
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.
That does help explain the problem you were seeing and does some like
something we could/should be testing for.
Yes if possible the test should run #1 above - 3 ways: 1) clean cache
for kernel/u-boot/u-boot tools, 2) cached run for kernel/u-boot/u-boot
tools and 3) cached for kernel/u-boot tools, but changed u-boot
(invalidate cache?)
- Mike
Cheers,
Richard
--
Michael Scott
Embedded Software Engineer at Foundries.io
"microPlatforms™ for Connected Products"
E: m...@foundries.io
W: https://www.foundries.io
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
