[PATCH v2 0/3] watchdog: K3: Add RTI watchdog support

[Jan Kiszka]

On 11.08.20 20:01, Lokesh Vutla wrote:
> 
> 
> On 11/08/20 8:28 pm, Jan Kiszka wrote:
>> On 11.08.20 16:36, Lokesh Vutla wrote:
>>> Hi Jan,
>>>
>>> On 11/08/20 6:07 pm, Jan Kiszka wrote:
>>>> On 11.08.20 12:46, Lokesh Vutla wrote:
>>>>>
>>>>>
>>>>> On 11/08/20 4:12 pm, Jan Kiszka wrote:
>>>>>> On 11.08.20 12:33, Lokesh Vutla wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 23/06/20 4:45 pm, Jan Kiszka wrote:
>>>>>>>> This brings watchdog support for the TI K3 SoCs, derived from the Linux
>>>>>>>> kernel, augmented with firmware loading as needed on the AM65x.
>>>>>>>>
>>>>>>>> Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream
>>>>>>>> support will be posted soon).
>>>>>>>>
>>>>>>>> Changes in v2:
>>>>>>>>      - keep watchdog powered when handing over to Linux
>>>>>>>>      - drop unneeded explicit power-on
>>>>>>>>      - account for RTI firmware locking the power domain
>>>>>>>
>>>>>>> Patch 1 and 3 merged applied.
>>>>>>>
>>>>>>
>>>>>> Thanks. Still taking workable suggestions for loading the firmware.
>>>>>
>>>>> FIT image is the one that I can think off. Since SPL is loading the FIT image,
>>>>> SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot
>>>>> can start the remote cores using this info.
>>>>
>>>> OK, just the ensure I got the idea correctly:
>>>>
>>>>    - extend struct spl_handoff or arch_spl_handoff with the fit image
>>>>      loadaddr that spl is processing
>>>
>>> Yes
>>>
>>>>
>>>>    - stick the watchdog firmware into the u-boot proper fit image
>>>>      (generated by tools/k3_fit_atf.sh or shipped via the board folder, as
>>>>      in our case)
>>>
>>> IMHO, not via board folder. k3_fit_atf is used to generate a53 spl images. May
>>
>> Yeah, right. We also have a fit image for u-boot proper, that confused me.
>>
>>> be create a new one that packs fit image with u-boot and firmware. Or can you
>>> check if binman in u-boot works for you?
>>
>> You mean, pack the u-boot proper with the firmware? Then we could stick the
>> result in an signed fit image when needed. And I could read the offset of the
>> firmware from the generated dtb - provided binman can deal with multiple
>> configurations like we have.
> 
> If that is possible I am okay with it.
> 

I will definitely try to switch our SPI flash image generation to 
binman, but I didn't figure out how to use it for appending a binary to 
u-boot-nodtb.bin.

To my current understanding of the tool, it is only able to write back 
the offsets of image elements to a single dtb. That breaks when you have 
multiple configurations to choose from. I also have to handle 
https://github.com/siemens/u-boot/blob/jan/iot2050/board/siemens/iot2050/u-boot.its, 
not just u-boot.dtb.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux