UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor solomon71
Visitor
9,702 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
Xilinx Employee
Xilinx Employee
13,068 Views
Registered: ‎07-31-2008

Re: an exclusive access ldrex/strex question

Jump to solution

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.

8 Replies
Xilinx Employee
Xilinx Employee
9,692 Views
Registered: ‎07-31-2008

Re: an exclusive access ldrex/strex question

Jump to solution

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
Visitor solomon71
Visitor
9,690 Views
Registered: ‎01-19-2014

Re: an exclusive access ldrex/strex question

Jump to solution
Thanks, Peter!
1. L1 cache is enabled
2. Yes, it is DDR memory
0 Kudos
Xilinx Employee
Xilinx Employee
13,069 Views
Registered: ‎07-31-2008

Re: an exclusive access ldrex/strex question

Jump to solution

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.

Visitor solomon71
Visitor
9,644 Views
Registered: ‎01-19-2014

Re: an exclusive access ldrex/strex question

Jump to solution
Got it. Many thanks to you, Peter!
0 Kudos
Highlighted
Visitor samuele.m
Visitor
8,824 Views
Registered: ‎04-07-2014

Re: an exclusive access ldrex/strex question

Jump to solution

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
Xilinx Employee
Xilinx Employee
8,737 Views
Registered: ‎10-11-2011

Re: an exclusive access ldrex/strex question

Jump to solution
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
Tags (1)
Visitor samuele.m
Visitor
8,641 Views
Registered: ‎04-07-2014

Re: an exclusive access ldrex/strex question

Jump to solution

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

 

0 Kudos
Visitor ablaz77
Visitor
5,017 Views
Registered: ‎11-13-2014

Re: an exclusive access ldrex/strex question

Jump to solution
Hi,
Can you provide the values you used in your working setup for the twor CPUs?
Thanks
0 Kudos