Accessing flash directly from User Space

[Jonathan Haws]

> Jonathan Haws wrote:
> >>> 	flash[0] = 0x1234;
> >>> 	msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
> >>> 	printf("flash[0] = %#04x\n", flash[0]);
> >>>
> >>> That prints flash[0] = 0x7f45.  I have verified that I am
> reading
> >> the correct values.  I can display the flash contents in U-Boot
> and
> >> 7f45 is what is in the first 16 bits of flash.
> >>> Why can I not write to flash?  What am I doing wrong?
> >> Flash does not work that way -- you must send it commands to
> erase a
> >> block, and then further commands to program new data.
> >
> > I realize that.  I have a driver written that does exactly that.
> > However, I need to be able to write to certain registers to setup
> the
> > erasure.
> 
> Will the device respond to 0x1234 being written at offset zero?  You
> generally have to poke these things pretty specifically in order to
> get
> them to go into command mode.
> 

It should because that is the first data location in flash.  Also, just to be sure I am telling the truth, I tried writing to one of the registers to setup an erase and got the same results - the value did not get written.

> > The driver works perfectly in VxWorks,
> 
> Including the 0x1234 thing?

Actually, I have not tried that - I have not had to since the driver worked.

> >> It sounds like what you really want is the /dev/mtd or
> /dev/mtdblock
> >> interface, not raw access to the flash chip.
> >
> > As mentioned in my initial post, I need to use my custom driver to
> maintain the interface to the application that uses the flash for
> data storage.
> >
> > I had thought about using MTD, but decided against it because with
> > previous benchmarking that we did with MTD and our custom driver,
> we
> > found that our custom driver was about 10x faster.
> 
> Ouch.  Any idea where the slowdown is coming from?

>From what I remember (I would have to dig up notes to make sure) it is something to do with MTD looking for a signal to go high that is processed a bunch before MTD even sees it.  Our flash produces a hardware ready signal that we are triggering off of to move on.  MTD took much longer to report to us that the hardware was ready.

Thanks