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/ -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
