mmap question
Frederic Gobry
frederic.gobry at smartdata.ch
Fri Jul 12 03:57:16 EDT 2002
> 0x80 is the status register, you are reading. The command set (Intel
> or Amd, I suppose) can read it, handle any errors (0x80 mean no errors
> on intel) and return to read mode by writing 0xff to the flash.
Mmmm, this enlightens the situation. I was fearing some cache problem...
> My guess is that you command set has a bug. Fix it or provide a spec
> and some beer and pizza. ;-)
The base code uses cfi_probe: it seemed to me the command set is
determined and provided automatically, isn't it ?
I think it's more because I interfere with the "canonical" way MTD
handles the flash: I access directly the memory after the erase or
write operation (via mmap, *not* via a read system call), but from the
code in do_read_onechip (cfi_cmdset_0001.c), it seems the flash is set
to read mode not when the erase or write operation is finished, but
before an actual read must be performed (which makes sense).
I can work around this for my program (I just tested, performing a
simple read just after the write restores what is seen in the mmapped
memory), but I still would like to know if the MTD API could be
augmented in order to handle read-only memory mapped areas (when
available) in a cleaner way as what I currently do? I don't think
this would imply lots of changes:
- a flag indicating if the flash can be mmapped
- the implementation of mmap (which probably would need a call
similar to 'point' but with an explicit semantic toward
mmapping.
- possibly another flag to indicate that an area is currently
mmapped, so that the erase / write operations set the flash in
read mode once they have finished their duty
Frédéric
PS : where can I send the beer and pizza ? :-)
--
Frédéric Gobry SMARTDATA
--- http://www.smartdata.ch
Software Engineer Lausanne - Switzerland
+41 21 693 84 98
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020712/7d3edfb4/attachment.bin
More information about the linux-mtd
mailing list