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-b..., not just u-boot.dtb.
Jan