Jonathan Haws wrote:

quoted

quoted

quoted

	flash[0] =3D 0x1234;
	msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
	printf("flash[0] =3D %#04x\n", flash[0]);

That prints flash[0] =3D 0x7f45.  I have verified that I am

reading

quoted

quoted

the correct values.  I can display the flash contents in U-Boot

and

quoted

quoted

7f45 is what is in the first 16 bits of flash.

quoted

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

quoted

quoted

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

quoted

erasure.

=20
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.
=20

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.

quoted

The driver works perfectly in VxWorks,

=20
Including the 0x1234 thing?

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

quoted

quoted

It sounds like what you really want is the /dev/mtd or

/dev/mtdblock

quoted

quoted

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.

quoted

I had thought about using MTD, but decided against it because with
previous benchmarking that we did with MTD and our custom driver,

we

quoted

found that our custom driver was about 10x faster.

=20
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 some=

thing to do with MTD looking for a signal to go high that is processed a bu=
nch before MTD even sees it.  Our flash produces a hardware ready signal th=
at we are triggering off of to move on.  MTD took much longer to report to =
us that the hardware was ready.

Thanks