Found a potential bug in MTD

Found a potential bug in MTD

[Frederic Giasson]

Hi,

	I did as it is said in document
ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/mtd/mtd-jffs/HOWTO.txt to add MTD
support in linux kernel 2.4.4 for my PowerPC MPC860 embedded platform.  I
have a single flash chip on by board, an ATMEL AT49BV1614, which has a 2MB
capacity.  So I configured xconfig with CFI support ( since I had found that
my atmel chip was CFI compliant ) and geometry 1x16 but the MTD driver
didn't detect the flash.  Then I tryed not to specify the geometry of my
flash chip, and two 8-bits chips ( 2x8 geometry ) was detected.  At this
point, I began suspecting a bug in the cfi_probe.c functions, which I
tracked down and found (at least, I think).  

	In /mtd/chips/cfi_probe.c, function cfi_qry_mode( ).  Calls to
function cfi_send_gen that read as:
 
		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map,
cfi->interleave, CFI_DEVICETYPE_X8, NULL);
		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map,
cfi->interleave, CFI_DEVICETYPE_X8, NULL);
		cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map,
cfi->interleave, CFI_DEVICETYPE_X8, NULL);
 
should, in my opinion, read like:
		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map,
cfi->interleave, cfi->device_type, NULL);
		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map,
cfi->interleave, cfi->device_type, NULL);
		cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map,
cfi->interleave, cfi->device_type, NULL);   

	I compiled and tested the change with my board, and it works OK.  It
also make sense since CFI_DEVICETYPE_X8 is an hardcoded value for 8 bits
type devices, and cfi->device_type holds the buswidth specified in xconfig.

	Please come back to me on that. 

Best regards,

Frédéric Giasson

Re: Found a potential bug in MTD

[David Woodhouse]

fgiasson@mediatrix.com said:
> 
> 	I compiled and tested the change with my board, and it works OK.  It
> also make sense since CFI_DEVICETYPE_X8 is an hardcoded value for 8
> bits type devices, and cfi->device_type holds the buswidth specified
> in xconfig. 

The addr_unlock values set in cfi_probe_chip() are supposed to compensate
for that. We can't do it by shifting by the device_type, because sometimes 
we need to put an odd address value on the bus for 16-bit chips. 

But the actual _detection_ of CFI chips shouldn't be affected by that 
anyway, unless it's falling back to the JEDEC probe.

--
dwmw2

RE: Found a potential bug in MTD

[Frederic Giasson]

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: Tuesday, May 29, 2001 2:26 PM
To: Frederic Giasson
Cc: linux-mtd@lists.infradead.org
Subject: Re: Found a potential bug in MTD 



fgiasson@mediatrix.com said:
> 
> 	I compiled and tested the change with my board, and it works OK.  It
> also make sense since CFI_DEVICETYPE_X8 is an hardcoded value for 8
> bits type devices, and cfi->device_type holds the buswidth specified
> in xconfig. 

The addr_unlock values set in cfi_probe_chip() are supposed to compensate
for that. We can't do it by shifting by the device_type, because sometimes 
we need to put an odd address value on the bus for 16-bit chips. 

But the actual _detection_ of CFI chips shouldn't be affected by that 
anyway, unless it's falling back to the JEDEC probe.

--
dwmw2


	Maybe but the actual code does not work if you specify a 1x16
geometry with an actual single 16 bits chip on the memory bus.  Also, either
specifying 2x8 geometry or letting MTD autodetect the geometry leads to a
wrong sector organization detection on my board.  I don't know know if it is
the case with other board with 16 bits flash on it (does somebody else
already experienced that problem?), but with 2x8 I come out with bad sizes
and of course bad offset for my sectors.

	I understand that one may want to address a byte at a time, but many
flash chips has a pin called BYTE to specify byte (8 bits) or word (16 bits)
addressing.  If BYTE is set to 8 bits, then it serves nothing to wire all 16
I/O pins because all MSB pins would be don't care.  If it has not been done
yet, maybe someone should check in CFI standard specifications to see if
this is right.  

	But despite of that, doesn't cfi->device_type hold the right
devicetype specified by xconfig?  If someone wants to address the chip in
byte mode, then he will be able to do so (as if CFI_DEVICETYPE_X8 would have
been hardcoded), and if 16 bits (word mode) is specified in xconfig, then it
will work right too.  What do you think?

Re: Found a potential bug in MTD

[David Woodhouse]

fgiasson@mediatrix.com said:
> 
> 	Maybe but the actual code does not work if you specify a 1x16
> geometry with an actual single 16 bits chip on the memory bus.

For CFI chips, I believe it works. The Compaq iPAQ 31xx series have 
precisely this arrangement.

I'm interested to know whether it's the CFI probe or the JEDEC probe which 
is working on your device. Please could you make it print the contents of 
cfi->cfi_mode after detecting the chip?



--
dwmw2

RE: Found a potential bug in MTD

[Frederic Giasson]

----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: Tuesday, May 29, 2001 3:13 PM
To: Frederic Giasson
Cc: linux-mtd@lists.infradead.org
Subject: Re: Found a potential bug in MTD 



fgiasson@mediatrix.com said:
> 
> 	Maybe but the actual code does not work if you specify a 1x16
> geometry with an actual single 16 bits chip on the memory bus.

For CFI chips, I believe it works. The Compaq iPAQ 31xx series have 
precisely this arrangement.

I'm interested to know whether it's the CFI probe or the JEDEC probe which 
is working on your device. Please could you make it print the contents of 
cfi->cfi_mode after detecting the chip?



--
dwmw2
 

cfi->mode = 1 which means that MTD detects in JEDEC mode.  This result is
obtained by compiling the kernel with 1x16 geometry specification, and the
modification to cfi_qry_mode I talked about in a previous mail.

But Atmel chips are CFI, right?  Correct me if I am wrong. 

Frédéric Giasson

RE: Found a potential bug in MTD

[Frederic Giasson]

-----Original Message-----
From: Frederic Giasson [mailto:fgiasson@mediatrix.com]
Sent: Tuesday, May 29, 2001 3:38 PM
To: 'David Woodhouse'
Cc: linux-mtd@lists.infradead.org
Subject: RE: Found a potential bug in MTD 


----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: Tuesday, May 29, 2001 3:13 PM
To: Frederic Giasson
Cc: linux-mtd@lists.infradead.org
Subject: Re: Found a potential bug in MTD 



fgiasson@mediatrix.com said:
> 
> 	Maybe but the actual code does not work if you specify a 1x16
> geometry with an actual single 16 bits chip on the memory bus.

For CFI chips, I believe it works. The Compaq iPAQ 31xx series have 
precisely this arrangement.

I'm interested to know whether it's the CFI probe or the JEDEC probe which 
is working on your device. Please could you make it print the contents of 
cfi->cfi_mode after detecting the chip?



--
dwmw2
 

cfi->mode = 1 which means that MTD detects in JEDEC mode.  This result is
obtained by compiling the kernel with 1x16 geometry specification, and the
modification to cfi_qry_mode I talked about in a previous mail.

But Atmel chips are CFI, right?  Correct me if I am wrong. 

Frédéric Giasson

About my own last question, I just got the answer for someone at Atmel:
their chips are NOT CFI compliant.

Frédéric Giasson




______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/