Memory attribute configuration in SMMU-v3

Hi, martin,

thanks for your reply.

In fact, I do some work on arm fvp platform with cache_state_modelled=1,

1. if I set SMMU_IDR0.COHACC as 1, and cpu allocate cachable memory for queues and config constructures, the test engine works well.

2. Then, If I set SMMU_IDR0.COHACC as 0, and cpu allocate non-cachable memory for queues and config constructures, and I get an SMMU event  C_BAD_STREAMID(0x2) or C_BAD_STE(0x4).
   2.1 base on case 2, if I run fvp with cache_state_modelled=0, it also works well.

Base on case 2.1, I think the case 2 failure is resulting from cache actions other than the real streamid error(such as

a) L1STD.Span == 0
b) L1STD.Span == Reserved
c) L1STD.Span > SMMU_(S_)STRTAB_BASE_CFG.SPLIT + 1
d) The given StreamID[SPLIT - 1:0] >= 2(L1STD.Span-1)
).

So, I am not sure how to configure the queue and config memory for SMMU in case 2. Can you share some details on this case 2?

Thanks

Hi, martin,

thanks for your reply.

In fact, I do some work on arm fvp platform with cache_state_modelled=1,

1. if I set SMMU_IDR0.COHACC as 1, and cpu allocate cachable memory for queues and config constructures, the test engine works well.

2. Then, If I set SMMU_IDR0.COHACC as 0, and cpu allocate non-cachable memory for queues and config constructures, and I get an SMMU event  C_BAD_STREAMID(0x2) or C_BAD_STE(0x4).
   2.1 base on case 2, if I run fvp with cache_state_modelled=0, it also works well.

Base on case 2.1, I think the case 2 failure is resulting from cache actions other than the real streamid error(such as

a) L1STD.Span == 0
b) L1STD.Span == Reserved
c) L1STD.Span > SMMU_(S_)STRTAB_BASE_CFG.SPLIT + 1
d) The given StreamID[SPLIT - 1:0] >= 2(L1STD.Span-1)
).

So, I am not sure how to configure the queue and config memory for SMMU in case 2. Can you share some details on this case 2?

Thanks

It does sound as if the problem is down to memory coherency problems. 

Have you double checked the attributes used on the CPU for the memory?  One test would be to see whether adding a Clean to the PoC (followed by a DSB) for the memory housing the queue/ST/etc.

Hi, martin,

thanks for your reply.

I checked the attributes used on the cpu for the memory, the normal non-cacheable mair value(0x44) and the right index set to pte.

After I add an cache operation, SMMU works, and the upstream device can access memory normally.  All the listed tests have the same result on real silicon chip and fvp revc platform. details as

• I add the cache operation( to poc, dc *vac), whatever clean, invalidate, or clean and invalidate, SMMU works
• I add the cache operation just after the memory allocation, even not after the setting of STE, SMMU works
• after an error occurs, event queue can receive corresponding event, if there is no cache operation, event queue will not receive new event after the secondary error occurs.
• after an error occurs, event queue can receive corresponding event, add cache operation, event queue will receive secondary error corresponding  event after the secondary error occurs.

base on the test above, it looks like the SMMU waiting for the CPU cache operation before it do the real memory access(access PTE or wirte event queue), and SMMU uses the cpu cache operation as the synchronizing signal.

Doing cache operation to non-cacheable memory looks wired. Can you share more detailed logic rules(similar to Pseudocode in arm arch spec) deep in the SMMU IP module? And why the SMMU take the logic rules?

Thanks