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

[Sebin Francis]

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-c6905ef29f20@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