> 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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
