On Jul 17, 2024 at 13:47:19 -0500, Nishanth Menon wrote: > On 22:18-20240705, Dhruva Gole wrote: > > Add documentation to briefly explain the role of TIFS Stub in relevant > > K3 SoC's. > > This also sheds light on why TIFS Stub isn't package with the DM firmware > > itself. > > > > Signed-off-by: Dhruva Gole <d-g...@ti.com> > > --- > > doc/board/ti/k3.rst | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst > > index 67b066a07d3a..c80060662074 100644 > > --- a/doc/board/ti/k3.rst > > +++ b/doc/board/ti/k3.rst > > @@ -193,6 +193,17 @@ online > > device resources such as power, clock, interrupts, dma etc. This > > firmware > > runs on a dedicated or multi-use microcontroller outside the security > > enclave. > > + * **TIFS Stub** - A small piece of code that helps restore the remaining > > + context and resume the TIFS firmware when resuming from Low Power Modes > > + like Suspend-to-RAM/ Deep Sleep. It is loaded into the ATCM (Tightly > > + Coupled Memory 'A' of the DM R5) during DM startup. The reason it isn't > > + merged with DM is because in HS devices we need to sign the tifs-stub > > with > > + customer key. The DM cannot have a component signed using a customer > > key > > + because a HS device customer owns the customer key and only customer > > + has the access for the customer key. Since TIFS Stub signing has to > > happen > > + from the customer side but DM is released by TI, we need to allow > > binman to > > + sign the TIFS Stub and only then package it alongside other firmwares. > > + This applies only to AM62x, AM62A and AM62P based devices. > > This implies TI is hiding DM source - we are not. TIFS stub is prop > binary (the usual issues), but can you rephrase the description above? I > do not want to go and explicitly list out the devices this section has > either..
OK. I was trying to convey was the binary is provided by TI not that its hidden. But yes I will reword it to say: .... but DM is released by TI or can be built independently by customers using the publicly available sources, we need to allow binman...... > > Futher, the way it is introduced, did you check the documentation for > other SoCs? we dont want tifs stub section to punch in for other SoCs > which dont matter. Yep, it appears wherever there's include:: ../ti/k3.rst, I will introduce few more tags between k3_rst_include_start_boot_sources and k3_rst_include_end_boot_sources to help with this. Does that make sense? -- Best regards, Dhruva Gole <d-g...@ti.com>
