On 02/11/2022 10:59, Patrick DELAUNAY wrote:
Hi,
On 11/1/22 08:26, Srinivas Kandagatla wrote:
On 28/10/2022 15:52, Patrick Delaunay wrote:
For boot with OP-TEE on STM32MP13, the communication with the secure
world no more use STMicroelectronics SMC but communication with the
BSEC TA, for data access (read/write) or lock operation:
- all the request are sent to OP-TEE trusted application,
- for upper OTP with ECC protection and with word programming only
each OTP are permanently locked when programmed to avoid ECC error
on the second write operation
Signed-off-by: Patrick Delaunay <patrick.delaunay@xxxxxxxxxxx>
---
For some reason I pushed this patch without a full review, This is now reverted from nvmem-next.
Ok
Why not add TEE client based new driver instead of ifdefing around this driver? Also I see there is not much common across both drivers anyway.
I hesitate between the 2 solutions. I choose this update to handle the STM32MP15 support with OP-TEE.
How are you to handing this?
For backward compatibility reason the same driver STM32 ROMEM associated to compatible "st,stm32mp15-bsec" should be kept.
- the lower OTP can directly accessible by Linux (the IP is not secured) => boot with SPL
Can we determine this at runtime?
- the upper OTP and the write operation are requested by STMicroelectronics SMCs
=> boot with TF-A SPMIN and old OP-TEE (before migration to STM32 BSEC PTA)
But in the future OP-TEE the access to OTP should be also done with STM32 BSEC PTA...
Given that we have only one compatible for these two type of combinations how are you planning to deal with both the cases and still be backward compatible?
--srini
I can manage this compatibility by detection in STM32 romem driver if the booth access are managed in the same driver.
This patch can be added in the serie to understood the detection mechanism.