linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* NAND access fail after MMU enabled when booting linux
@ 2008-06-23  3:06 Qin, Laigui (GE EntSol, Security)
  2008-06-23 17:00 ` Scott Wood
  0 siblings, 1 reply; 2+ messages in thread
From: Qin, Laigui (GE EntSol, Security) @ 2008-06-23  3:06 UTC (permalink / raw)
  To: linuxppc-embedded


[-- Attachment #1.1: Type: text/plain, Size: 3962 bytes --]

Dear all,

I am facing a MMU related problem when porting Linux to my custom board
with Coldfire M5445x processor. The observation is that the nand Bus
chip select/WE/RE become 100 times longer than normal when MMU enabled.
I just can not understand this...

The NAND drivers and filesystem (JFFS2) worked fine in Uboot, as shown
in below:

I2C:   ready
DRAM:  64 MB
In:    serial
Out:   serial
Err:   serial
NAND:  256 MiB
-> mtdparts

device nand0 <micron>, # parts = 2
 #: name                        size            offset
mask_flags
 0: kernel              0x00300000      0x00000000      0
 1: database            0x0fc00000      0x00300000      0

active partition: nand0,0 - (kernel) 0x00300000 @ 0x00000000

defaults:
mtdids  : nand0=micron
mtdparts: mtdparts=micron:3m(kernel),252m(database)
->

However, when booting linux, after the MMU enabled, accessing the NAND
flash became fail, here is the screen dump:

Calling initcall 0xc02d7d06: m54452poc_nand_init+0x0/0x1ba()
 paddr=0x0,vaddr=0xe0000000,retaddr=0xe0000000
pa=0x1cb9 va=0xe0000000
Searching for NAND flash...
maf_id=ff dev_id=0x000000ff, &type=00000000
No NAND device found!!!
ColdFire-eDMA: initialized successfully
Slab corruption: size-512 start=c3f702c8, len=512
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
010: 00 00 00 00 00 00 00 00 00 00 00 01 c3 f7 02 e4
020: c3 f7 02 e4 00 00 00 00 00 00 00 00 c0 28 56 04
030: 00 00 00 00 c3 f7 02 fc c3 f7 02 fc 00 00 00 00
040: c0 2c 3e 44 c3 f7 03 0c c3 f7 03 0c 0f e0 00 01
050: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00
Prev obj: start=c3f700c8, len=512
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=c3f704c8, len=512
000: 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00
010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SPI: Coldfire master initialized
ssi_audio: Probed successfully
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
DES & 3DES ColdFire CAU driver v0.01 registered.
AES ColdFire CAU driver v0.01 registered.
MD5 ColdFire CAU driver v0.01 registered.
SHA1 ColdFire CAU driver v0.01 registered.
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
do_initcalls() okay
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
List of all partitions:
No filesystem could mount root, tried:  jffs2
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(2,0)

With logic analyser, we see that Bus CS/WE/RE signals are as long as
1ms, and some address line is not as expected. (The clock is fine
according to osscilliscope.)

 <<Picture (Metafile)>> 

Look into my driver codes, I use the virtual address (0xe0000000)
applied from ioremap() kernel function.

136         /* map physical address */
137         this->IO_ADDR_R = this->IO_ADDR_W = ioremap(0x00000000,
1024);
138         if (!this->IO_ADDR_R) {
139                 printk(KERN_WARNING "ioremap micron NAND @0x00000000
failed\n");
140                 err = -EIO;
141                 goto out_mtd;
142         }

157         /* write byte to flexbus */
158         *((volatile u8 *)(this->IO_ADDR_W)) = 0xDD;

I printed the regs value for the MMU at line 158:
MMUCR: 00000001
MMUOR: 00240000
MMUSR: 00000000
MMUAR: E0000000
MMUTR: E0000003
MMUDR: 000002BC

Looking at the MMU regs, it looks right for read and write access
pessmission. But CS signal should not be that long and ALE singal should
be zero as it is the bit 0 of address (0x00000000)!!! 

Anyone have an idea?

Thanks,
Mike Qin



[-- Attachment #1.2: Type: text/html, Size: 9574 bytes --]

[-- Attachment #2: Picture (Metafile) --]
[-- Type: image/bmp, Size: 177022 bytes --]

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

* Re: NAND access fail after MMU enabled when booting linux
  2008-06-23  3:06 NAND access fail after MMU enabled when booting linux Qin, Laigui (GE EntSol, Security)
@ 2008-06-23 17:00 ` Scott Wood
  0 siblings, 0 replies; 2+ messages in thread
From: Scott Wood @ 2008-06-23 17:00 UTC (permalink / raw)
  To: Qin, Laigui (GE EntSol, Security); +Cc: linuxppc-embedded

Qin, Laigui (GE EntSol, Security) wrote:
> I am facing a MMU related problem when porting Linux to my custom board 
> with Coldfire M5445x processor. The observation is that* the nand Bus 
> chip select/WE/RE become 100 times longer than normal when MMU enabled*. 
> I just can not understand this...

Coldfire is m68k; this list is for powerpc.

> Look into my driver codes, I use the virtual address (0xe0000000) 
> applied from ioremap() kernel function.
> 
> 136         /* map physical address */
> 137         this->IO_ADDR_R = this->IO_ADDR_W = ioremap(0x00000000, 1024);
> 138         if (!this->IO_ADDR_R) {
> 139                 printk(KERN_WARNING "ioremap micron NAND @0x00000000 
> failed\n");

Is it really at address zero, or is that where your RAM is?

-Scott

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

end of thread, other threads:[~2008-06-23 17:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-23  3:06 NAND access fail after MMU enabled when booting linux Qin, Laigui (GE EntSol, Security)
2008-06-23 17:00 ` Scott Wood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).