Intel flash and cfi_probe.c

Intel flash and cfi_probe.c

[Dan Post]

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

Re: Intel flash and cfi_probe.c

[Thayne Harbaugh]

On Tue, 2004-01-20 at 14:50, Dan Post wrote:

> 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...

This is what jedec_probe.c v1.44 does:


static inline void jedec_reset(u32 base, struct map_info *map, 
	struct cfi_private *cfi)
{
	/* Reset */
	cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
	/* Some misdesigned intel chips do not respond for 0xF0 for a reset,
	 * so ensure we're in read mode.  Send both the Intel and the AMD command
	 * for this.  Intel uses 0xff for this, AMD uses 0xff for NOP, so
	 * this should be safe.
	 */ 
	cfi_send_gen_cmd(0xFF, 0, base, map, cfi, cfi->device_type, NULL);
	/* FIXME - should have reset delay before continuing */
}


-- 
Thayne Harbaugh
Linux Networx

Re: Intel flash and cfi_probe.c

[David Woodhouse]

On Tue, 2004-01-20 at 13:50 -0800, Dan Post wrote:
> 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.

Yeah.... the CFI spec says how to get into query mode, but unfortunately
doesn't specify how to get out of it. And without getting out of it we
can't check for aliases.

We'd previously observed that 0xF0 happened to work for Intel chips...
now evidently it doesn't any more. I suspect we might just have to bite
the bullet and make it depend on the chip type, although it was easier
to avoid that.

> 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...

Hmmm. That could work.

-- 
dwmw2

Re: Intel flash and cfi_probe.c

[Bill Gatliff]

David:


I had seen the lines of code that Thayne had referred to; there are 
other exit paths out of that code that leave the flash in READ STATUS 
mode, apparently.  Haven't researched it enough yet.

Let me know what, if anything, I can do to help!


b.g.


David Woodhouse wrote:

>On Tue, 2004-01-20 at 13:50 -0800, Dan Post wrote:
>  
>
>>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.
>>    
>>
>
>Yeah.... the CFI spec says how to get into query mode, but unfortunately
>doesn't specify how to get out of it. And without getting out of it we
>can't check for aliases.
>
>We'd previously observed that 0xF0 happened to work for Intel chips...
>now evidently it doesn't any more. I suspect we might just have to bite
>the bullet and make it depend on the chip type, although it was easier
>to avoid that.
>
>  
>
>>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...
>>    
>>
>
>Hmmm. That could work.
>
>  
>

-- 
Bill Gatliff
Embedded GNU, Linux, and other board support packages.
bgat@billgatliff.com

Re: Intel flash and cfi_probe.c

[Bill Gatliff]

Dan:


I've seen similar behavior with the J flashes, see my posts from a 
couple of days ago.  My temporary workaround was to issue my own 0xff in 
my map driver functions.  :^(

I noticed the F0's, but didn't wade into the datasheet enough to spot 
that as an issue...


b.g.


Dan Post wrote:

>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
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/
>  
>

-- 
Bill Gatliff
So what part of make clean all install do you not understand?
bgat@billgatliff.com