Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Michael König]

Hello there,

as a short introduction (I'll be more precise later):
We built our own Linux device utilizing the ETRAX 100LX microcontroller and 
using the SDK provided by Axis. As a Flash chip we chose the Atmel 
AT49BV642D.

With the Linux 2.4 based SDK that includes cfi_cmdset_0002.c v1.62 
2003/01/24 the Flash worked fine although it wasn't correctly recognised by 
the CFI probe (the Atmel patches weren't there yet), but it seems that 
JEDEC seems to fix that up. Excerpt from dmesg on Linux 2.4:

 Amd/Fujitsu Extended Query Table v1.0 at 0x0041
cse0: JEDEC Device ID is 0xD6. Assuming broken CFI table.
cse0: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.

I'm not totally sure what the last line means exactly, but Flash operations 
seem to work fine nontheless.


The new SDK from Axis is based on Linux 2.6 and includes cfi_cmdset_0002.c 
v1.122 2005/11/07. In this case the Flash is correctly recognised thanks to 
the Atmel patches (I also made sure that fixup_convert_atmel_pri() gets 
called and the AT49BV642D is identified as a bottom boot device):

cse0: Probing a 0x04000000 bytes large window at 0xe0000000.
cse0: Found 1 x16 devices at 0x0 in 16-bit bank
cse0: Found an alias at 0x800000 for the chip at 0x0
cse0: Found an alias at 0x1000000 for the chip at 0x0
cse0: Found an alias at 0x1800000 for the chip at 0x0
cse0: Found an alias at 0x2000000 for the chip at 0x0
cse0: Found an alias at 0x2800000 for the chip at 0x0
cse0: Found an alias at 0x3000000 for the chip at 0x0
cse0: Found an alias at 0x3800000 for the chip at 0x0
 Amd/Fujitsu Extended Query Table at 0x0041
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.


The system boots fine and reading isn't a problem either, but it seems that 
no data is actually written to the Flash. When creating a new file on JFFS2 
I get an error message like this:

Node totlen on flash (0xffffffff) != totlen from node ref (0x00000044)

I guess the magic number 0x1985 isn't checked, otherwise it might even fail 
before checking the totlen.

At first I thought that the problem is just with do_write_buffer(), but 
Axis have a bootblocktool that lets you write data to a specific partition 
that is classified as a mtdchar device. While I don't get error messages in 
this case, the written data simply cannot be read back, so I guess there 
must be a problem with do_write_one_word() as well.

I noticed that do_write_buffer() seems to use some kind of burst mode, but 
I wasn't able to find that command sequence (0xAA, 0x55, 0x25) in neither 
the documentation for the AT49BV642D nor an AMD one (Am29DL640D) I looked 
at for comparison.

Since the AT49BV642D is a successor of the AT49BV6416 I tried activating 
fixup_use_atmel_lock() for it as well, but that didn't help either.

All the tests were performed on the same device and once I switch from 
Linux 2.6 back to 2.4 everything works fine, so I doubt that there is a 
problem with the Flash itself.

Does anybody have an idea what might be the cause of this problem?

Thanks in advance!

-- 
Mit freundlichen Grüßen
Best regards
Michael König

ipcas GmbH
Wetterkreuz 17
91058 Erlangen, Germany
Tel.: +49 9131 7677-31
Fax: +49 9131 7677-78
mailto:Michael.Koenig at ipcas.de

Geschäftsführer: Dipl.-Ing. S. Sutiono
Sitz der Gesellschaft: Erlangen
Registergericht: Fürth, HBR 3676
WEEE-Reg.-Nr. DE 77202473

Hinweis: Diese E-Mail und etwaige Anlagen können Betriebs- oder
Geschäftsgeheimnisse, dem Anwaltsgeheimnis unterliegen oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
irrtümlich erhalten haben, ist Ihnen der Status dieser E-Mail bekannt.
Bitte benachrichtigen Sie uns in diesem Fall sofort durch Antwort-Mail
und löschen Sie diese E-Mail nebst etwaigen Anlagen von Ihrem System.
Ebenso dürfen Sie diese E-Mail oder seine Anlagen
nicht kopieren oder an Dritte weitergeben. Vielen Dank.