On 3/11/21 12: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. 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 ?
It could work, as long as all users are reminded to change their build
scripts to pick up a "-noscmi.dtb". I suspect that if this were the case
we'll see quite a few bug reports saying "stm32mp1 no longer boots with
kernel v5.13".
I didn't think of this originally, though u-boot already does the DTB
patching for OPTEE reserved memory regions. It's not too hard to also
patch in the SCMI clocks at boot. In u-boot's case, runtime detection
might even be feasible.
Alex
