AM1808 NAND ECC mode in uboot are not compatible with that in kernel and U-Boot update problem

Hi,

PSP Release 03.20.00.06 is using u-boot version 2009.01 and in that version u-boot was incompatible with ECC layout being used in kernel. Latest PSP release 03.21.00.04 is using u-boot version 2010.12 and Linux Kernel version 2.6.37. In this release both u-boot and Linux Kernel are using same ECC layouts. You can try upgrading to this release.

fahon said:

And another question is : can I update uboot from uboot ?

Practically it is possible, but it'll involve lot of steps as there is a primary boot loader in NAND which boots u-boot and when you write u-boot from u-boot, some header information has to be re-written to NAND which the primary boot loader will be expecting.

Regards, Sudhakar

Thank you for your reply.
    You said in PSP release 03.21.00.04 ,both u-boot and Linux Kernel are using same ECC layouts,but could tell me the earliest release version which have solved this problem ,because PSP release 03.21.00.04 has too much change with which I am using;
    Software version I am using：
        Arago 2009.11  JFFS2
        Linux version 2.6.32-rc6 (maybe in Release 03.20.00.08 )
        U-Boot 2009.01           (maybe in Release 03.20.00.06 )

    There is a big problem that our devices have been send to the worksite, How shoud I update the uboot without the emulator and CCS?
    So ...
    1. If I will have to update the uboot using uboot, What should I do?
    2. If I won't update the program (remain current situation (turn off the ECC in the kernel), use CONFIG_SYS_NAND_4BIT_HW_ECC in uboot and use NAND_ECC_NONE in the kernel, Is that acceptable? How about the reliability? Will it be broken quickly?
        With current situation,It runs OK, but when the kernel is booting up it prints:
        1.  NAND_ECC_NONE selected by board driver. This is not recommended !!
            Bad block table not found for chip 0
            Bad block table not found for chip 0
            Scanning device for bad blocks
            Bad eraseblock 1278 at 0x000009fc0000
        2.Empty flash at 0x005cbd98 ends at 0x005cc000
        3.JFFS2 notice: (827) check_node_data: wrong data CRC in data node at 0x00dc9d7c: read 0x50713e65, calculated 0xa8971319.
        Even so, It runs OK!

Hi,

PSP Release 03.20.00.11 having U-Boot version 2009.11 and Linux Version 2.6.33-rc4, is the earliest one where the ECC layout issue has been fixed.

As I mentioned in my earlier e-mail, there is a primary bootloader (UBL) which boots the secondary boot-loader (U-Boot). U-Boot image got from building u-boot source is prepended by a header during flashing. This header will have information about the starting block number where u-boot.bin is being flashed, number of blocks the u-boot.bin file will occupy etc. So when you update u-boot from u-boot, you have to update this header information as well. If you take care of this, then you can update u-boot from u-boot.

As NAND device is prone to errors, using ECC is recommended. The message (NAND_ECC_NONE selected by board driver. This is not recommended !!) you are seeing on the console is just a warning.

fahon said:

        2.Empty flash at 0x005cbd98 ends at 0x005cc000
        3.JFFS2 notice: (827) check_node_data: wrong data CRC in data node at 0x00dc9d7c: read 0x50713e65, calculated 0xa8971319.

Even after maintaining similar ECC layouts both in U-Boot and Linux, I have seen warning messages as above. So I feel, it is not a problem.

Regards, Sudhakar

I have upgrad uboot to 2009.11 in DaVinci-PSP-SDK-03.20.00.12，but do not upgrade kernel，
uboot and kernel both use ECC HW，uboot define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST and kernel config NAND_ECC_HW,
then use "nand erase 0x0 0x20000000",erase all the flash, then reflash ubl and uboot with CCS,
then reflash kernel and rootfs with uboot,use
"tftp 0xc0700000 uImage ; nand erase 0x300000 0x200000 ; nand write.e 0xc0700000 0x300000 0x200000"
"tftp 0xc1180000 rootfs.jffs2 ; nand erase 0x500000 0x4000000 ; nand write.jffs2 0xc1180000 0x500000 0x800000"
rootfs.jffs2 image is made using "./mkfs.jffs2 -r targetNFS -o rootfs.jffs2 -e 0x20000 --pad=0x800000 -s 0x800 -n"
mkfs.jffs2: revision 1.39 bin for i386 is downloaded from http://sources.redhat.com/jffs2/

but while kernel mount rootfs it prints "returned ECC error"，but It runs OK，and the error addresses are different each booting time
nand partitions are like below，you can see the ECC error address is at the begin section of rootfs, 2 boards are the same situation.
Creating 6 MTD partitions on "davinci_nand.1":
0x000000000000-0x000000020000 : "u-boot env"
0x000000020000-0x000000040000 : "UBL"
0x000000040000-0x0000000c0000 : "u-boot"
0x000000300000-0x000000500000 : "kernel"
0x000000500000-0x000004500000 : "filesystem"
0x000004500000-0x000020000000 : "user"

when booting it prints like:
PHY: 1:00 - Link is Up - 100/Full
mtd->read(0x1fa10 bytes from 0x5c05f0) returned ECC error
mtd->read(0x14264 bytes from 0x5cbd9c) returned ECC error
Empty flash at 0x005cbd98 ends at 0x005cc000
Empty flash at 0x023be858 ends at 0x023bf000
VFS: Mounted root (jffs2 filesystem) on device 31:4.
Freeing init memory: 124K
mtd->read(0x7bc bytes from 0x5cc044) returned ECC error
INIT: version 2.86 booting
Please wait: booting...
Starting udev
Populating dev cachemtd->read(0x44 bytes from 0x5cc7ec) returned ECC error
mtd->read(0x44 bytes from 0x5cff00) returned ECC error
mtd->read(0x44 bytes from 0x5d1684) returned ECC error
mtd->read(0x14a bytes from 0x5d16c8) returned ECC error
mtd->read(0x44 bytes from 0x5d27d0) returned ECC error
mtd->read(0x44 bytes from 0x5d5ec4) returned ECC error
mtd->read(0x44 bytes from 0x5d6ff0) returned ECC error
mtd->read(0x44 bytes from 0x5d8798) returned ECC error
mtd->read(0x125 bytes from 0x5d87dc) returned ECC error
mtd->read(0x44 bytes from 0x5da6dc) returned ECC error
mtd->read(0x44 bytes from 0x5dbfdc) returned ECC error
mtd->read(0x44 bytes from 0x5ddf1c) returned ECC error

Remounting root file system...
root: mount: mounting rootfs on / failed: No such file or directory
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces... done.
INIT: Entering runlevel: 3
Starting telnet daemon.
Starting syslogd/klogd: done

Hi, Sudhakar.

I got a u-boot version 2010.12 shipped with PSP release 03.21.00.04.

But this u-boot can't read nand flash correctly.

My am1808 board has a K9F2G08U0B-PCB0 nand flash.

Have you ever come across such problem?

the output of u-boot.

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

AM1808 initialization passed!
Booting TI User Boot Loader
        UBL Version: 1.65
        UBL Flashtype: NAND
Starting NAND Copy...
Valid magicnum, 0x55424CBB, found in block 0x00000006.
   DONE
Jumping to entry point at 0xC1080000.
NAND:  256 MiB
MMC:   davinci: 0
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
nand_read_bbt: Bad block at 0x00000e3c0000
*** Warning - bad CRC, using default environment

and this is the configuration in da850evm.h

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

/*
 * Flash & Environment
 */
#ifdef CONFIG_USE_NAND
#undef CONFIG_ENV_IS_IN_FLASH
#define CONFIG_NAND_DAVINCI
#define CONFIG_SYS_NO_FLASH
#define CONFIG_ENV_IS_IN_NAND           /* U-Boot env in NAND Flash  */
#define CONFIG_ENV_OFFSET               0x0 /* Block 0--not used by bootcode */
#define CONFIG_ENV_SIZE                 (128 << 10)
#define CONFIG_SYS_NAND_USE_FLASH_BBT
//#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
#define CONFIG_SYS_NAND_PAGE_2K
#define CONFIG_SYS_NAND_CS              3
#define CONFIG_SYS_NAND_BASE            DAVINCI_ASYNC_EMIF_DATA_CE3_BASE
#define CONFIG_SYS_CLE_MASK             0x10
#define CONFIG_SYS_ALE_MASK             0x8
#define CONFIG_SYS_NAND_HW_ECC
#define CONFIG_SYS_MAX_NAND_DEVICE      1 /* Max number of NAND devices */
#define NAND_MAX_CHIPS                  1
#endif

Hi,

This error is because environment variables is saved by the previous boot loader which was using a different ECC algorithm when compared to the latest one that you've flashed. If you save the env variables again, it will write using the new ECC algorithm and the error will get resolved.

-Renjith

www.pathpartnertech.com