All of lore.kernel.org
 help / color / mirror / Atom feed
* a complex map
@ 2008-09-08 18:44 Allon Stern
  2008-09-08 19:06 ` Allon Stern
  2008-09-08 19:23 ` Mike Frysinger
  0 siblings, 2 replies; 3+ messages in thread
From: Allon Stern @ 2008-09-08 18:44 UTC (permalink / raw)
  To: linux-mtd

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: a complex map
  2008-09-08 18:44 a complex map Allon Stern
@ 2008-09-08 19:06 ` Allon Stern
  2008-09-08 19:23 ` Mike Frysinger
  1 sibling, 0 replies; 3+ messages in thread
From: Allon Stern @ 2008-09-08 19:06 UTC (permalink / raw)
  To: linux-mtd


On Sep 8, 2008, at 2:44 PM, Allon Stern wrote:

> 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.

Neglected to mention:
uClinux 2.6.26-uc0

-
allon

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: a complex map
  2008-09-08 18:44 a complex map Allon Stern
  2008-09-08 19:06 ` Allon Stern
@ 2008-09-08 19:23 ` Mike Frysinger
  1 sibling, 0 replies; 3+ messages in thread
From: Mike Frysinger @ 2008-09-08 19:23 UTC (permalink / raw)
  To: Allon Stern; +Cc: linux-mtd

On Mon, Sep 8, 2008 at 2:44 PM, Allon Stern wrote:
> 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)

the mtd layers handle bottom/top boot devices just fine. usually
people use those sectors to store configurations or bootloaders rather
than filesystems though.  but that is of course your choice.

> #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?

ive written a generic gpio mapping driver but i'm not sure it's been
posted to LKML yet ... perhaps you will find it useful:
http://blackfin.uclinux.org/git/?p=readonly-mirrors/linux-kernel.git;a=blob_plain;f=drivers/mtd/maps/gpio-addr-flash.c;hb=HEAD

example platform resources can be found here:
http://blackfin.uclinux.org/git/?p=readonly-mirrors/linux-kernel.git;a=commitdiff;h=cf8a23b05d657efbe704426ac458db2f219f5bef

and here:
http://blackfin.uclinux.org/git/?p=readonly-mirrors/linux-kernel.git;a=blob_plain;f=arch/blackfin/mach-bf537/boards/tcm_bf537.c;hb=HEAD
-mike

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-09-08 19:23 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-08 18:44 a complex map Allon Stern
2008-09-08 19:06 ` Allon Stern
2008-09-08 19:23 ` Mike Frysinger

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.