Re: mmap question

Frederic Gobry
2002-07-12T07:57:17Z

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

> 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