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
