On Mon, 13 Sept 2021 at 17:36, Tom Rini <tr...@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.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.
>
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
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
