Writing Kernel Image to NAND fail on DM6467

This probrably means the Linux Kernel does not have support for this specific NAND device; you may need to modify the Linux Kernel NAND driver to support this part.

Hi Juan,

You mean the Kervel NAND driver does not support EVM board's NAND flash?

Oh....

Tai

RBL supports fixed set of NAND devices; additionally u-boot and kernel can support a wider set of NAND devices but it would be impossible to add support for all existing and yet to exist NAND devices, hence the source code only supports a limited set of devices.  The u-boot and kernel we provide support the NAND device we used on our EVM, anything other NAND device may or may not work; therefore, if you are designing your own EVM with a different NAND device, then you may or may not need to add support for your new NAND device. 

That said, I was under the impression that you were using a different NAND device on your own board; therefore, suggested you may need to add support. 

Hi Juan,

Now the nandwrite is ok to write into NAND flash, but when I boot in u-boot mode.

and run ↓

DM6467 EVM # nboot 80700000 0 120000

Loading from NAND 128MiB 3,3V 8-bit, offset 0x120000
** Read error

then I try another way: ↓

DM6467 EVM # nand read 0x80700000 0x120000 0x200000

NAND read: device 0 offset 0x120000, size 0x200000
 2097152 bytes read: ERROR

What's wrong with it ??

Tai

update:

DM6467 EVM # nand erase 0x120000 0x200000

NAND erase: device 0 offset 0x120000, size 0x200000
Skipping bad block at  0x00120000
Skipping bad block at  0x00140000
Skipping bad block at  0x00160000
Skipping bad block at  0x00180000
Skipping bad block at  0x001a0000
Skipping bad block at  0x001c0000
Skipping bad block at  0x001e0000
Skipping bad block at  0x00200000
Skipping bad block at  0x00220000
Skipping bad block at  0x00240000
Skipping bad block at  0x00260000
Skipping bad block at  0x00280000
Erasing at 0x300000 -- 100% complete.
OK

DM6467 EVM # tftp 0x80700000 uImage
TFTP from server 10.32.62.188; our IP address is 10.32.62.100
Filename 'uImage'.
Load address: 0x80700000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##################################
done
Bytes transferred = 1504540 (16f51c hex)

DM6467 EVM # nand write 0x80700000 0x120000 0x200000

NAND write: device 0 offset 0x120000, size 0x200000
 2097152 bytes written: OK

DM6467 EVM # nand read 0x80700000 0x120000 0x200000

NAND read: device 0 offset 0x120000, size 0x200000
 2097152 bytes read: ERROR

What's wrong with it ??

Tai

looks like a problem with your flash. you write the kernel image to 0x120000 but the flash block at 0x120000 is bad. but the messages from the nand erase command looks also strange. try "nand bad" to show all bad blocks. seems all blocks are bad. maybe you can erase the BBT.

Hi,

I study the u-boot code and found nand scrub comand

========================================================================

partion of code: usage: nand cmd

 if (strcmp(cmd, "bad") != 0 && strcmp(cmd, "erase") != 0 &&
     strncmp(cmd, "dump", 4) != 0 &&
     strncmp(cmd, "read", 4) != 0 && strncmp(cmd, "write", 5) != 0 &&
     strcmp(cmd, "scrub") != 0 && strcmp(cmd, "markbad") != 0 &&
     strcmp(cmd, "biterr") != 0 &&
     strcmp(cmd, "lock") != 0 && strcmp(cmd, "unlock") != 0 )
========================================================================

DM6467 HD EVM # nand scrub <== scrub NAND flash

NAND scrub: device 0 whole chip
Warning: scrub option will erase all factory set bad blocks!
         There is no reliable way to recover them.
         Use this command only for testing purposes if you
         are sure of what you are doing!

Really scrub this NAND flash? <y/N> if y then press Enter.
Erasing at 0x7fe0000 -- 100% complete.
OK
DM6467 HD EVM # nand bad  < === check bad sector and got no bad ones.

Device 0 bad blocks:
DM6467 HD EVM # tftp 0x80700000 uImage <== load uImage from tftp server
TFTP from server 10.32.62.188; our IP address is 10.32.62.100
Filename 'uImage'.
Load address: 0x80700000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##################################
done
Bytes transferred = 1504540 (16f51c hex)
DM6467 HD EVM # nand write 0x80700000 0x0a0000 160000  <== this time I write to 0xa0000 

NAND write: device 0 offset 0xa0000, size 0x160000
cmd_nand.c[381] 1441792 bytes written: OK  <== write ok
DM6467 HD EVM # nboot 80700000 0 a0000 <== nand boot

Loading from NAND 128MiB 3,3V 8-bit, offset 0xa0000
   Image Name:   Linux-2.6.10_mvl401-davinci_evm-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1504476 Bytes =  1.4 MB
   Load Address: 80008000
   Entry Point:  80008000
DM6467 HD EVM # bootm 80700000 <== boot from memory address 80700000
## Booting image at 80700000 ...
   Image Name:   Linux-2.6.10_mvl401-davinci_evm-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1504476 Bytes =  1.4 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... Bad Data CRC  < == damn !!! [:'(]

Tai

you have the wrong size in your nand write command. your kernel is 0x16f51c an you only write 0x160000 to the flash. try 0x180000.

Hi,

DM6467 HD EVM # tftp 0x80700000 uImage
TFTP from server 10.32.62.188; our IP address is 10.32.62.100
Filename 'uImage'.
Load address: 0x80700000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##################################
done
Bytes transferred = 1504540 (16f51c hex)
DM6467 HD EVM # nand write 0x80700000 0x0a0000 0x180000

NAND write: device 0 offset 0xa0000, size 0x180000
cmd_nand.c[381] 1572864 bytes written: OK
DM6467 HD EVM # nboot 80700000 0 a0000

Loading from NAND 128MiB 3,3V 8-bit, offset 0xa0000
   Image Name:   Linux-2.6.10_mvl401-davinci_evm-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1504476 Bytes =  1.4 MB
   Load Address: 80008000
   Entry Point:  80008000
DM6467 HD EVM # bootm 80700000
## Booting image at 80700000 ...
   Image Name:   Linux-2.6.10_mvl401-davinci_evm-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1504476 Bytes =  1.4 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... Bad Data CRC  < =========== [^o)][8-)]

Tai,

Just looking at your last entry, I would do a 'nand erase 0xa0000 0x180000' right before the 'nand write' command.  Also, I have always used the bootm command with full hex notation.  For example 'bootm 0x80700000'; not sure if it also works without the '0x' in front (it might), but if it does not, it may be trying to load the kernel from the wrong memory location which could explain the CRC, although most likely is tha nand erase.

Regarding the nand scrub command - it seems to me like a really bad idea to clear the factory bad block list.  If those addresses really ARE bad, according to the original factory tests, then you simply cannot use them.

But, after your nand scrub, you 'get no bad blocks' listed, because the command is not testing the memory - it is merely reporting the bad block list, which you just scrubbed clean.

Speculation on my part:   I think that your original bad CRC problem had to do with the size of your write (0x16000 not big enough, per Schulle).  Now I think the reason you get bad CRC is that you are writing the data to some bad blocks - so the read will be corrupted.

I think that you need to find a way to mark those blocks bad again (from your other post, you list them).  Perhaps the 'nand markbad' command.  Then these blocks should be skipped when writing to the nand.

Hi,

I have done some test with my DVEVM. My offset for the kernel is 0x400000.

-------------------------------------------------------------------------------

Hit any key to stop autoboot:  0
DM6467 HD EVM # nboot 0x80700000 0 0x400000

Loading from NAND 128MiB 3,3V 8-bit, offset 0x400000
   Image Name:   Linux-2.6.18_pro500-davinci_evm-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2009288 Bytes =  1.9 MB
   Load Address: 80008000
   Entry Point:  80008000
DM6467 HD EVM # bootm
## Booting image at 80700000 ...
   Image Name:   Linux-2.6.18_pro500-davinci_evm-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2009288 Bytes =  1.9 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux..................................................................................................................................... done, booting the kernel.
Linux version 2.6.18_pro500-davinci_evm-arm_v5t_le (root@ZO01Q00091) (gcc version 3.4.3 (MontaVista 3.4.3-25.0.30.0501131 2005-07-23)) #1 PREEMPT Thu Jul 30 11:47:01 CEST 2009
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
Machine: DaVinci DM6467 EVM
Memory policy: ECC disabled, Data cache writeback
DaVinci DM6467 variant 0x0
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets
Built 1 zonelists.  Total pages: 30720
Kernel command line: console=ttyS0,115200n8 noinitrd rw root=/dev/nfs nfsroot=192.168.1.50:/opt/HD/filesys,nolock mem=120M
PID hash table entries: 512 (order: 9, 2048 bytes)
-----------------------------------------------------

This works fine with my board.

Hi Schulle,

Did you run:

1. tftp 0x80700000 uImage
2. nand erase 0x400000 0x180000
3. nand write 0x80700000 0x400000 0x180000
4. nboot 0x80700000 0 0x400000
5. bootm 0x80700000

Is it works??

Why write to offset 0x400000 of NAND flash?

Tai

After back to office, I test the procedure below:

• TEST IN U-BOOT:

1. nand erase 400000 180000 ==> ok
2. tftp 80700000 uImage ==> ok
3. nand write 80700000 400000 180000 ==> ok
4. nboot 80700000 0 400000 ==> ok
5. bootm 80700000 ==> ok

It can be boot to kernel console without problem. 

Then I modify the Kernel side MTD layout to  "bootloader: 2M" & "params:2M" in file "boad-dm6467-evm.c" , so the kernel offset in nand flash is 0x400000, compile and boot to new MTD config kernel.

• TEST IN KERNEL CONSOLE:

Now I use flash_eraseall and nandwrite to update kernel image "uImage".

1. flash_eraseall /dev/mtd2
2. nandwrite -p /dev/mtd2 /uImage

then boot the board and set the u-boot config: bootcmd=nboot 0x80700000 0 0x400000;bootm 0x80700000

and boot kernel from nand flash...

BUT it always comes out :

Loading from NAND 128MiB 3,3V 8-bit, offset 0x400000
** Read error
## Booting image at 80700000 ...
   Image Name:   Linux-2.6.10_mvl401-davinci_evm-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1511708 Bytes =  1.4 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... Bad Data CRC

Why? I have test in u-boot side and shows OK..why doesn't in kernel side ???

Tai

Here are some printf of nandwrite:

root@10.32.62.100:/# ./nandwrite -p /dev/mtd2 /uImage

 meminfo.type=4
 meminfo.flags=197
 meminfo.size=4194304: mtd2 size
 meminfo.erasesize=131072 <== block size
 meminfo.writesize=2048  <==page size
 meminfo.oobsize=64  <== oob size
 meminfo.ecctype=2  <====???
 meminfo.eccsize=512 <=== ????
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000
Writing data to block 8 at offset 0x100000
Writing data to block 9 at offset 0x120000
Writing data to block 10 at offset 0x140000
Writing data to block 11 at offset 0x160000

root@10.32.62.100:/#

Who knows the ecctype and eccsize mean ???

Thanks,

Tai

those have to do with error correction code (ECC); it likely means which type (1-bit, 2-bit, 4-bit) and the size of the ECC block at the end.  Not sure if kernel supports all types; I believe DM6467 kernel supports 1-bit ECCs, hence if the NAND part requires 4-bit, this may be an issue.

Tai Chang said:

Why? I have test in u-boot side and shows OK..why doesn't in kernel side ??? 

 

I believe newer versions of u-boot have better NAND support than the Linux Kernel (this may be related to the 1-bit vs 4-bit ECC support)

how to solve this problem??

can you solved ??

My E-mail: wuquan-1230@163.com