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