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-g...@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/
