> 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