Messages in this thread | | | Subject | Re: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode | From | Marek Vasut <> | Date | Thu, 11 Mar 2021 21:09:40 +0100 |
| |
On 3/11/21 7:10 PM, Alexandre TORGUE wrote: > 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.
Why not ? U-Boot is perfectly capable of merging prior stage DT and DT loaded from elsewhere. See R-Car3 for example.
> 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 ?
I would highly prefer the SCMI to be opt-in, not opt-out.
But still, isn't it possible to auto-detect the board configuration in Linux and pick the clock enumeration based on that automatically ?
| |