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