lkml.org 
[lkml]   [2021]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode
From
Date
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.

\
 
 \ /
  Last update: 2021-03-11 17:13    [W:0.094 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site