Accessing flash directly from User Space [SOLVED]

[Joakim Tjernlund]

>
> >
> > > > On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
> > > > >> >>> How can I get that pointer?  Unfortunately I cannot simply
> > > > use
> > > > >> the
> > > > >> >>>
> > > > >> >> address of the flash.  Is there some magical function call
> > > > that
> > > > >> >> 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
> > > > >> not?  However, I do not have a base flash driver to give me
> > > that
> > > > >> file descriptor.  Am I missing something with that call?
> > > > >> >
> > > > >>
> > > > >> /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.
> > > > >
> > > > >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()?

Does O_DIRECT help? (you may need to define _GNU_SOURCE before #include)

 Jocke