a complex map
Allon Stern
allon.stern at argonst.com
Mon Sep 8 14:44:39 EDT 2008
I've got the unique pleasure of dealing with a hardware design
cramming a 64MB NOR flash onto a 23 bit address bus (Coldfire M5282).
The memory chip is a Numonyx Strataflash (P30). It's a single part on
a 16 bit data bus.
A couple of questions:
#1: this chip appears as two dies; Each die has four small (32K)
blocks at the bottom, with 128K blocks elsewhere. Is this a problem,
particularly if the small blocks appear in the middle of an MTD
partition? I'm assuming no problem. (I have concatenating support
enabled to allow my partition to span the two dies)
#2: I control the high two address bits on the flash (A24 and A25)
using GPIOs. I have a customized map for this flash which sets the
GPIOs appropraitely for the offset being accessed. Is this is all I
need to do?
The reason I ask, is because I'm running into some issues. In
searching, I've found others having similar issues with previously
stable systems (gumstix, in particular) but I can't help but wonder
if I'm not doing something quite right.
One issue is that the MTD driver seems to think that the chip is in
FL_POINT or FL_READY mode, when in fact it's in status mode. So when
I attempt to mount a filesystem, I see:
host:~ # mount /dev/mtdblock4 /opt
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000000: 0x0080 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000004: 0x0080 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000008: 0x0080 instead
... ad nauseum
I added some debugging in do_read_onechip() and do_point_onechip()
which reveals that it thought it was in FL_POINT or FL_READY mode,
even though I could then read and get 0x0080; I did a write of CMD
(0xff), after which I didn't read 0x0080. (I did print a debugging
message there). I found that after performing a write to the JFFS
filesystem, my debugging messages no longer happened upon reading
from the flash (indicating the flash and MTD driver were in agreement
as to the state at that point).
Are there any known issues being tracked regarding this issue? Am I
missing something in my map? Does having a 32MB part with only 16MB
addressable at a time cause heartburn, especially with pointing? Will
forcing the map_bankwidth to 2 help?
Anything else I should be aware of when it comes to weird mappings?
(Mine must be a pretty tame map compared to what hardware designers
are capable of ;)
Thanks.
-
allon
More information about the linux-mtd
mailing list