Thread (36 messages) 36 messages, 8 authors, 2021-03-12

Re: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

From: Alexandre TORGUE <alexandre.torgue@foss.st.com>
Date: 2021-03-11 15:20:42

Hi Ahmad

On 3/11/21 3:41 PM, Ahmad Fatoum wrote:
Hello,

On 11.03.21 15:02, Alexandre TORGUE wrote:
quoted
On 3/11/21 12:43 PM, Marek Vasut wrote:
quoted
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
quoted
1- Break the current ABI: as soon as those patches are merged, stm32mp157c-dk2.dtb will impose to use
A tf-a for scmi clocks. For people using u-boot spl, the will have to create their own "no-secure" devicetree.
NAK, this breaks existing boards and existing setups, e.g. DK2 that does not use ATF.
quoted
2-As you suggest, create a new "secure" dtb per boards (Not my wish for maintenance perspectives).
I agree with Alex (G) that the "secure" option should be opt-in.
That way existing setups remain working and no extra requirements are imposed on MP1 users. Esp. since as far as I understand this, the "secure" part isn't really about security, but rather about moving clock configuration from Linux to some firmware blob.
quoted
3- Keep kernel device tree as they are and applied this secure layer (scmi clocks phandle) thanks to dtbo in
U-boot.
Is this really better than
#include "stm32mp15xx-enable-secure-stuff.dtsi"
in a board DT ? Because that is how I imagine the opt-in "secure" option could work.
Discussing with Patrick about u-boot, we could use dtbo application thanks to extlinux.conf. BUT it it will not prevent other case (i.e. TF-A which jump directly in kernel@). So the "least worst" solution is to create a new "stm32mp1257c-scmi-dk2 board which will overload clock entries with a scmi phandle (as proposed by Alex).
I raised this issue before with your colleagues. I still believe the correct way
would be for the TF-A to pass down either a device tree or an overlay with the
actual settings in use, e.g.:

   - Clocks/Resets done via SCMI
   - Reserved memory regions

If TF-A directly boots Linux, it can apply the overlay itself, otherwise it's
passed down to SSBL that applies it before booting Linux.
Discussing with tf-a and u-boot guys, this solution could imply hard 
synchronization between tf-a/u-boot. The most simple remains a "secure" dts.

regards
Alex
Cheers,
Ahmad
quoted
Gabriel, can you wait a bit before sending something about SCMI in dtsi, I would like to align this strategy internally.

Marek, Alex: thanks for your inputs.

Regards
Alex
quoted
quoted
The third could be the less costly.
[...]
_______________________________________________
Linux-stm32 mailing list
Linux-stm32@st-md-mailman.stormreply.com
https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help