From: Axel Ludszuweit <alu@keymile.com>
To: linux-kernel@vger.kernel.org
Subject: helper routines for flash chip probing, search sequence
Date: Thu, 08 May 2003 16:24:57 +0200 [thread overview]
Message-ID: <3EBA68B9.9000202@keymile.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]
I have sent this mail to David Woodhouse, the maintainer
of MTD (memory technology devices) part.
He answers
> At first glance, you seem to be right -- you'll not get false matches
> for 4x interleave when in fact the interleave is 2x, so we should check
> for 4x first.
>
> Can you send your patch (and explanation) to the mailing list too, so
> that others can comment on it? It's been a while since I've looked hard
> at anything but the CFI probes. Thanks.
And now my original mail:
I have a question, concerning the flash chip helper
routines
linux/drivers/mtd/chips/gen_probe.c
In my opinion, the searching sequence, to find the
flash geometry, (cfi->device_type and cfi->interleave)
must be reversed, to prevent wrong decisions.
If the buswidth is given, the search should begin
with the highest meaningfull interleave and the lowest
device type.
With the current searching order I get the following
effect.
I have 4 8bit flashes working on a 32 bit data bus.
The Manufacture ID is 0x89, the Device ID 0xAA.
The flash type is SHARP LH28F016SCT-L95
The correct values, which should be detected are:
- cfi->device_type = 1 CFI_DEVICETYPE_X8
- cfi->interleave = 4 CFIDEV_INTERLEAVE_4
but the probing detected
cfi->interleave = CFIDEV_INTERLEAVE_2
cfi->device_type = CFI_DEVICETYPE_X16.
as valid, so that the test with the correct values, following later,
will not be done.
The identifier codes of this SHARP flashes can be read at offset
0 and 1 after writing 0x90 at any arbitrary address in the flash space.
The unlock sequence
0xaa at cfi->addr_unlock1 = 0x555 and
0x55 at cfi->addr_unlock2 = 0x2aa
seems not to be neccessary.
The flashes 0 and 2 are unlocked by 0x00900090, flashes 1 and 4 not,
so that 0 and 2 answers with th correct ID and 1 and 3 with 0x00.
If the search order is reversed, the test with the correct values is made
before the test with wrong parameters.
I have attached a patch, which should prevent such wrong decisions, if
the flashes are not correctly designed.
Does anyone know reasons, that the search order should not be reversed?
--
--------------------------------------------
Datentechnik GmbH
Axel Ludszuweit
D-30855 Langenhagen
Tel.: +49 511 / 978197-630
Fax : +49 511 / 978197-670
http://www.keymile.com
mailto:axel.ludszuweit@keymile.com
[-- Attachment #2: patch_gen_probe.c --]
[-- Type: text/plain, Size: 2887 bytes --]
--- linux-2.4.20/drivers/mtd/chips/gen_probe.c.orig Fri Oct 5 00:14:59 2001
+++ linux-2.4.20/drivers/mtd/chips/gen_probe.c Thu May 8 15:34:52 2003
@@ -159,13 +159,6 @@
#ifdef CFIDEV_BUSWIDTH_2
case CFIDEV_BUSWIDTH_2:
-#ifdef CFIDEV_INTERLEAVE_1
- cfi->interleave = CFIDEV_INTERLEAVE_1;
-
- cfi->device_type = CFI_DEVICETYPE_X16;
- if (cp->probe_chip(map, 0, NULL, cfi))
- return 1;
-#endif /* CFIDEV_INTERLEAVE_1 */
#ifdef CFIDEV_INTERLEAVE_2
cfi->interleave = CFIDEV_INTERLEAVE_2;
@@ -177,50 +170,56 @@
if (cp->probe_chip(map, 0, NULL, cfi))
return 1;
#endif /* CFIDEV_INTERLEAVE_2 */
+#ifdef CFIDEV_INTERLEAVE_1
+ cfi->interleave = CFIDEV_INTERLEAVE_1;
+
+ cfi->device_type = CFI_DEVICETYPE_X16;
+ if (cp->probe_chip(map, 0, NULL, cfi))
+ return 1;
+#endif /* CFIDEV_INTERLEAVE_1 */
break;
-#endif /* CFIDEV_BUSWIDTH_2 */
+#endif /* CFIDEV_BUSWIDTH_2 */
#ifdef CFIDEV_BUSWIDTH_4
case CFIDEV_BUSWIDTH_4:
-#if defined(CFIDEV_INTERLEAVE_1) && defined(SOMEONE_ACTUALLY_MAKES_THESE)
- cfi->interleave = CFIDEV_INTERLEAVE_1;
+#ifdef CFIDEV_INTERLEAVE_4
+ cfi->interleave = CFIDEV_INTERLEAVE_4;
- cfi->device_type = CFI_DEVICETYPE_X32;
+ cfi->device_type = CFI_DEVICETYPE_X8;
if (cp->probe_chip(map, 0, NULL, cfi))
return 1;
-#endif /* CFIDEV_INTERLEAVE_1 */
-#ifdef CFIDEV_INTERLEAVE_2
- cfi->interleave = CFIDEV_INTERLEAVE_2;
-#ifdef SOMEONE_ACTUALLY_MAKES_THESE
- cfi->device_type = CFI_DEVICETYPE_X32;
+ cfi->device_type = CFI_DEVICETYPE_X16;
if (cp->probe_chip(map, 0, NULL, cfi))
return 1;
-#endif
- cfi->device_type = CFI_DEVICETYPE_X16;
+
+#ifdef SOMEONE_ACTUALLY_MAKES_THESE
+ cfi->device_type = CFI_DEVICETYPE_X32;
if (cp->probe_chip(map, 0, NULL, cfi))
return 1;
+#endif /* SOMEONE_ACTUALLY_MAKES_THESE */
- cfi->device_type = CFI_DEVICETYPE_X8;
+#endif /* CFIDEV_INTERLEAVE_4 */
+#ifdef CFIDEV_INTERLEAVE_2
+ cfi->interleave = CFIDEV_INTERLEAVE_2;
+
+ cfi->device_type = CFI_DEVICETYPE_X16;
if (cp->probe_chip(map, 0, NULL, cfi))
return 1;
-#endif /* CFIDEV_INTERLEAVE_2 */
-#ifdef CFIDEV_INTERLEAVE_4
- cfi->interleave = CFIDEV_INTERLEAVE_4;
#ifdef SOMEONE_ACTUALLY_MAKES_THESE
cfi->device_type = CFI_DEVICETYPE_X32;
if (cp->probe_chip(map, 0, NULL, cfi))
return 1;
-#endif
- cfi->device_type = CFI_DEVICETYPE_X16;
- if (cp->probe_chip(map, 0, NULL, cfi))
- return 1;
+#endif /* SOMEONE_ACTUALLY_MAKES_THESE */
+#endif /* CFIDEV_INTERLEAVE_2 */
+#if defined(CFIDEV_INTERLEAVE_1) && defined(SOMEONE_ACTUALLY_MAKES_THESE)
+ cfi->interleave = CFIDEV_INTERLEAVE_1;
- cfi->device_type = CFI_DEVICETYPE_X8;
+ cfi->device_type = CFI_DEVICETYPE_X32;
if (cp->probe_chip(map, 0, NULL, cfi))
return 1;
-#endif /* CFIDEV_INTERLEAVE_4 */
+#endif /* CFIDEV_INTERLEAVE_1 */
break;
#endif /* CFIDEV_BUSWIDTH_4 */
reply other threads:[~2003-05-08 14:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3EBA68B9.9000202@keymile.com \
--to=alu@keymile.com \
--cc=linux-kernel@vger.kernel.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