Bad block in nand uImage after ESIA/EPIA installation

[lyzby]

I have used the ESIA/EPIA installer to try to install two of the distributions in the distro folder to nand (squeeze and ubuntu), and the program reports successful completion, but for both when I try to boot, I get a NAND read "Bad block at 0x2a0000" error message, which causes a bad checksum and failure to boot.  This is on an original Sheevaplug.

Here is the message: 
---------------------------------
...
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x100000, size 0x400000

Bad block at 0x2a0000 in erase block from 0x2a0000 will be skipped
Reading data from 0x51f800 -- 100% complete.
4194304 bytes read: OK
## Booting image at 00800000 ...
   Image Name:   Linux-2.6.33
   Created:      2010-03-02  21:27:23 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2840500 Bytes =  2.7 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
Marvell>>
-----------------------------
This seems different from the other "Bad Block" threads I have looked at.  Is there something I can do to have this block marked bad, so the installer doesn't use it, or can I install to and boot from a different location from 0x100000?

[tylernt]

Bad blocks in NAND are common enough that the tools should deal with them automatically. u-Boot, for example, has 'read.e' and 'write.e' commands which are enhanced versions of 'read' and 'write', respectively, that automatically skip bad blocks.

Indeed, the message you posted includes "Bad block at 0x2a0000 in erase block from 0x2a0000 will be skipped" which leads me to believe that the correct 'read.e' command is being used by u-Boot. However, perhaps the ESIA installer didn't use 'write.e' or it's equivalent, so maybe some of your kernel data was lost in that bad block? If so, I'm not sure how to fix ESIA...

[lyzby]

I suspect you are right that ESIA/EPIA does not use "write.e".  The command, "nand bad" indeed shows 0x2a0000 as bad.  The installer produces a log file of the uBoot commands it uses, but does not include any "write" commands.  So I would guess that the actual write commands are within the instImg file on the usb drive which the installer uses. 

I had thought this was not an installer issue, since it reported a successful installation, but it may be.  I'll report it in the installer thread.  But if anyone has any other ideas, I'ld like to hear.

[rooster]

Hi,

It looks like that is the issue, that latest ESIA uses dd instead of nand bad block aware API, can you try old ESIA version and see if it resolves the bad block issue?

[rooster]

oops, I verified on older versions and it is the same, regular cp of uImage  instead of using nandwrite, initrd needs to be updated

[blueqoo0321]

Hi lyzby

Its common to see bad blocks on NAND, due to it's architecture.

there's a uboot env called "nandEcc ".

HAMMING Algo ==> set nandEcc '1bit'
REED SOLOMON Algo==> set nandEcc '4bit'
Hamming algo read data from NAND faster but it's only 1bit correction.
(compare to RS, Hamming generate bad block faster, in theory)
RS algo read data slower, but 4bit correction.
Its a trade off.

After UBOOT, there's a lot of NAND file systems you can try. (JFFS2, cramfs, ubifs...etc)

To avoid bad block problem, mount RAMDISK + MTD(ubifs) maybe a good combination.

Actually boot from SPI and using NAND as storage device is better than put all stuff in NAND.
(put uboot + kernel at SPI flash)
But MPPs have to change settings .......
also means BOM cost higher, need more place to put SPI.  means > $99    oops!   



Regards
 

I have used the ESIA/EPIA installer to try to install two of the distributions in the distro folder to nand (squeeze and ubuntu), and the program reports successful completion, but for both when I try to boot, I get a NAND read "Bad block at 0x2a0000" error message, which causes a bad checksum and failure to boot.  This is on an original Sheevaplug.

Here is the message: 
---------------------------------
...
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x100000, size 0x400000

Bad block at 0x2a0000 in erase block from 0x2a0000 will be skipped
Reading data from 0x51f800 -- 100% complete.
4194304 bytes read: OK
## Booting image at 00800000 ...
   Image Name:   Linux-2.6.33
   Created:      2010-03-02  21:27:23 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2840500 Bytes =  2.7 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
Marvell>>
-----------------------------
This seems different from the other "Bad Block" threads I have looked at.  Is there something I can do to have this block marked bad, so the installer doesn't use it, or can I install to and boot from a different location from 0x100000?

[lyzby]

Ok, after a week of reading and doing other stuff and installing debian lenny and squeeze to usb and sd, I finally thought I might know enough to come back and get this to work.

I reran the ESIA/EPIA installer for the Ubuntu 9.04 version, and it reported success, but failed again on rebooting as expected with the error for the bad block at 0x02a0000.  But this left everything set up for correct booting, including the environmental variables.  I loaded the uImage file to memory from the usb drive, erased the uImage nand partition, wrote the file from memory with 'nand write.e" to take into account the bad block, and then booted successfully.  I used the following commands.

usb start
fatload usb 0 0x800000 /Ubuntu904/uImage
nand erase clean 0x00100000 0x00400000
nand write.e 0x800000 0x100000 0x300000
boot

The 'nand erase clean' was necessary.  From the Ubuntu prompt, 'reboot' returns to Ubuntu, booting from nand flash.  The bad block is noted, but skipped.