NAND access fail after MMU enabled when booting linux

[Qin, Laigui (GE EntSol, Security)]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20080623/3eb63710/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 177022 bytes
Desc: Picture (Metafile)
URL: <http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20080623/3eb63710/attachment-0001.bin>