Problems with cfi_cmdset_0002 and Atmel AT49BV642D

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

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Vitaly Wool]

Hi Michael,
> 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

that's b/c you're supplying too large a window, but that's harmless AFAICS.

> 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'd check if you have the right width set up first.

Vitaly

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Michael König]

Hello Vitaly

>> cse0: Probing a 0x04000000 bytes large window at 0xe0000000.
>
> that's b/c you're supplying too large a window, but that's harmless
> AFAICS.

Strange, I don't think I'm supplying that window size anywhere, so it must 
be some preset range by Axis. I just took a look at the output of a device 
with a smaller Flash and it was the same window.

>> Node totlen on flash (0xffffffff) != totlen from node ref (0x00000044)
>
> I'd check if you have the right width set up first.

Both kernelconfig files have the following settings for the Flash:
CONFIG_ETRAX_FLASH_BUSWIDTH=2
CONFIG_ETRAX_FLASH1_SIZE=8

The kernelconfig for Linux 2.6 also adds CONFIG_ETRAX_NANDFLASH_BUSWIDTH, 
which was set to 1. I didn't think it would matter, since we don't have 
NAND Flashes, just NOR ones. I set it to 2 as well, just to see what 
happens, but I still have the same behaviour.

To be totally sure, I changed the FLASH_BUSWIDTH to 1 and still have the 
same effects. It's a bit strange, I didn't expect it to work at all.

It still bugs me that I cannot find the command sequence that is used in 
do_write_buffer() in my Atmel documentation.

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

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Michael König]

Hello again,

first of all, going through the GIT archive I found out that the 
cfi_cmdset_0002.c in the latest Axis SDK must be the one from 2006-09-22, 
since the last Atmel changes are present but the newest SST additions 
aren't.

Through some testing I found out that do_write_one_word() works just fine, 
and the main problem seems to be do_write_buffer().
To make it work without changing too much, I simply added a call to 
do_write_one_word() in the beginning of do_write_buffer() and then return. 
I'm sure it's less efficient that way, but I wanted to get it to work first.

Since the problem obviously is in do_write_buffer(), I wonder how this 
command sequence works:

cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi, 
cfi->device_type, NULL);
cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi, 
cfi->device_type, NULL);
//cfi_send_gen_cmd(0xA0, cfi->addr_unlock1, chip->start, map, cfi, 
cfi->device_type, NULL);
/* Write Buffer Load */
map_write(map, CMD(0x25), cmd_adr);

I wasn't able to find that sequence either in the documentation of my Atmel 
chip, or in AMD or Spansion ones.
Is this some undocumented command sequence that isn't implemented by Atmel?
Why isn't the bypass mode used anymore?

Thanks in advance for any insights that might clear up this issue.

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

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Hans-Christian Egtvedt]

On Wed, 2007-05-09 at 15:34 +0200, Michael König wrote:
> first of all, going through the GIT archive I found out that the 
> cfi_cmdset_0002.c in the latest Axis SDK must be the one from 2006-09-22, 
> since the last Atmel changes are present but the newest SST additions 
> aren't.
> 
> Through some testing I found out that do_write_one_word() works just fine, 
> and the main problem seems to be do_write_buffer().
> To make it work without changing too much, I simply added a call to 
> do_write_one_word() in the beginning of do_write_buffer() and then return. 
> I'm sure it's less efficient that way, but I wanted to get it to work first.

Hmmm, AT49BV642D should not use the do_write_buffer() function at all.
There should be a fixup for this in the kernel.

Is there a "fixup_convert_atmel_pri" function which

<quote>
	/* burst write mode not supported */
	cfi->cfiq->BufWriteTimeoutTyp = 0;
	cfi->cfiq->BufWriteTimeoutMax = 0;
</quote>

This will disable using the "cfi_amdstd_write_buffers" function.

> Since the problem obviously is in do_write_buffer(), I wonder how this 
> command sequence works:
> 
> cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi, 
> cfi->device_type, NULL);
> cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi, 
> cfi->device_type, NULL);
> //cfi_send_gen_cmd(0xA0, cfi->addr_unlock1, chip->start, map, cfi, 
> cfi->device_type, NULL);
> /* Write Buffer Load */
> map_write(map, CMD(0x25), cmd_adr);

This is the standard "Word program" command, take a look on page 11 in
the datasheet.

> I wasn't able to find that sequence either in the documentation of my Atmel 
> chip, or in AMD or Spansion ones.
> Is this some undocumented command sequence that isn't implemented by Atmel?
> Why isn't the bypass mode used anymore?

The Atmel device has a dual-word write function, but AFAIK AMD
(Spansion) devices can write a lot more with a single command. Thus
AT49BV642D can not use the default AMD command for buffer writes.

> Thanks in advance for any insights that might clear up this issue.

Sorry for a bit incomplete answer, but this flash device is working on
the ATNGW100 kit from Atmel. So it should work for you as well.

-- 
With kind regards,

Hans-Christian Egtvedt

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Michael König]

Hello Hans-Christian...

> Is there a "fixup_convert_atmel_pri" function which

The function fixup_convert_atmel_pri() is present and is being called as 
confirmed by a printk() I added to it.

> <quote>
> 	/* burst write mode not supported */
> 	cfi->cfiq->BufWriteTimeoutTyp = 0;
> 	cfi->cfiq->BufWriteTimeoutMax = 0;
> </quote>

I'm not sure what version of cfi_cmdset_0002.c you have, but those lines 
are nowhere to be found in my copy and neither are they in the current GIT 
revision:
<http://git.infradead.org/?p=mtd-2.6.git;a=blob_plain;f=drivers/mtd/chips/cfi_cmdset_0002.c>

> This will disable using the "cfi_amdstd_write_buffers" function.

To give it a try I removed my changes and added those two lines to 
fixup_convert_atmel_pri(), but cfi_amdstd_write_buffers() and thus 
do_write_buffer() are still being called.

>> cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
>> cfi->device_type, NULL);
>> cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi,
>> cfi->device_type, NULL);
>> //cfi_send_gen_cmd(0xA0, cfi->addr_unlock1, chip->start, map, cfi,
>> cfi->device_type, NULL);
>> /* Write Buffer Load */
>> map_write(map, CMD(0x25), cmd_adr);
>
> This is the standard "Word program" command, take a look on page 11 in
> the datasheet.

It would be if 0xA0 was present, but that's commented out in 
do_write_buffer() and replaced by 0x25. That's a sequence I cannot find in 
the Atmel documentation (and neither in the AMD/Spansion ones for that 
matter), but as you point out do_write_buffer() shouldn't get called for 
Atmel chips anyway.

> The Atmel device has a dual-word write function, but AFAIK AMD
> (Spansion) devices can write a lot more with a single command. Thus
> AT49BV642D can not use the default AMD command for buffer writes.

The funny thing is that do_write_buffer() never seems to write more than 
two words (in my case 4 bytes), so I don't understand why the bypass mode 
isn't used anymore like in a previous incarnation of the code.

> Sorry for a bit incomplete answer, but this flash device is working on
> the ATNGW100 kit from Atmel. So it should work for you as well.

You've certainly helped me to know for certain that do_write_buffer() 
shouldn't get called for Ateml chips. But it confuses me that Atmel seems 
to have a different code base than the GIT repository.

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

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Hans-Christian Egtvedt]

On Thu, 2007-05-10 at 08:53 +0200, Michael König wrote:
> Hello Hans-Christian...
> 
> > Is there a "fixup_convert_atmel_pri" function which
> 
> The function fixup_convert_atmel_pri() is present and is being called as 
> confirmed by a printk() I added to it.
> 
> > <quote>
> > 	/* burst write mode not supported */
> > 	cfi->cfiq->BufWriteTimeoutTyp = 0;
> > 	cfi->cfiq->BufWriteTimeoutMax = 0;
> > </quote>
> 
> I'm not sure what version of cfi_cmdset_0002.c you have, but those lines 
> are nowhere to be found in my copy and neither are they in the current GIT 
> revision:
> <http://git.infradead.org/?p=mtd-2.6.git;a=blob_plain;f=drivers/mtd/chips/cfi_cmdset_0002.c>

This is from the AVR32 GIT repository at
git://www.atmel.no/~hskinnemoen/linux/kernel/avr32.git

/* Atmel chips don't use the same PRI format as AMD chips */
static void fixup_convert_atmel_pri(struct mtd_info *mtd, void *param)
{
	struct map_info *map = mtd->priv;
	struct cfi_private *cfi = map->fldrv_priv;
	struct cfi_pri_amdstd *extp = cfi->cmdset_priv;
	struct cfi_pri_atmel atmel_pri;

	memcpy(&atmel_pri, extp, sizeof(atmel_pri));
	memset((char *)extp + 5, 0, sizeof(*extp) - 5);

	if (atmel_pri.Features & 0x02)
		extp->EraseSuspend = 2;

	if (atmel_pri.BottomBoot)
		extp->TopBottom = 2;
	else
		extp->TopBottom = 3;

	/* burst write mode not supported */
	cfi->cfiq->BufWriteTimeoutTyp = 0;
	cfi->cfiq->BufWriteTimeoutMax = 0;
}

It should have been pushed upstream, I will prod my co-worker.

> > This will disable using the "cfi_amdstd_write_buffers" function.
> 
> To give it a try I removed my changes and added those two lines to 
> fixup_convert_atmel_pri(), but cfi_amdstd_write_buffers() and thus 
> do_write_buffer() are still being called.

Strange... because it should never get added in the
fixup_use_write_buffers() function. Could you check the ordering in
cfi_fixup_table[]?

fixup_convert_atmel_pri must be set _before_ fixup_use_write_buffers. I
think that might be bogus upstream as well :(

> >> cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
> >> cfi->device_type, NULL);
> >> cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi,
> >> cfi->device_type, NULL);
> >> //cfi_send_gen_cmd(0xA0, cfi->addr_unlock1, chip->start, map, cfi,
> >> cfi->device_type, NULL);
> >> /* Write Buffer Load */
> >> map_write(map, CMD(0x25), cmd_adr);
> >
> > This is the standard "Word program" command, take a look on page 11 in
> > the datasheet.
> 
> It would be if 0xA0 was present, but that's commented out in 
> do_write_buffer() and replaced by 0x25. That's a sequence I cannot find in 
> the Atmel documentation (and neither in the AMD/Spansion ones for that 
> matter), but as you point out do_write_buffer() shouldn't get called for 
> Atmel chips anyway.

I know, this is why the fixup for Atmel devices was added in the first
place.

> > The Atmel device has a dual-word write function, but AFAIK AMD
> > (Spansion) devices can write a lot more with a single command. Thus
> > AT49BV642D can not use the default AMD command for buffer writes.
> 
> The funny thing is that do_write_buffer() never seems to write more than 
> two words (in my case 4 bytes), so I don't understand why the bypass mode 
> isn't used anymore like in a previous incarnation of the code.

Hmmm... interesting, perhaps we can add the dual word write support for
the Atmel device but have a fixup which sets the last command according
to the device.

> > Sorry for a bit incomplete answer, but this flash device is working on
> > the ATNGW100 kit from Atmel. So it should work for you as well.
> 
> You've certainly helped me to know for certain that do_write_buffer() 
> shouldn't get called for Ateml chips. But it confuses me that Atmel seems 
> to have a different code base than the GIT repository.

We use GIT repository internally and push to the externally available
repository, and we do have some branches with drivers which are still in
review for submitting upstream.

But changes like these should have been posted earlier.

-- 
With kind regards,

Hans-Christian Egtvedt, siv.ing. (M.Sc.)
Applications Engineer - AVR32 System Solutions - Atmel Norway

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Michael König]

Hello Hans-Christian...

> This is from the AVR32 GIT repository at
> git://www.atmel.no/~hskinnemoen/linux/kernel/avr32.git

That's the same fixup_convert_atmel_pri() apart from the two additional 
lines you mentioned earlier.

> Strange... because it should never get added in the
> fixup_use_write_buffers() function. Could you check the ordering in
> cfi_fixup_table[]?
> fixup_convert_atmel_pri must be set _before_ fixup_use_write_buffers. I
> think that might be bogus upstream as well :(

Good call, those entries are the other way round:

static struct cfi_fixup cfi_fixup_table[] = {
#ifdef AMD_BOOTLOC_BUG
	{ CFI_MFR_AMD, CFI_ID_ANY, fixup_amd_bootblock, NULL },
#endif
	{ CFI_MFR_AMD, 0x0050, fixup_use_secsi, NULL, },
	{ CFI_MFR_AMD, 0x0053, fixup_use_secsi, NULL, },
	{ CFI_MFR_AMD, 0x0055, fixup_use_secsi, NULL, },
	{ CFI_MFR_AMD, 0x0056, fixup_use_secsi, NULL, },
	{ CFI_MFR_AMD, 0x005C, fixup_use_secsi, NULL, },
	{ CFI_MFR_AMD, 0x005F, fixup_use_secsi, NULL, },
#if !FORCE_WORD_WRITE
	{ CFI_MFR_ANY, CFI_ID_ANY, fixup_use_write_buffers, NULL, },
#endif
	{ CFI_MFR_ATMEL, CFI_ID_ANY, fixup_convert_atmel_pri, NULL },
	{ 0, 0, NULL, NULL }
};

I moved "fixup_convert_atmel_pri" above "fixup_use_write_buffers" and now 
it works like expected.

>> The funny thing is that do_write_buffer() never seems to write more than
>> two words (in my case 4 bytes), so I don't understand why the bypass
>> mode  isn't used anymore like in a previous incarnation of the code.
>
> Hmmm... interesting, perhaps we can add the dual word write support for
> the Atmel device but have a fixup which sets the last command according
> to the device.

At least my traces show that do_write_buffer() seems to be always called 
with two words. I guess you'll have to do your own testing to confirm that.

> But changes like these should have been posted earlier.

Hopefully those changes will be posted soon, before someone else runs into 
the same problem.

Thanks for your help; now I have a clean solution rather than my crude hack.

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

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Haavard Skinnemoen]

On Thu, 10 May 2007 09:15:48 +0200
Hans-Christian Egtvedt <hcegtvedt@atmel.com> wrote:

> This is from the AVR32 GIT repository at
> git://www.atmel.no/~hskinnemoen/linux/kernel/avr32.git

[...]

> It should have been pushed upstream, I will prod my co-worker.

No, only the avr32-arch branch from that repository containts stuff
that is pushed upstream directly. Anything that is not completely
AVR32-specific is sent as patches to the appropriate maintainers for
review.

So if you have the patch available, now would probably be a good time
to post it ;-)

Haavard

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Michael König]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

> So if you have the patch available, now would probably be a good time
> to post it ;-)

Unfortunately I don't have any experience with GIT and also don't have the 
time to set it up right now, but I'm attaching a "diff -p" for the changes 
to the latest cfi_cmdset_0002.c in the repository.

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

[-- Attachment #2: cfi_cmdset_0002.diff --]
[-- Type: application/octet-stream, Size: 1381 bytes --]

*** a/drivers/mtd/chips/cfi_cmdset_0002.c	2007-05-10 04:06:58.000000000 -0400
--- b/drivers/mtd/chips/cfi_cmdset_0002.c	2007-05-10 04:53:03.000000000 -0400
*************** static void fixup_convert_atmel_pri(stru
*** 185,190 ****
--- 185,194 ----
  		extp->TopBottom = 2;
  	else
  		extp->TopBottom = 3;
+ 
+ 	/* burst write mode not supported */
+ 	cfi->cfiq->BufWriteTimeoutTyp = 0;
+ 	cfi->cfiq->BufWriteTimeoutMax = 0;
  }
  
  static void fixup_use_secsi(struct mtd_info *mtd, void *param)
*************** static struct cfi_fixup cfi_fixup_table[
*** 226,235 ****
  	{ CFI_MFR_AMD, 0x0056, fixup_use_secsi, NULL, },
  	{ CFI_MFR_AMD, 0x005C, fixup_use_secsi, NULL, },
  	{ CFI_MFR_AMD, 0x005F, fixup_use_secsi, NULL, },
  #if !FORCE_WORD_WRITE
  	{ CFI_MFR_ANY, CFI_ID_ANY, fixup_use_write_buffers, NULL, },
  #endif
- 	{ CFI_MFR_ATMEL, CFI_ID_ANY, fixup_convert_atmel_pri, NULL },
  	{ 0, 0, NULL, NULL }
  };
  static struct cfi_fixup jedec_fixup_table[] = {
--- 230,239 ----
  	{ CFI_MFR_AMD, 0x0056, fixup_use_secsi, NULL, },
  	{ CFI_MFR_AMD, 0x005C, fixup_use_secsi, NULL, },
  	{ CFI_MFR_AMD, 0x005F, fixup_use_secsi, NULL, },
+ 	{ CFI_MFR_ATMEL, CFI_ID_ANY, fixup_convert_atmel_pri, NULL },
  #if !FORCE_WORD_WRITE
  	{ CFI_MFR_ANY, CFI_ID_ANY, fixup_use_write_buffers, NULL, },
  #endif
  	{ 0, 0, NULL, NULL }
  };
  static struct cfi_fixup jedec_fixup_table[] = {

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Hans-Christian Egtvedt]

On Thu, 2007-05-10 at 12:13 +0200, Michael König wrote:
> > So if you have the patch available, now would probably be a good time
> > to post it ;-)
> 
> Unfortunately I don't have any experience with GIT and also don't have the 
> time to set it up right now, but I'm attaching a "diff -p" for the changes 
> to the latest cfi_cmdset_0002.c in the repository.

Ah, very similar to the patch I posted against 2.6.20. The email is held
for approval for some reason, but this patch will do the same. Only
difference is that I put fixup_convert_atmel_pri on the top, since none
of the other fixups should read anything from an Atmel device CFI
information before it has been corrected.

-- 
With kind regards,

Hans-Christian Egtvedt, siv.ing. (M.Sc.)
Applications Engineer - AVR32 System Solutions - Atmel Norway

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Haavard Skinnemoen]

On Thu, 10 May 2007 12:13:05 +0200
Michael König <Michael.Koenig@ipcas.de> wrote:

> > So if you have the patch available, now would probably be a good time
> > to post it ;-)  
> 
> Unfortunately I don't have any experience with GIT and also don't have the 
> time to set it up right now, but I'm attaching a "diff -p" for the changes 
> to the latest cfi_cmdset_0002.c in the repository.

Sorry, that comment was meant for Hans-Christian. But your patch looks
good too :-)

Haavard

Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D

[Ricard Wanderlof]

On Thu, 10 May 2007, Michael König wrote:

>> So if you have the patch available, now would probably be a good time
>> to post it ;-)
>
> Unfortunately I don't have any experience with GIT and also don't have the 
> time to set it up right now, but I'm attaching a "diff -p" for the changes to 
> the latest cfi_cmdset_0002.c in the repository.

This was a long time ago, is there any reason the supplied patch was never 
committed?

/Ricard

(for reference, since it was a while ago, the patch follows below)

--------------8<------------------

From Michael.Koenig@ipcas.de Thu May 10 10:44:49 2007
Date: Thu, 10 May 2007 10:42:53 +0200
From: "[UTF-8] Michael König" <Michael.Koenig@ipcas.de>
To: dev-etrax@axis.com
Subject: Atmel Flash Fix: cfi_cmdset_0002.c (was: MTD problems)

     [ The following text is in the "utf-8" character set. ]
     [ Your display is set for the "ISO-8859-1" character set.  ]
     [ Some characters may be displayed incorrectly. ]

Hello again,

with the help of Hans-Christian Egtvedt from Atmel (thanks!) I was able to
track down my issues with the Atmel Flash.

On Atmel Flashes the do_write_buffer() function is not supposed to be
called, and it seems that some patches to make sure of that weren't applied
to the code in the Linux kernel GIT.

The following changes have to be applied to this file:
drivers/mtd/chips/cfi_cmdset_0002.c


Two lines (not counting the comment) are added to fixup_convert_atmel_pri():

static void fixup_convert_atmel_pri(struct mtd_info *mtd, void *param)
{
 	struct map_info *map = mtd->priv;
 	struct cfi_private *cfi = map->fldrv_priv;
 	struct cfi_pri_amdstd *extp = cfi->cmdset_priv;
 	struct cfi_pri_atmel atmel_pri;

 	memcpy(&atmel_pri, extp, sizeof(atmel_pri));
 	memset((char *)extp + 5, 0, sizeof(*extp) - 5);

 	if (atmel_pri.Features & 0x02)
 		extp->EraseSuspend = 2;

 	if (atmel_pri.BottomBoot)
 		extp->TopBottom = 2;
 	else
 		extp->TopBottom = 3;

 	/* burst write mode not supported */
 	cfi->cfiq->BufWriteTimeoutTyp = 0;
 	cfi->cfiq->BufWriteTimeoutMax = 0;
}


In the cfi_fixup_table[] "fixup_convert_atmel_pri" has to appear before
"fixup_use_write_buffers":

static struct cfi_fixup cfi_fixup_table[] = {
#ifdef AMD_BOOTLOC_BUG
 	{ CFI_MFR_AMD, CFI_ID_ANY, fixup_amd_bootblock, NULL },
#endif
 	{ CFI_MFR_AMD, 0x0050, fixup_use_secsi, NULL, },
 	{ CFI_MFR_AMD, 0x0053, fixup_use_secsi, NULL, },
 	{ CFI_MFR_AMD, 0x0055, fixup_use_secsi, NULL, },
 	{ CFI_MFR_AMD, 0x0056, fixup_use_secsi, NULL, },
 	{ CFI_MFR_AMD, 0x005C, fixup_use_secsi, NULL, },
 	{ CFI_MFR_AMD, 0x005F, fixup_use_secsi, NULL, },
 	{ CFI_MFR_ATMEL, CFI_ID_ANY, fixup_convert_atmel_pri, NULL },
#if !FORCE_WORD_WRITE
 	{ CFI_MFR_ANY, CFI_ID_ANY, fixup_use_write_buffers, NULL, },
#endif
 	{ 0, 0, NULL, NULL }
};


Now Atmel Flash chips should work correctly with the latest SDK, at least my
AT49BV642D does.

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

-------------8<---------

--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30