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

[Jan Kiszka]

On 13.08.20 14:12, Jan Kiszka wrote:
> 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.

Just updated the branch to use binman for the flash image and also for
replacing u-boot.its [1][2]. However, I still don't see how to use it
for adding a firmware image into the fit parts AND finding it later on
from U-Boot proper. Adding Simon, in case he has some idea.

Jan

[1]
https://github.com/siemens/u-boot/commit/951e5294f14196a502e7fe238c23c49de49b8e29
[2]
https://github.com/siemens/u-boot/blob/951e5294f14196a502e7fe238c23c49de49b8e29/arch/arm/dts/iot2050-boot-image.dtsi

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