Appro 5.1

Hi,

1. following blocks are shown as bad blocks:
        0x000000400000 - 0x0000007e0000
        0x000002140000 - 0x0000023e0000

If you want to check those blocks are really bad,  you can see all bad blocks get skipped/listed during nand srcub as you said

0x400000 ---> this location is kernel area

it could be mismatch ECC types between bootloader & kernel

Try to change the ECC type in board file   

".ecc_mode        = NAND_ECC_HW,"

   .ecc_mode        = NAND_ECC_SW,

   .ecc_mode        = NAND_ECC_HW_SYNDROME,

use anyone of this & flash kernel with these modification compiled image

Which ECC type are you using?

UBIFS

-----------

Refer the below links for UBIFS suport

http://processors.wiki.ti.com/index.php/UBIFS_Support
http://elinux.org/UBIFS
http://processors.wiki.ti.com/index.php/TI-Android-GingerBread-2.3.4-DevKit-2.1_UserGuide#Fastboot_and_UBI_rootfs

           mkfs.ubifs -r  filesys_dm365 -m 2048 -e 126976 -c 313 -o ubifs.img

For 32MB fs storage , 313 is it OK?

See

Boot your s/m in NFS mode , flash the filesystem with UBIFS type then try to mount the partition (for testing) then go for initial UBIFS mounting (through bootargs and all)

In target shell (NFS boot)

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

# flash_eraseall /dev/mtd3

# ubiformat /dev/mtd3 -s 512 -y   (

# ubiattach /dev/ubi_ctrl -m 3

# mount -t ubifs ubi0:ubi-rootfs /mnt/

make any changes as you want

# umount /mnt

# ubidetach /dev/ubi_ctrl -m 3

Regards,

Titus S.

Refer the below link for UBIFS suport

Hi,
       Thank's for your reply.

         Checked ECC in u-boot and kernel, earlier "NAND_ECC_HW_SYNDROME" was set in u-boot and "NAND_ECC_HW" in kernel. For UBIFS the value used for argument -c(313) was wrong. Calculated this value and got 250.

 Tried by setting same ECC in u-boot and kernel and following is the result:

NAND_ECC_HW:
     Getting bad block issue

NAND_ECC_SW:
     Showing bad blocks at 02900000 - 02fe0000(This area is after the filesystem partition)
     We are able to Load UBIFS if programmed from linux,following are the steps done:
         -Done NFS boot
     -Erased filesystem partition using command "flash_eraseall /dev/mtd3"
     -Flashed filesystem using command "flashcp filesystem_image /dev/mtd3"
         -Then tried to do NAND boot with bootargs.
   But not able to load UBIFS if programmed from u-boot.

NAND_ECC_HW_SYNDROME:
     NAND driver probe failed - "davinci_nand: probe of davinci_nand.0 failed with error -22"

Regards,
   Geethu
     
    



     
    

Hi,

NAND BAD BLCOK

You can use "NAND_ECC_HW" type ECC

I think, you are using wrong SDK's (may be your using new SDK's kernel with old SDK's uboot) (mismatch versions)

i faced the same kind of issue when i try to use new kernel with old uboot binary.

UBIFS

We are able to Load UBIFS if programmed from linux,following are the steps done:
         -Done NFS boot
     -Erased filesystem partition using command "flash_eraseall /dev/mtd3"
     -Flashed filesystem using command "flashcp filesystem_image /dev/mtd3"

Can you able to list/check the filesystem, which you have written while you are in NFS mode?

do the below commands after NFS boot (copy rootfs.ubi file into NFS fs)

flash_eraseall /dev/mtd3

ubiformat /dev/mtd3 -f rootfs.ubi -O 512  (chk it)

ubiattach /dev/ubi_ctrl -m 3

mount -t ubifs ubi0 /mnt

ls /mnt          (check here ; all files are avail?)

>> If you able to see properly(without any errors) then only u can able to mount initial time(thr bootargs)

umount /mnt

ubidetach /dev/ubi_ctrl -m 3

NOTE

Do you have any intended reason to boot with ubifs & why not yaffs2?

yaffs2 is much easier than ubifs (steps)

Hi,

Can you please provide complete bootup log (top to bottom) start with bootloader upto error.

You can list actual bad blocks list at uboot section by "nand bad" command & paste that too

Are you getting any error while you are doing "saveenv"?

What SDK version are you using?

Hi,

Refer my old post,

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/204957/727450.aspx#727450

I got fixed this by doing the below things,

Have a try,

Scenario (How i hv faced this issue on my custom board?)

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

In my custom board, very first time i have flashed 2.6.18 kernel (LSP2.10) & with the same old LSP2.10's u-boot

after that i flashed new u-boot & kernel (LSP3.10 of TI), then i got the bad block errors,

This is because of due to bbt (bad block table) of  old with new one(type of ECC)

Fix

===

I have used new PSP3.10's kernel image & u-boot,

1) flashed ubl (old) & , u-boot(old)

2) nand scrub

3) flash new UBL, u-boot & kernel

fixed !!!

Hi,

Bad blocks listed after NAND scrub:
===========================================================================
 03960000
 052a0000
 07760000
 077c0000
 07f80000
 07fa0000
 07fc0000
 07fe0000

Bad blocks listed after flashing Kernel,filesystem and doing NAND boot :
===========================================================================
  00200000
  00400000
  00420000
  00440000
  00460000
  00480000
  004a0000
  004c0000
  004e0000
  00500000
  00520000
  00540000
  00560000
  00580000
  005a0000
  005c0000
  005e0000
  00600000
  00620000
  00640000
  00660000
  00680000
  006a0000
  006c0000
  006e0000
  00700000
  00720000
  00740000
  00760000
  00780000
  007e0000
  02160000
  02180000
  021a0000
  021c0000
  021e0000
  02200000
  02220000
  02240000
  02260000
  02280000
  022a0000
  022c0000
  022e0000
  02300000
  02320000
  02340000
  02360000
  02380000
  023a0000
  023c0000
  023e0000
  03960000
  052a0000
  07760000
  077c0000
  07f80000
  07fa0000
  07fc0000
  07fe0000

     After getting these bad blocks if we give saveenv getting error:
                 Saving Environment to NAND...
         Erasing Nand...
         Skipping bad block at  0x00200000                                            
         Writing to Nand... FAILED!

    We are using SDK5.1
    Please find the attached logs.

Regards,
   Geethu

7041.log.txt

Hi,

  I tried the fix you suggested :

      1) flashed ubl (old) & , u-boot(old)

      2) nand scrub

      3) flash new UBL, u-boot & kernel

But getting the same issue.

Regards,

    Geethu

Hi,

How you are flashing the UBL & U-boot? (SD card or nandwriter or serial flasher)

Can you try to flash to your ubl & u-boot bn through serial flasher utility?

Please provide NAND Part no?

Refer the below link & verfiy the NAND ECC layout in your ubl & u-boot code

http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout

Do you have any command like "nand ecc hw" in u-boot terminal?

Try to boot the board from ramdisk & flash kernel image and filesystem into NAND flash through mtd-utils (ie flashing kernel & fs with ECC layout of linux)
It seems to be issue with ECC layout of u-boot.

Is this your custom board or TI EVM?
if it is custom, Aru using same nand flash in your board as EVM?

Hi,

Try to flash kernel image & fs by linux ECC type (from linux shell)

do the below commands after NFS boot (copy rootfs.ubi file & kernel into NFS fs)

Kernel

=======

copy the kernel image into NFS fs folder

$ flash_eraseall /dev/mtd2  (kernel partition)

$ nandwrite -p /dev/mtd2 /uImage_ipnc_dm365 (flashing kernel at 0x400000 to 0x900000)

Filesystem

==========

flash_eraseall /dev/mtd3

ubiformat /dev/mtd3 -f rootfs.ubi -O 512  (chk it)

ubiattach /dev/ubi_ctrl -m 3

mount -t ubifs ubi0 /mnt

ls /mnt          (check here ; all files are avail?)

>> If you able to see properly(without any errors) then only u can able to mount initial time(thr bootargs)

umount /mnt

ubidetach /dev/ubi_ctrl -m 3

Hi,

    Thank's for your replay.

    We will try these suggestions.

Regards,

   Geethu

Hi

We are using kernel 2.6.32 and we are facing following error on TI  DM355 Evm

Our NAND is spansion S34ML08G1.

our nand ECC bit is 1

uncorrectable error :

Please reply me as soon as possible

Hi Tejas Dave,

Did you resolve the issue you were chasing?

Setup: DM368 based IP camera.

I'm chasing something somewhat related.  I have about 30k devices deployed.  We're rolling out a new build of firmware.  What I've found is that the flash_eraseall on the yaffs2 partition occasionally fails or leaves the device in an incomplete state.  After the erase no files are able to be written to the partition until a hard power cycle occurs.

This causes a portion of our upgrades to fail the upgrade process... and in this case dumps us back out to UBOOT.... which is unacceptable....

Could this possibly be explained by kernel settings:

board-dm365-evm.c: ~333

static struct nand_davinci_platform_data nand_data = {
 .options = 0,
 .ecc_mode = NAND_ECC_HW_SYNDROME,   /* Reed-Solomon with inline syndrome */
 /* .ecc_mode = NAND_ECC_SOFT, */
 /* .ecc_mode = NAND_ECC_HW, */

or perhaps using an old UBOOT version?

We're currently still using our original UBOOT build from ~2009.  We had updated the UBL to fix a soft boot hang problem.. but hadn't yet been motivated to upgrade the UBOOT...

Regards,

Edwin