[LS1043a] No eSDHC controller RAM access when TZASC activated

[alexandreberder]

Hello,

I'm working with a LS1043a based platform from Microsys.
Reading SMMU_IDR7 (0x21), it looks like it implements SMMUV2.1

In my setup I boot SPL responsible for loading different firmware.
This includes usual u-boot and Linux + proprietary firmware able to run as secure monitor and micro-kernel in the secure world.

The goal I want to achieve is to reserve RAM used for proprietary firmware load and runtime for secure accesses only.
To reach such property, early stage of SPL, I configure/enable TZASC to reserve last 512MB of RAM for secure access only.
While booting, I confirm that eSDHC controller is not able anymore to load proprietary firmware.

I'm then trying to enable/configure "Secure State Determination" (SSD) in SMMU, in order to indicate, eSDHC controller can act as a secure master.

It is here I meet issue, unable to configure SMMU SSD correctly to allow eSDHC reserved RAM access as soon as TZASC is activated.

From SMMU and LS1043 documents, here is what I understand:
- eSDHC is default non secure master
- SCFG_SDHC_ICID register can be programmed with so called "ICID" that shall be transmitted to SMMU each time eSDHC initiates SMMU transaction
- SMMU provides SSD address space allowing to build a SSD index table with programmable/non programmable bits indicating type of SMMU transaction (e.g secure or non secure) for a given index.
- SSD memory space is divided in 1024bits areas, each areas corresponding to a TBU
- I have 4 TBUs on my SMMU: TBU0 to TBU3
- TBU3 is used for eSDHC transactions

- programming both SCFG_SDHC_ICID and corresponding SMMU SSD register shall allow SMMU to accept secure transaction for eSDHC controller.

In SMMU Architecture Specification, regarding SMMU SSD address space, it is written:
- "Software can detect programmable bits by using a read-modify-write sequence."
Playing read-modify-write sequence, I found (at least this is what I understand) that I have only 4 programmables bits, one per TBU, so as 1 bit always secure, also one per TBU and all bits not modified when writting them thus indicating "always non secure transaction" for corresponding index.
Regarding SMMU SSD address space:
- at offset 0x0 (TBU0 ?): bit0 is always secure, bit 1 is programmable
- at offset 0x80 (TBU1 ?): same results
- at offset 0x100 (TBU2 ?): same results
- at offset 0x180 (TBU3 ?): same results

I kept all programmable and default SSD indexes to "secure" and tried to "play" with SCFG_SDHC_ICID value with no success.

I think I miss good value for SCFG_SDHC_ICID or something else in SMMU config to allow eSDHC to perform secure SMMU transactions.

Any help/clarifications welcome here.

Thanks in advance.