• State Suggested Answer
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 348 subscribers
  • Views 1142 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SError interrupt due to LDAXRB instruction when disable cache on NXP ls1046a

Tony Tu

Hi Experts

My code runs in EL3 on ls1046a RDB in bare mental environment. Here are the focus code after start up.

Step 1: Disable data cache, the the sctlr_el3 is changed from 0x00c5183d to 0x00c51839

Step 2: Update a global variable.

Step 3: do {} while (atomic_flag_test_and_set(&gIRQpRrintmutex));

0000000080005a68: adrp x0, 0x8002e000 <__global_locale+120>
0000000080005a6c: add x0, x0, #0x1b8
0000000080005a70: mov w1, #0x1 // #1
0000000080005a74: ldaxrb w2, [x0]

SError interrupt happened in Step 3: when execute "ldaxrb w2, [x0]" as the resister value as below:

ESR_EL3: 0xbf000002

ELR_EL3: 0x0000000080005a74

If not disable cache as in the step 1, the code execute well.

Any suggestion to fix the SError interrupt?

Parents
  • 0

    My first thought is that the target memory doesn't support exclusives.

    The LDAXRB is a type of load-exclusive.  Load exclusives perform a "regular" load, but also set up the Exclusive Monitor so a later Store-Exclusive can check it,

    For cacheable-addresses, the Exclusive Monitor function is usually carried out in the caches.   For non-cacheable addresses (or when the cache is disabled) the core requires the monitoring to be done in memory system, and will signal this on the bus.  That relies on the memory system supporting exclusives, and supporting them for the accessed address.

    You could test this theory by temporarily replacing the Exclusive-load with a regular load to see if the Error goes way.  (That's not a long term solution, but a good test)

    If that is the problem, you'll need to check the NXP docs for information on which addresses do/don't support non-cacheable exclusives.  I'd expect the info to be in the data sheet somewhere.

Reply
  • 0

    My first thought is that the target memory doesn't support exclusives.

    The LDAXRB is a type of load-exclusive.  Load exclusives perform a "regular" load, but also set up the Exclusive Monitor so a later Store-Exclusive can check it,

    For cacheable-addresses, the Exclusive Monitor function is usually carried out in the caches.   For non-cacheable addresses (or when the cache is disabled) the core requires the monitoring to be done in memory system, and will signal this on the bus.  That relies on the memory system supporting exclusives, and supporting them for the accessed address.

    You could test this theory by temporarily replacing the Exclusive-load with a regular load to see if the Error goes way.  (That's not a long term solution, but a good test)

    If that is the problem, you'll need to check the NXP docs for information on which addresses do/don't support non-cacheable exclusives.  I'd expect the info to be in the data sheet somewhere.

Children