On Thu, 2009-10-29 at 10:00 +0100, Joakim Tjernlund wrote:

quoted

quoted

quoted

On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:

quoted

quoted

quoted

quoted

quoted

How can I get that pointer?  Unfortunately I cannot simply

use

quoted

quoted

the

quoted

quoted

quoted

address of the flash.  Is there some magical function call

that

quoted

quoted

quoted

quoted

gives me access to that portion of the memory space?

$ man 2 mmap

You want MAP_SHARED and O_SYNC.

To use that I need to have a file descriptor to a device, do

I

quoted

quoted

quoted

not?  However, I do not have a base flash driver to give me

that

quoted

quoted

quoted

file descriptor.  Am I missing something with that call?

quoted

/dev/mem

Okay, I now have access to the flash memory, however when I write

to it the writes do not take.  I have tried calling msync() on the
mapping to no avail.  I have opened the fd with O_SYNC, but cannot
get things to work right.

quoted

Here are the calls:

  int fd = open("/dev/mem", O_SYNC | O_RDWR);
  uint16_t * flash = (uint16_t *)mmap(NULL, NOR_FLASH_SIZE,
        (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
        NOR_FLASH_BASE_ADRS);

What board and CPU are you using?  Is your flash really at
0xFC800000, or is
that the virtual address that VxWorks puts it at?

I am using a custom board based on the AMCC Kilauea development
board.  It uses a 405EX CPU.  Yes, the flash is really at
0xFC000000.

I have found the problem.  It occurred to me in the shower (okay not really,
but most good ideas happen there).

What was happening is that I was in fact able to write to the correct
registers.  However, I would try and write to them in a batch.  But the way
mmap works (at least according to the man page) with MAP_SHARED is that the
file may not be updated until msync() is called.  Now, I thought that O_SYNC
would take care of that when I open /dev/mem, but that was not the case.

Anyway, to make a long story short, I inserted an msync() after each
assignment to the flash.  This resolved my problem and I can now program my flash.

Ouch, this was news to me too. Calling msync() after every write kills performance.
We use mmap(/dev/mem) to access HW and havn't seen any issues yet. Is this
perhaps a new behaviour for mmap(/dev/mem) and is there a way
to avoid calling msync()?

The address range should be outside the dram and thus uncached. Any
write to any address in the range mmaped should go directly to the NOR
flash. Any other behavior is a bug. It's not mapping an actual file
here.