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

Jan Kiszka jan.kiszka at siemens.com
Mon Sep 13 18:10:09 CEST 2021


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


More information about the U-Boot mailing list