[PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it

[Tom Rini]

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 at 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 at 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210913/a1f5eb38/attachment.sig>