[PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay

[Sebin Francis]

On 28/06/24 18:33, Nishanth Menon wrote:
> On 15:02-20240628, Dhruva Gole wrote:
>> This series includes the binman related changes required to package tIFS
>> Stub to support Low Power Modes on BeaglePlay.
>> Also, based on comments from previous patch [0] documentation has been
>> added to describe small addition in boot flow as well as tispl image
>> format.
>>
>> I am aware that the new boot flow image will need to be updated in
>> other places like am62a, am62p and even other boards that use am62x.
>> However, I would like to keep this series beagleplay TIFSStub specific
>> and so I will be sending a follow up series to update other places
>> seperately if that's ok.
>>
>> Changelog:
>> * Add new image format for TISPL
>> * Add new changes in boot flow for am62 family of devices.
>>
>> [0] https://lore.kernel.org/u-boot/20240618045610.271884-1-d-gole@ti.com/
>>
>> Dhruva Gole (4):
>>    arm: dts: k3-am625-beagleplay: Package TIFS Stub
>>    doc: beagle: am62x_beagleplay: Update the boot flow to show TIFS Stub
>>    doc: beagle: am62x_beagleplay: Add TIFS Stub in image format
>>    doc: ti: k3: Add TIFS Stub documentation
>>
>>   arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 33 +++++++++++++++++++-
>>   doc/board/beagle/am62x_beagleplay.rst        |  4 +--
>>   doc/board/ti/img/boot_diagram_am62.svg       |  4 +++
>>   doc/board/ti/img/tifsstub_dm_tispl.bin.svg   |  4 +++
>>   doc/board/ti/k3.rst                          |  5 +++
>>   5 files changed, 47 insertions(+), 3 deletions(-)
>>   create mode 100644 doc/board/ti/img/boot_diagram_am62.svg
>>   create mode 100644 doc/board/ti/img/tifsstub_dm_tispl.bin.svg
>
> Maybe you can help clarify a bit. I understand from [1]
> that you are betting on timing to keep tifs stub safe. But then, why
> not plug in this firmware blob along with DM itself? that allows DM
> to manage itself the way it wants to and control it's own memory map?
> DM initialization itself takes a few ms, just because TFA is not
> touching any part of DDR does not mean that we can assume system is
> interference free, no? What if DM architecture changes such that PLL
> initialization or some other long pole item is performed prior to
> loading the tifs stub?


In Linux DT the address space in which FS stub is copied is part of DM 
firmware carve-out in DDR,
so if fs stub can get corrupted then DM also can get corrupted.

Regards
Sebin

>
> [1] https://lore.kernel.org/u-boot/20240621054337.qqjftv72ofiinlhv@dhruva/
>