Accessing flash directly from User Space
Jonathan.Haws at sdl.usu.edu
Wed Oct 28 09:52:40 EST 2009
> Jonathan Haws wrote:
> >>> flash = 0x1234;
> >>> msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
> >>> printf("flash = %#04x\n", flash);
> >>> That prints flash = 0x7f45. I have verified that I am
> >> the correct values. I can display the flash contents in U-Boot
> >> 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
> > erasure.
> Will the device respond to 0x1234 being written at offset zero? You
> generally have to poke these things pretty specifically in order to
> 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
> >> 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,
> > 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.
More information about the Linuxppc-dev