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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 4455 bytes --]

On Mon, Sep 13, 2021 at 06:08:10PM +0200, François Ozog wrote:
> 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 ?

So, here's one of those cases where we aren't really talking about the
runtime device tree so much as how we configure the build.  binman is
how we assemble the assorted binaries in to a functional blob for a
given platform without having to write a new tool for every SoC.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]