User avatar
Cycl0ne
Posts: 102
Joined: Mon Jun 25, 2012 8:03 am

DMB/WMB/ISB

Wed Aug 08, 2012 1:50 pm

Ok,

as i am not the only one confused, i started a new thread and post all implementations i know of into here:

From Tufty:

Code: Select all

/* pass in a spare register */
.macro DMB reg
	mov	\reg, #0
	mcr	p15,0,\reg,c7,c10,5	/* Data memory barrier on ARMv6 */
.endm
/* Data synchronisation barrier */
/* pass in a spare register */
.macro DSB reg
	mov	\reg, #0
	mcr	p15,0,\reg,c7,c10,4	/* Data Synchronisation barrier on ARMv6 */
	
.endm
Dwelch/:

Code: Select all

memory_barrier:
   MCR   p15, 0, ip, c7, c5, 0      @ invalidate I cache
   MCR   p15, 0, ip, c7, c5, 6      @ invalidate BTB
   MCR   p15, 0, ip, c7, c10, 4     @ drain write buffer
   MCR   p15, 0, ip, c7, c5, 4      @ prefetch flush
   MOV   pc, lr
Mine (C Version of Tuftys)

Code: Select all

void lib_DSB(void) 
{
	UINT32 name = 0; 
	__asm__ __volatile__ ("mcr	p15,0,%[t],c7,c10,4\n" :: [t] "r" (name) : "memory");
}
Dexos had also one, but cant find it at the moment.

The question here arises, which of these implementations to use when?

At the moment im thinking of 4 Commands to put into my "kernel":

CacheClear(void) -> Flush all caches etc for : Selfmodifying code etc.
CacheClear(adress,len, flags) -> Flush adress with len out of the deifned chaces in flags.
CachePreDMA(); -> Write all to memory, something wants to use the data.
CachePostDMA(); -> Reload all caches for changed memory.

Is CacheClear(....) even possible on arm? Or can i only flush all?

And what is the correct progress implementing DSB/DMB/..... ? Why are so many different approaches? And what fits best into my functions? Are they enoough or am i missing another case?

Questions over questions...

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: DMB/WMB/ISB

Wed Aug 08, 2012 3:39 pm

Mines the same as Dwelch.
But it originally was modified from the Linux kernel source.
Batteries not included, Some assembly required.

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

Re: DMB/WMB/ISB

Wed Aug 08, 2012 8:38 pm

Data Memory Barrier
This memory barrier ensures that all explicit memory transactions occurring in program order
before this instruction are completed. No explicit memory transactions occurring in program
order after this instruction are started until this instruction completes. Other instructions can
complete out of order with the Data Memory Barrier instruction.
Data Synchronization Barrier
This memory barrier completes when all explicit memory transactions occurring in program
order before this instruction are completed. No explicit memory transactions occurring in
program order after this instruction are started until this instruction completes. In fact, no
instructions occurring in program order after the Data Synchronization Barrier complete, or
change the interrupt masks, until this instruction completes.

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

Re: DMB/WMB/ISB

Wed Aug 08, 2012 8:47 pm

DataSynchronizationBarrier (DSB) CP15 register 7
Note
This operation has historically been referred to as DrainWriteBuffer or DataWriteBarrier (DWB). From
ARMv6, these names (and the use of DWB) are deprecated in favor of the new DataSynchronizationBarrier
name and DSB. DSB better reflects the functionality provided in ARMv6; it is architecturally defined to
include all cache, TLB and branch prediction maintenance operations as well as explicit memory operations.

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

Re: DMB/WMB/ISB

Wed Aug 08, 2012 8:50 pm

B2.7.2
Ordering of cache maintenance operations in the memory order model
The following rules apply to cache maintenance operations with respect to the memory order model:
• All Cache and Branch Predictor Maintenance operations are executed in program order relative to
each other. Where a cache or branch predictor maintenance operation appears in program order
before a change to the page tables, the cache or branch predictor maintenance operation is guaranteed
to take place before change to the page tables is visible.
• Where a change of the page tables appears in program order before a cache or branch predictor
maintenance operation, the sequence outlined in TLB maintenance operations and the memory order
model on page B2-22 must be executed before that change can be guaranteed to visible.
• DMB causes the effect of all cache maintenance operations appearing in program order prior to the
DMB operation to be visible to all explicit load and store operations appearing in program order after
the DMB. It also ensures that the effects of any cache maintenance operations appearing in program
order before the DMB are globally observable before any cache maintenance or explicit memory
operations appearing in program order after the DMB are observed. Completion of the DMB does
not ensure the visibility of all data to other (relevant) observers. (e.g. page table walks).
• DSB causes the completion of all cache maintenance operations appearing in program order prior to
the DSB operation, and ensures that all data written back is visible to all (relevant) observers.
• PrefetchFlush or a return from exception causes the effect of all Branch Predictor maintenance
operations appearing in program order prior to the PrefetchFlush operation to be visible to all
instructions after the PrefetchFlush operation or exception return.
• An exception causes the effect of all Branch Predictor maintenance operations appearing in program
order prior to the point in the instruction stream where the exception is taken to be visible to all
instructions executed after the exception entry (including the instruction fetch of those instructions).
• A Data (or unified) cache maintenance operation by MVA must be executed in program order relative
to any explicit load or store on the same processor to an address covered by the MVA of the cache
operation.
• The ordering of a Data (or unified) cache maintenance operation by MVA relative to any explicit load
or store on the same processor where the address of the explicit load or store is not covered by the
MVA of the cache operation is not restricted. Where the ordering is to be restricted, a DMB operation
must be inserted to enforce ordering.
Memory Order Model
• The ordering of a Data (or unified) cache maintenance operation by Set/Way relative to any explicit
load or store on the same processor is not restricted. Where the ordering is to be restricted, a DMB
operation must be inserted to enforce ordering.
• The execution of a Data (or unified) cache maintenance operation by Set/Way is not necessarily
visible to other observers within the system until a DSB operation has been executed.
• The execution of an Instruction cache maintenance operation is only guaranteed to be complete after
the execution of a DSB barrier.
• The completion of an Instruction cache maintenance operation is only guaranteed to be visible to the
instruction fetch after the execution of a PrefetchFlush operation or an exception or return from
exception.
As a result of the last two points, the sequence of cache cleaning operations for a line of self-modifying code
on a uniprocessor system is:
STR rx, [Instruction location]
Clean Data cache by MVA to point of unification [instruction location]
DSB
; ensures visibility of the data cleaned from the D Cache
Invalidate Instruction cache by MVA [instruction location]
Invalidate BTB entry by MVA [instruction location]
DSB
; ensures completion of the ICache invalidation
PrefetchFlush

User avatar
Cycl0ne
Posts: 102
Joined: Mon Jun 25, 2012 8:03 am

Re: DMB/WMB/ISB

Wed Aug 08, 2012 10:01 pm

its nice that you posted this, but most of us arent too deep into this to know what they are doing or to understand the words written in the arm manual. personaly i dont like the arm manuals, they are written, as if the only three letters in the speech of arm is A.R.M. A simplified version saying:

you do this, because of that, and you do this, because auf this. would be really nice.

i miss the time, where powerpc or 68k manuals where written. easy to understand and easy to implement. but to speak with the words of the chairman of arm: "To produce a good processor, two things i gave to my engineers: no money and no time". i would say, they also missed a good documentation for the broader audience! ;)

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

Re: DMB/WMB/ISB

Thu Aug 09, 2012 1:00 am

compared to others I have been for the most part pleased with the ARM docs, with all the cores and variations possible they do a good job. I agree they dont give howtos, at the same time there are so many different things depending on cores, strap options, memory implementations, etc that there can be too many combinations.

I think you may need to either not have these features, or start looking at things like linux and bsd and others. For sequences they use. The sequence I use came from somewhere, but understand mine is a bare metal thing, I generally turn cache on and leave it on for the duration of the test, or turn it off, trashing everything because I dont care/need to save it then turn it on again. I have had exceptions to that rule but generally use that code to fire up the cache and just leave it on.

You need to worry about the things they are describing and depending on what you have on and what state you are in be it simply trying to invalidate one thing or in a data abort handler trying to stay alive you have different things you may want to flush or invalidate if you want to throw it away (cache parity error for example). So if you need to make sure the cache is flushed and the write buffer then find what barrier is needed for that.

Remember that Linux seems to add arm bugs every release, someone who didnt read the manual or misunderstood or applied the wrong errata to the wrong family of chips. Seems to happen to often, so you still need to take the sequences used there and check the manual to see if there is some sanity behind them at all...At the same time on popular platforms like beagleboards and the raspberry pi the linux and other releases tend to work well enough.

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: DMB/WMB/ISB

Thu Aug 09, 2012 5:59 am

The TRM explains exactly how to carry out the various memory barriers and cache manipulations. The 'howto' is there. It doesn't explain why, because that's not its task - if you're messing about at the level where you need to do these, you're expected to understand why and where you need them. There's quite a few docs on the arm site that explain a good part of this - if it weren't such a pain to link to them, I'd do so.

User avatar
Cycl0ne
Posts: 102
Joined: Mon Jun 25, 2012 8:03 am

Re: DMB/WMB/ISB

Thu Aug 09, 2012 10:46 am

Hmm, you dont need to link them, it would be fine to explain why your DSB differs from others. I know it easier to say: hey RTFM. But i think one positive aspect we should have here in this community of baremetal builders to share know how by saying: dont read all this stuff, just do it this way and all is well with perhaps a little explain what is done. whats so hard about it?
At the end we have an own manual with all interessting things one would need for the baremetal development.

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

Re: DMB/WMB/ISB

Thu Aug 09, 2012 1:50 pm

Cycl0ne wrote:Hmm, you dont need to link them, it would be fine to explain why your DSB differs from others. I know it easier to say: hey RTFM. But i think one positive aspect we should have here in this community of baremetal builders to share know how by saying: dont read all this stuff, just do it this way and all is well with perhaps a little explain what is done. whats so hard about it?
At the end we have an own manual with all interessting things one would need for the baremetal development.
What is so hard is that you need to define what it is you want to do there are many, valid answers for each task but those answers are also very wrong for applying to other tasks, reading the ARM ARM and TRM (and AMBA/AXI spec) is less work than the thousands of howtos to find the one that applies to what you are doing, that is why there are no howtos, this is not a chip company very limited in the number of combinations of solutions. This is where the linux problems come in, a solution is submitted that applies specifically to one chip and one board but is wrong for so many other chips and boards.

David

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: DMB/WMB/ISB

Thu Aug 09, 2012 7:09 pm

Batteries not included, Some assembly required.

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: DMB/WMB/ISB

Thu Aug 09, 2012 8:24 pm

Cycl0ne wrote:it would be fine to explain why your DSB differs from others.
It doesn't. Here it is in all its glory.

Code: Select all

mcr p15, 0, <register>, c7, c10, 4
Dave's using ip (r12), and that's the only difference, although he should probably be setting it to zero before use :)

User avatar
Cycl0ne
Posts: 102
Joined: Mon Jun 25, 2012 8:03 am

Re: DMB/WMB/ISB

Sun Aug 12, 2012 6:35 pm

did you notice that the c example seems to be wrong?

Return to “Bare metal, Assembly language”