On 28/06/24 23:10, Nishanth Menon wrote:
On 19:39-20240628, Sebin Francis wrote:
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.
[...]
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.
OK - so the memory map we are copying to is already reserved in device
tree?
See this thread[1] - we are arguing here that the reserved region is
meant for bootloader to fill up and keep protected. DT itself from
kernel is shared between u-boot and kernel OF_UPSTREAM.
Now, the consumer of the binary is DM, the load area is already part of
carveout for DM, it sounds like it should have been packaged with DM
itself instead of making the packaging problem the problem that everyone
image creation system has to solve - not to mention signing etc..
Why not merge this with DM?
[1] https://lore.kernel.org/all/59c391a7-c6fe-4b04-891a-c6905ef29...@ti.com/
For HS-FS device we need to sign the fs-stub with customer key. DM firmware
cannot have a component which is signed using customer key.
Thanks
Sebin
