binman and faked blobs failures
Hey,
So here's a problem I have. Today if I'm in a branch that has a commit that's not in it's upstream branch (so lets say I'm testing a bunch of patches I grabbed from patchwork in a local branch that knows master is the upstream) and I do:
export SOURCE_DATE_EPOCH=1649712313 ./tools/buildman/buildman -o /tmp/chromebook_samus -devl --step 0 -b testing -SBC chromebook_samus Building 2 commits for 2 boards (2 threads, 8 jobs per thread) 01: linux/mtd/mtd.h: Add <dm/ofnode.h> x86: w+ chromebook_samus +(chromebook_samus) Image 'main-section' is missing external blobs and is non-functional: intel-descriptor intel-me intel-refcode intel-vga intel-mrc +(chromebook_samus) Image 'main-section' has faked external blobs and is non-functional: descriptor.bin me.bin refcode.bin vga.bin mrc.bin +(chromebook_samus) +(chromebook_samus) Some images are invalid 02: HACK x86: + chromebook_samus +(chromebook_samus) binman: Node '/binman/rom/intel-descriptor': Cannot find Intel Flash Descriptor (FD) signature +(chromebook_samus) make[1]: *** [Makefile:1101: all] Error 1 +(chromebook_samus) make: *** [Makefile:177: sub-make] Error 2 01: linux/mtd/mtd.h: Add <dm/ofnode.h> x86: w+ chromebook_samus_tpl +(chromebook_samus_tpl) Image 'main-section' is missing external blobs and is non-functional: intel-descriptor intel-me intel-refcode intel-vga intel-mrc +(chromebook_samus_tpl) Image 'main-section' has faked external blobs and is non-functional: descriptor.bin me.bin refcode.bin vga.bin mrc.bin +(chromebook_samus_tpl) +(chromebook_samus_tpl) Some images are invalid 02: HACK x86: + chromebook_samus_tpl +(chromebook_samus_tpl) binman: Node '/binman/rom/intel-descriptor': Cannot find Intel Flash Descriptor (FD) signature +(chromebook_samus_tpl) make[1]: *** [Makefile:1101: all] Error 1 +(chromebook_samus_tpl) make: *** [Makefile:177: sub-make] Error 2 0 2 2 /4 chromebook_samus_tpl Completed: 4 total built, duration 0:00:31, rate 0.13
Note that nothing changed for the board but on the second build now the faked blob is unhappy and causes a failure message that I don't see the first time, and probably shouldn't see this time either? This is a problem for me in that it's on most x86 boards and so makes it easier to miss other real build failures in my testing.
On 12/04/2022 00:28, Tom Rini wrote:
[...]
Note that nothing changed for the board but on the second build now the faked blob is unhappy and causes a failure message that I don't see the first time, and probably shouldn't see this time either? This is a problem for me in that it's on most x86 boards and so makes it easier to miss other real build failures in my testing.
Yeah, the root cause here is that fake files created in the first build are interpreted as actual files in subsequent builds. Simon already added a TODO in binman.rst for cleaning them up, I intend to give it a try but didn't have the time to experiment.
Hi,
On Sat, 16 Apr 2022 at 11:30, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
On 12/04/2022 00:28, Tom Rini wrote:
[...]
Note that nothing changed for the board but on the second build now the faked blob is unhappy and causes a failure message that I don't see the first time, and probably shouldn't see this time either? This is a problem for me in that it's on most x86 boards and so makes it easier to miss other real build failures in my testing.
Yeah, the root cause here is that fake files created in the first build are interpreted as actual files in subsequent builds. Simon already added a TODO in binman.rst for cleaning them up, I intend to give it a try but didn't have the time to experiment.
Yes, this is:
- Put faked files into a separate subdir and remove them on start-up, to avoid seeing them as 'real' files on a subsequent run
I believe it is quite easy, since we create the fake files in a single place - check_fake_fname() - and can simply add another subdir into the path we create (e.g. 'fakeblobs/'. Then, when binman, it can remove that subdir, in control.py before tools.finalise_output_dir() is called. The test for it should not be too bad either.
Alper if you have time, give it a crack. Otherwise I can look at it, but will be out for a few weeks so not sure when.
Regards, Simon
participants (3)
-
Alper Nebi Yasak -
Simon Glass -
Tom Rini