>But, as far as I remember, mmap is not synchronous. So
>if you write 0x40404040, then your word at the same location, it
>doesn't mean that it will be really written on the flash,
>so you can't program like that.
If you mmap() the flash, it literally means that the flash device will be
mapped into your address space. Since it's mapped uncached writes will go
straight through.
>Why not doing a write function ? Even if there is one
>for NETWINDER, one for CATS and one for EBSA285
The reason for not putting a flash write function in initially was that it
depends too much on the particular flash chip. Every device has a different
programming algorithm.
For EBSA-285 and other machines with 32-bit flash you can just mmap
/dev/flash and program it that way (though mmap'ing /dev/mem at the right
offset would do just as well). The problem is that if your flash is only 8
or 16 bits wide you need to do additional messing with the Footbridge to get
the data to turn up in the right place.
The way I was most recently planning to do it was to provide a primitive
write() that just sends bytes to the flash doing the correct byte-manipulation
stuff. The device-dependent bits would still be in user space and it would be
generic to EBSA-285 and (I think) CATS, though not NetWinder because that has
extra hardware that needs to get involved. I just haven't got around to
implementing it yet.
p.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
