1. GDMA writes to the ACP port and is backpressed, resulting in GDMA reads being backpressed. The memory channel on the GDMA read chip and the memory channel on the A72 read chip are the same channel, so the memory operation on the A72 read chip is also blocked, and the A72 read is blocked, causing ACP writes to be unable to be released, forming a deadlock
2. The A72 Core has been sending prefetch read operations (0xae0, 0x2b2) to noncpu, resulting in ACP writes being unable to obtain arbitration. The PC pointer has been stuck at 0x51c7dc
add x0,x0,#0xae4 -> PC hanging at 0x51c7dcldr w0,[x0]add x1,x1,#0xae0ldr w1,[x1] -> speculative read 0xae0udiv w2,w0,w1mul w1,w2,w1sub w0,w0,w1and w0,w0,#0x1FFFFand w1,w0,#0xFFFFldrh w0,[sp,#34] -> speculative read 0x2b2
3. On chip memory is a device attribute
After analyzing RTL, there are two solutions:
1) Configure the on-chip memory MMU attribute to write back write allocate read allocate. This will generate a pass signal, mask prefetch reads, and unblock the ACP port write path
2) Configure L2 Auxiliary Control Register bit [1] to enable the replay threshold timeout attribute. After waiting for a certain amount of time, ACP port writes will obtain arbitration rights, and the ACP port write path will be unblocked
My question is, are the above two solutions the real solutions?
If so, I would like to know the design intention: why must the instruction area be set to cacheable in order to avoid ACP port deadlock? If there is cache miss or other device access, is there also a possibility of hanging? Is there any other side effect of configuring L2 Auxiliary Control Register bit [1]?
If not, are there any other solutions?
Hello, I recommend you raise an official support case from the support menu above.
I do not believe this level of question can be answered in a public forum.