colinh
Posts: 95
Joined: Tue Dec 03, 2013 11:59 pm
Location: Munich

Memory barriers...

Sat Feb 22, 2014 7:41 pm

The BCM2835 SOC document (p.7) is actually quite clear about when and where memory barriers are required. However, it refers to "memory write barriers" and "memory read barriers".

The ARM v6 ARM talks about DataMemoryBarrier (DMB) and DataSynchronizationBarrier (DSB), noting that the DSB used to be referred to historically (ie. it's deprecated) as DataWriteBarrier (DWB).

Is it thus correct to place a MCR p15,0,r0,c7,c10,5 // DMB instruction wherever the Broadcom doc says one should put a memory read or write barrier?

rst
Posts: 497
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Memory barriers...

Mon Feb 24, 2014 11:35 am

This is a real interesting question because complex bare metal programming on the Raspberry Pi is impossible without a sufficient answer. One can build a world of software but without a barrier in the right place it will not be stable.

You may have a look at this: http://www.raspberrypi.org/phpBB3/viewt ... =63&t=1410

Rene

dwelch67
Posts: 1002
Joined: Sat May 26, 2012 5:32 pm

Re: Memory barriers...

Mon Feb 24, 2014 7:29 pm

http://infocenter.arm.com/help/index.js ... 14041.html

Has info on this as well. Basically they are both saying the same thing. If you CARE about things being in order then you need to use a memory barrier, if you dont then dont. With respect to this chip the way I am reading things...basically IMO...If for example you are reading a byte from the uart rx register, and want to write it to some other peripheral, you cant just do a load then a store, you need a barrier in between because the arm and/or memory controller may do things out of order. I assume a DSB or DMB or ISB will work in that case from ARMs description.

with bcm and arm both mentioning this it should be possible to create an experiment that demonstrates this out of order behavior...

David

rst
Posts: 497
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Memory barriers...

Tue Feb 25, 2014 8:11 am

Thank you David! I think your explanation and the knowledge base article make it clearer now. I have to read it carefully.

Rene

colinh
Posts: 95
Joined: Tue Dec 03, 2013 11:59 pm
Location: Munich

Re: Memory barriers...

Thu Feb 27, 2014 9:08 pm

I haven't read the linked articles yet, but the way I understood the BCM doc was that if you do a load from the UART and immediately after that, a load from another peripheral, like the system timer, or gpio, then the data might arrive out of order and the register where you wanted the uart data, will contain the system time, or whatever (and vice versa).

The way I read the ARM docs was that ... I didn't fully understand it, to be honest. :D The ARM ARM and the 1176 TRM explain things (DMB and DSB) differently.

One needs to know though, that when you issue a LDR/STR (or LDM/STM) the load/stores are started, but the next instruction can (sometimes) execute immediately, without the load/store having finished. (see TRM 16 - Cycle Timings and Interlock Behaviour)

When writing memory-mapped registers (as opposed to just memory) one is often interested in the side effects. These might be very relevant to code executing after the load/store. In such a case one can use a DSB which ensures that the load/store instruction has actually completed, before the following instructions are executed.

Regarding memory agents and globally visible etc, that's obviously important for multi-processor systems...

Return to “Bare metal, Assembly language”