Intel flash and cfi_probe.c

["Dan Post" <djp.mtd@onemyth.net>]

Hi,

I was looking at the cfi_probe.c file, and noticed that there are numerous
'0xF0' commands to flash (theoretically to put the flash back into read array
mode).  This is incorrect in terms of Intel flash; according to the datasheets
for L18/30 and K3/18, the "read array" command is 0xFF.

Normally, it would work fine (by virtue of accident, the state machine is
coherent enough not to break after the probe), except in cases of XIP (based
on dwmw2's code, which I have been working on and will send out probably this
week).  It breaks the system then because 0xF0 doesn't really put an Intel
chip into read array, so when you enable intterupts, you schedule to a
function running out of flash, which happens to be in status mode.... == big
bad no-run, i.e. you freeze.

(Specifically, it blows up on L*...  though it seemed to "work" on K*, that
may just be an accident or compatibility mode that wasn't put into L*.  Or
maybe I munged my code somehow and something magically changed.  It's not in
the datasheets, so the behavior could change at any time.  When I changed the
0xF0's to 0xFF's, it worked on L*.)

I assume that the 0xF0 is for AMD flash (a datasheet I checked out confirms
this).  For the cfi_probe.c file to be "proper", it needs to issue 0xFF to
Intel flash, and 0xF0 for AMD.  (Any other chips using different commands??)

What would happen if we issued an 0xF0;0xFF to an AMD chip?  Or 0xFF;0xF0? 
Any AMD chip-heads care to answer?  It looks like it will "work" on Intel chips...

At any rate, either there needs to be a clever hack like that, or the
cfi_probe.c facilities need to be refactored so they know which command to
issue to flash.

Dan