From: "Michael König" <Michael.Koenig@ipcas.de>
To: linux-mtd@lists.infradead.org
Subject: Re: Problems with cfi_cmdset_0002 and Atmel AT49BV642D
Date: Wed, 09 May 2007 15:34:20 +0200 [thread overview]
Message-ID: <B2FC9E5F094119A0F71B96EF@franken3> (raw)
In-Reply-To: <D1CA5322EC0446D8F2053C9D@franken3>
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.
next prev parent reply other threads:[~2007-05-09 13:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-08 8:44 Problems with cfi_cmdset_0002 and Atmel AT49BV642D Michael König
2007-05-08 11:49 ` Vitaly Wool
2007-05-08 13:04 ` Michael König
2007-05-09 13:34 ` Michael König [this message]
2007-05-09 13:46 ` Hans-Christian Egtvedt
2007-05-10 6:53 ` Michael König
2007-05-10 7:15 ` Hans-Christian Egtvedt
2007-05-10 7:41 ` Michael König
2007-05-10 8:27 ` Haavard Skinnemoen
2007-05-10 10:13 ` Michael König
2007-05-10 10:24 ` Hans-Christian Egtvedt
2007-05-10 10:41 ` Haavard Skinnemoen
2007-08-06 13:41 ` Ricard Wanderlof
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B2FC9E5F094119A0F71B96EF@franken3 \
--to=michael.koenig@ipcas.de \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox