| Message ID | 20240705164833.2386549-5-d-gole@ti.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | Low Power Mode: Package TIFS Stub in BeaglePlay | expand |
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-gole@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 >
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-gole@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?
On 16:05-20240718, Dhruva Gole wrote: > 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-gole@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? Yeah - looks like we might need more split up here. we want this to appear only on relevant platforms.
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. OR
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-gole@ti.com> --- doc/board/ti/k3.rst | 11 +++++++++++ 1 file changed, 11 insertions(+)