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-b..., 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/951e5294f14196a502e7fe238c23c49de49... [2] https://github.com/siemens/u-boot/blob/951e5294f14196a502e7fe238c23c49de49b8...