On Thu, Oct 29, 2009 at 10:00:28AM +0100, Joakim Tjernlund wrote:

quoted

quoted

I have found the problem.  It occurred to me in the shower (okay

not really,

quoted

quoted

but most good ideas happen there).

What was happening is that I was in fact able to write to the

correct

quoted

quoted

registers.  However, I would try and write to them in a batch.

But the way

quoted

quoted

mmap works (at least according to the man page) with MAP_SHARED

is that the

quoted

quoted

file may not be updated until msync() is called.  Now, I thought

that O_SYNC

quoted

quoted

would take care of that when I open /dev/mem, but that was not

the case.

quoted

quoted

Anyway, to make a long story short, I inserted an msync() after

each

quoted

quoted

assignment to the flash.  This resolved my problem and I can now

program my flash.

quoted

Ouch, this was news to me too. Calling msync() after every write

kills performance.

quoted

We use mmap(/dev/mem) to access HW and havn't seen any issues yet.

Is this

quoted

perhaps a new behaviour for mmap(/dev/mem) and is there a way
to avoid calling msync()?

=20
I suspect that the msync() was merely serving as a very heavyweight
memory barrier.

I did try hacking the mb() calls from the kernel source to use them in user=
 space, but they had no effect.  I still had to include the calls to msync(=
).