On 13.09.21 17:36, Tom Rini 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.kis...@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.kis...@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. >
Works now, with "blob-ext" rather than "blob". binman is actually called with --allow-missing. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux