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

[Alexandre TORGUE]

Hi Guys

On 3/11/21 5:11 PM, Marek Vasut wrote:
> On 3/11/21 3:41 PM, Ahmad Fatoum wrote:
>> Hello,
> 
> Hi,
> 
>> On 11.03.21 15:02, Alexandre TORGUE wrote:
>>> On 3/11/21 12:43 PM, Marek Vasut wrote:
>>>> On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
>>>>> 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.
>>>>
>>>>> 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.
>>>>
>>>>> 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.
> 
> That sounds good and it is something e.g. R-Car already does, it merges 
> DT fragment from prior stages at U-Boot level and then passes the result 
> to Linux.
> 
> So on ST hardware, the same could very well happen and it would work for 
> both non-ATF / ATF / ATF+TEE options.

Even this solution sounds good but we are currently not able to do it in 
our TF-A/u-boot so not feasible for the moment. So we have to find a 
solution for now. Create a new dtb can be this solution. Our internal 
strategy is to use scmi on our official ST board. It will be a really 
drawback to include a "no-scmi.dtsi" in DH boards (for example) and to 
create a stm32mp157c-noscmi-dk2.dts ?