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

From: Jan Kiszka <jan.kiszka@siemens.com>
To: Tom Rini <trini@konsulko.com>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Le Jin <le.jin@siemens.com>,
	Bao Cheng Su <baocheng.su@siemens.com>,
	Nian Gao <nian.gao@siemens.com>,
	Chao Zeng <chao.zeng@siemens.com>,
	Lokesh Vutla <lokeshvutla@ti.com>
Subject: Re: [PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it
Date: Mon, 13 Sep 2021 16:31:37 +0200	[thread overview]
Message-ID: <5d515165-6f39-285d-7bd1-a412ed468cf4@siemens.com> (raw)
In-Reply-To: <20210913123445.GB12964@bill-the-cat>

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.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux