cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
solomon71
Visitor
Visitor
11,089 Views
Registered: ‎01-19-2014

an exclusive access ldrex/strex question

Jump to solution

Hi all,

 

On Zynq7000 board, I run into the following issue. Does anyone know what's the root cause?  Thanks a lot.

If L2 cache(PL310) is disabled, it is successfull when performing an exclusive access to no-shareable normal write-through memory.

If L2 cache(PL310) is enabled, it always fail when performing an exclusive access to no-shareable normal write-through memory.

 

0 Kudos
1 Solution

Accepted Solutions
ryserp
Xilinx Employee
Xilinx Employee
14,455 Views
Registered: ‎07-31-2008

I talked to our exclusive memory access expert. Further down find her answer. A little bit of background first, though.

 

In Zynq there are exclusive monitors on the L1 cache and the DDR (L3). There is no exclusive monitor on the L2 cache. With that a user has to take care of making sure that the data accessed is not missed in L1 but hit in L2.

 

Now for the details from our expert:

----

This is the requirement for L1/DDR exclusive access:

 

To use the L1 exclusive monitor, the addressed MMU region must be set to be inner cacheable and inner cache write-back with write-allocate. This allows an address targeted by a particular exclusive access to always be allocated to L1 cache.

 

To use the L3 exclusive monitor, the access must not terminate at the APU L2 cache. From the ARM CPU perspective, this means the address must be shareable, normal and non-cacheable. Also, the L2 cache controller Shared Override option [bit 22 in  L2 Auxiliary Control Register.] must be set in the aux control register. By default in the APU L2 cache controller, any non-cacheable shared reads are treated as cacheable non-allocatable, while non-cacheable shared writes are treated as cacheable write-through/no write-allocate. The L2 cache controller Shared Override option in the PL310 aux control register overrides this behavior and prevents allocation into L2 cache.

 

Solomon71 has “no-shareable normal write-through memory”, I think the write-through part is incorrect since that means store won't end in L1 cache.

---


The upcoming update of the TRM will have an expanded chapter about load/store exclusive operation.

View solution in original post

8 Replies
ryserp
Xilinx Employee
Xilinx Employee
11,079 Views
Registered: ‎07-31-2008

Hi,

 

can you clarify two things:

1) Is the L1 cache enabled or disabled?

2) What is the target of the transaction (i.e. is it the DDR memory)?

 

- Peter

 

0 Kudos
solomon71
Visitor
Visitor
11,077 Views
Registered: ‎01-19-2014
Thanks, Peter!
1. L1 cache is enabled
2. Yes, it is DDR memory
0 Kudos
ryserp
Xilinx Employee
Xilinx Employee
14,456 Views
Registered: ‎07-31-2008

I talked to our exclusive memory access expert. Further down find her answer. A little bit of background first, though.

 

In Zynq there are exclusive monitors on the L1 cache and the DDR (L3). There is no exclusive monitor on the L2 cache. With that a user has to take care of making sure that the data accessed is not missed in L1 but hit in L2.

 

Now for the details from our expert:

----

This is the requirement for L1/DDR exclusive access:

 

To use the L1 exclusive monitor, the addressed MMU region must be set to be inner cacheable and inner cache write-back with write-allocate. This allows an address targeted by a particular exclusive access to always be allocated to L1 cache.

 

To use the L3 exclusive monitor, the access must not terminate at the APU L2 cache. From the ARM CPU perspective, this means the address must be shareable, normal and non-cacheable. Also, the L2 cache controller Shared Override option [bit 22 in  L2 Auxiliary Control Register.] must be set in the aux control register. By default in the APU L2 cache controller, any non-cacheable shared reads are treated as cacheable non-allocatable, while non-cacheable shared writes are treated as cacheable write-through/no write-allocate. The L2 cache controller Shared Override option in the PL310 aux control register overrides this behavior and prevents allocation into L2 cache.

 

Solomon71 has “no-shareable normal write-through memory”, I think the write-through part is incorrect since that means store won't end in L1 cache.

---


The upcoming update of the TRM will have an expanded chapter about load/store exclusive operation.

View solution in original post

solomon71
Visitor
Visitor
11,031 Views
Registered: ‎01-19-2014
Got it. Many thanks to you, Peter!
0 Kudos
samuele.m
Visitor
Visitor
10,211 Views
Registered: ‎04-07-2014

Hi all,

I'm "reopening" this discussion because we have a weird behaviour of ldrex/strex: we are developing two bare metal applications each running on a core of ZYNQ's Cortex; we needed a mutex and we implemented it following ARM's article "ARM Synchronization Primitives". We could not get it to work until we set the attributes of memory we use for exclusive access at 0x04de2: this should be "inner non cacheable, outer non cacheable and not shareable". If we use shareable attribute it does not work, no matter which cacheability setting we use ("it does not work" means that one application cannot "see" the other releasing the lock or both applications cannot  see the other acquiring the lock), This was quite a surprise, and we could not understand this behaviour... Any suggestion?

 

Thank you in advance!

0 Kudos
denist
Xilinx Employee
Xilinx Employee
10,124 Views
Registered: ‎10-11-2011
Did you try to change the L2CCAuxControl register in the boot.S file of the BSP for CPU0? .set L2CCAuxControl, 0x72760000 (bit 22 set to '1') instead of .set L2CCAuxControl, 0x72360000
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Tags (1)
samuele.m
Visitor
Visitor
10,028 Views
Registered: ‎04-07-2014

I just tried, and it seems to work as expected. Thank you denist!

 

0 Kudos
ablaz77
Visitor
Visitor
6,404 Views
Registered: ‎11-13-2014
Hi,
Can you provide the values you used in your working setup for the twor CPUs?
Thanks
0 Kudos