On Mon, 13 Sept 2021 at 17:36, Tom Rini trini@konsulko.com wrote:
On Mon, Sep 13, 2021 at 04:59:35PM +0200, Jan Kiszka wrote:
On 13.09.21 16:56, Tom Rini wrote:
On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote:
On 13.09.21 14:34, Tom Rini wrote:
On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote:
On 11.09.21 02:10, Tom Rini wrote: > On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: > >> From: Jan Kiszka jan.kiszka@siemens.com >> >> This allows to use the watchdog in custom scripts but does not
enforce
>> that the OS has to support it as well. >> >> Signed-off-by: Jan Kiszka jan.kiszka@siemens.com > > Sorry for the late reply. This causes CI to fail: > Building current source for 1 boards (1 thread, 16 jobs per thread) > aarch64: + iot2050 > +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary
is non-functional
> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might
be non-functional
> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input
path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) (cwd='/tmp/iot2050/.bm-work/iot2050')
> +(iot2050) make[1]: *** [all] Error 1 > +(iot2050) make: *** [sub-make] Error 2 > 0 0 1 /1 iot2050 > > And needs to be handled like ATF/OPTEE/etc where CI can build but
throw
> a "THIS WILL NOT RUN CORRECTLY" type warning to the user. >
I was about to sent an update anyway - time passed, and now we even
have
support for the next generation integrated from the beginning. But related upstream DT changes are not yet merged.
OK.
But back to this issue: How can CI be fed with all those required binaries? The build makes no sense in their absence.
To be clearer, CI isn't fed all of the binaries, we just use
/dev/null
in that case and try and make it clear it won't boot. K3 isn't a
good
example here, but I think sunxi uses binman and handles this same
class
of problem?
I'm seeing it additionally carrying a "missing-msg" property, but that alone (even with missing-blob-help updated) does not make the build pass. It rather seems I'm missing some "allow_missing" property for
that
image, but even reading the code gives no clue yet how to achieve
that.
Yet another binman mystery.
You might also need a new file in tools/binman/etype/ ? Also, it will have a non-zero exit status still, but with a value of 101 which we check for and know that's "binary blob missing" and so OK to allow CI
to
pass on.
Err, that doesn't sound like binman is making my life easier. Why can't a I simple do something like
k3-rti-wdt-firmware { type = "blob"; load = <0x82000000>; blob { filename = CONFIG_WDT_K3_RTI_FW_FILE; missing-msg = "k3-rti-wdt-firmware"; allow_missing; }; };and be done?
Sounds like a good idea, and I'm not quite sure what's missing to go from where we are today to there. I might be missing something myself.
If that entry is located in a DT for U-Boot consumption why not, but in the DT that is associated to a platform that is passed to the OS, that sounds like a practice to avoid as this does not describe hardware. Thinking compatibility, is the filename/filepath really OS independent ?
-- Tom