From: Dan Eisenhut <deisenhut@wi.rr.com>
To: linux-mtd@lists.infradead.org
Subject: do_erase_oneblock failing to detect lock-bit failure
Date: Thu, 25 Mar 2004 07:30:10 -0600 [thread overview]
Message-ID: <1080221409.21277.30.camel@localhost> (raw)
(Corporate email didn't do references, switching to something nicer)
Now that I've verified my lock-bits are setting and clearing okay, I'm
trying to test that erase fails properly when a block is locked.
We have a strange setup on our custom board. Data lines 0-7 are swapped
with lines 8-15 going into the CFI flash chip. This is what the
hardware guys are calling "byte-lane swapping" or reordering. To
compensate for this, I had to enable CONFIG_MTD_CFI_LE_BYTE_SWAP. This
appears to be working for reading and writing data. (Is there a better
way to handle this?)
But because of this, do_erase_oneblock fails to handle a failure when a
block is locked. Starting at line 1372 of cfi_cmdset_0001.c, cfi_read
returns a value of 0xa200 into status (a short) indicating ready, error
in block erasure, and block lock-bit detected. chipstatus (a unsigned
char) is assigned the value 0x00 since the 0xa2 portion is chopped off
in the implicit type conversion. My interleave is 1 so chipstatus is
not modified (only one chip for this bank).
Then when it gets down to checking for the protection bit it compares
against "chipstatus & 0x20" instead of "status & CMD(0x20)" so it
automatically fails. Eventually a zero is returned indicating erase
success.
Is byte-lane swapping common? Wouldn't this code fail for someone
without byte-lane swapping but requiring little endian enabled? By
changing the if statements with (chipstatus & 0xNN) with (status &
CMD(0xNN)) appears to correct my problem, but I sure this is not the
best solution.
Dan
Line#1372 - cfi_cmdset_0001.c
-----------------------------
status = cfi_read(map, adr);
/* check for lock bit */
if (status & CMD(0x3a)) {
unsigned char chipstatus = status;
if (status != CMD(status & 0xff)) {
int i;
for (i = 1; i<CFIDEV_INTERLEAVE; i++) {
chipstatus |= status >> (cfi->device_type
* 8);
}
printk(KERN_WARNING "Status is not identical for all
chips: 0x%llx. Merging to give 0x%02x\n", (__u64)status, chipstatus);
}
/* Reset the error bits */
cfi_write(map, CMD(0x50), adr);
cfi_write(map, CMD(0x70), adr);
if ((chipstatus & 0x30) == 0x30) {
printk(KERN_NOTICE "Chip reports improper command
sequence: status 0x%llx\n", (__u64)status);
ret = -EIO;
} else if (chipstatus & 0x02) {
/* Protection bit set */
ret = -EROFS;
} else if ....
next reply other threads:[~2004-03-25 13:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-25 13:30 Dan Eisenhut [this message]
2004-03-25 13:40 ` do_erase_oneblock failing to detect lock-bit failure David Woodhouse
2004-03-26 17:50 ` Dan Eisenhut
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=1080221409.21277.30.camel@localhost \
--to=deisenhut@wi.rr.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.