Sc59x smpu support

[ozan956]

One note,

These all works:

• Driver loads and initializes correctly
• Hardware violation detection works (proven with Boot ROM test)
• Transaction ID capture works: BDTLS = 0x00028902
• Bus error detection works: STAT.BERR sets correctly
• Address logging works: BADDR captures fault address

And these not:

• Cannot access SMPU-protected memory without SError abort
• Interrupts never fire
• STAT.IRQ never sets, only STAT.BERR

I am investigating that issue, first I thought it is related with the SECURECTL (only secure accesible registers) but probably its deeper than that.

PR Type

• Bug fix (a change that fixes an issue)
• New feature (a change that adds new functionality)
• Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

• I have conducted a self-review of my own code changes
• I have compiled my changes, including the documentation
• I have tested the changes on the relevant hardware
• I have updated the documentation outside this repo accordingly
• I have provided links for the relevant upstream lore

[qasim-ijaz]

several register/bit macros seem unused I assume this is because it's still a work in progress

[ozan956]

Yes, secure side is another discussion tho. Not sure how to deal with them. These registers should be considered with SPU.

[ozan956]

For manual testing, here are the commands that I have used/been using.

1 - On the U-Boot side, we should do:

mw.l 0x31007800 0x00000504
mw.l 0x31083800 0x00000504
mw.l 0x31084800 0x00000504
mw.l 0x31085800 0x00000504
mw.l 0x31086800 0x00000504
mw.l 0x310A0800 0x00000504
mw.l 0x310A1800 0x00000504

This is just to set SECURECTL to enable non secure read write. I was also curious about whether they are persistent.

2 - Then we can test a memory that is already read only.

# Configure SMPU2
devmem 0x31083000 32 0x00000009 

# Clear any previous status
devmem 0x31083004 32 0xFFFFFFFF

# RADDR[0]: Boot ROM base address
devmem 0x31083024 32 0x20200000

# RIDA[0]: Fake ID that cannot be matching any real hardware
devmem 0x31083028 32 0x00001FFF

# RIDMSKA[0]: Match all 13 bits (exact match, for the filter mask)
devmem 0x3108302C 32 0x00001FFF

# RCTL[0]: EN=1, SIZE=4 (64KB), RPROTEN=1, WPROTEN=1
devmem 0x31083020 32 0x00000909

# Trigger violation by writing to Boot ROM
devmem 0x20200000 32 0xADADADAD

# Check results
devmem 0x31083004 32
# Expected: 0x00000004 (BERR bit set)
devmem 0x31083010 32
# Expected: 0x20200000
devmem 0x31083014 32
# Expected: transaction ID

3 - Or, we can also test with SMPU9 on ddr.

# First, test that memory is accessible without SMPU
devmem 0x9E100000 32 0x12345678
devmem 0x9E100000 32
# Should read back: 0x12345678

# Configure SMPU9 instance
devmem 0x310A0000 32 0x00000009

# Clear status
devmem 0x310A0004 32 0xFFFFFFFF

# RADDR[0]: DDR test address
devmem 0x310A0024 32 0x9E100000

# RIDA[0]: Block with fake ID
devmem 0x310A0028 32 0x00001234

# RIDMSKA[0]: Exact match
devmem 0x310A002C 32 0x00001FFF

# RCTL[0]: EN=1, SIZE=6 (256KB), RPROTEN=1, WPROTEN=1
devmem 0x310A0020 32 0x00000D09

# Trigger violation
devmem 0x9E100000 32 0xBADC0DE0

# Check results
devmem 0x310A0004 32
# Expected: 0x00000004 (BERR) or 0x00000001 (IRQ)
devmem 0x310A0008 32
# Expected: 0x9E100000 (if IRQ) or check BADDR below
devmem 0x310A000C 32
# Expected: non-zero with transaction ID
devmem 0x310A0010 32
# Expected: 0x9E100000 (if BERR)
devmem 0x310A0014 32
# Expected: non-zero with transaction ID

Third one did not work as expected for me. Thats the part I am investigating.
There are other tests, but these two are the ones I am using mostly.

[ozan956]

Bit more on secure control registers:

The driver includes an adi,secure-access device tree property that controls whether the driver attempts to write SMPU SECURECTL registers. This property is currently reserved for future use and should NOT be set in production device trees.

SMPU instances have security registers at offset 0x800+ including SECURECTL. By default, SMPU instances are configured as secure slaves in the System Protection Unit (SPU). This means only secure privileged code can access these registers.

In the future, if SPU is configured to make SMPU instances non-secure slaves (SPU_SECUREP.SSEC=0), the Linux driver running in non-secure EL1 could potentially write SECURECTL registers. The adi,secure-access property is reserved for this use case.

IN current status, we should not set adi,secure-access property. The driver cannot write SECURECTL from Linux because kernel runs in non-secure EL1 mode and SMPU instances are secure slaves by default.

According to Errata 20000003, non-secure slaves cannot access secure slave registers. This errata is not the actual reason we cannot access SECURECTL currently. The actual reason is standard security with SMPU as a secure slave. The errata only matters if we configure SMPU as non-secure slave in the future.