• State Resolved
  • Locked Locked
  • Replies 19 replies
  • Subscribers 102 subscribers
  • Views 5893 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM1808 NAND Boot, ECC Errors

Benjamin Burns
Prodigy 185 points
Other Parts Discussed in Thread: AM1808

I am trying to bring up a custom board based on the AM1808.  I'd like to boot this board from NAND flash.  I currently have uBoot installed on the NAND and it is working properly to store and load my kernel image.  The kernel appears to init properly, and I see it detect my NAND correctly.  When it finishes its init code, I see it free the init memory and attempt to load the filesystem.  My console is immediately flooded with messages like the following:

<4>Returned error for crccheck of ino #4796. Expect badness...
<4>mtd->read(0xbc bytes from 0xd95f44) returned ECC error
<4>mtd->read(0x44 bytes from 0xd95f44) returned ECC error

Unfortunately I do not have a network interface on this board, so I have to resort to uBoot to load my filesystem into NAND, unless there is some other option I am overlooking.

I have checked the following:
 - mkfs.jffs2 was ran with the correct erase block size
 - NAND partition boundaries are correct
 - uBoot's ECC layout matches the ECC layout in my kernel
 - attempted to load the filesystem with both 'nand write.jffs2' and 'nand write' commands

 

I created the filesystem image with the following command:
mkfs.jffs2 -p -rmydir -e128 -orootfs.jffs2

One small idiosyncrasy is that due to RAM limitations I need to load the filesystem in 8MiB chunks.  After generating the JFFS2 image I split it with:
split -b 8M rootfs.jffs2

I then load it through uBoot with the following commands:

loady
-- first chunk transfers --
nand write.jffs2 0xc0700000 0x600000 0x800000
-- first chunk is written to NAND --
loady
-- second chunk transfers --
nand write.jffs2 0xc0700000 0xE00000 0x640000 
-- second chunk is written to nand --

Does uBoot expect a full JFFS2 image when I run 'nand write.jffs2' ?  Is there an alternate command that will allow me to transfer my image in chunks?

 

Thanks in advance for any reply.

 

  • 0
    Prodigy 185 points

    Just a quick update, below you will find some relevant snippets of my boot log.  Note where it says it mounted the root filesystem successfully...

     

     

    <7>calling  nand_base_init+0x0/0x14 @ 1

    <7>initcall nand_base_init+0x0/0x14 returned 0 after 2 usecs

    <7>calling  nand_davinci_init+0x0/0x30 @ 1

    <6>ONFI flash detected

    <6>ONFI param page 0 valid

    <6>NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron MT29F4G08ABADAWP)

    <7>Bad block table found at page 262080, version 0x01

    <7>Bad block table found at page 262016, version 0x01

    <5>Creating 5 MTD partitions on "davinci_nand.1":

    <5>0x000000000000-0x000000020000 : "u-boot env"

    <5>0x000000020000-0x000000040000 : "UBL"

    <5>0x000000040000-0x0000000c0000 : "u-boot"

    <5>0x000000200000-0x000000600000 : "kernel"

    <5>0x000000600000-0x000020000000 : "filesystem"

    <6>davinci_nand davinci_nand.1: controller rev. 2.5

    <7>initcall nand_davinci_init+0x0/0x30 returned 0 after 140512 usecs

     

     

    <snip>

     

     

    <7>calling  ip_auto_config+0x0/0xef4 @ 1

    <7>initcall ip_auto_config+0x0/0xef4 returned 0 after 61 usecs

    <7>calling  initialize_hashrnd+0x0/0x24 @ 1

    <7>initcall initialize_hashrnd+0x0/0x24 returned 0 after 47 usecs

     

     

    async_waiting @ 1

    async_continuing @ 1 after 6 usec

    <4>mtd->read(0x1fdf8 bytes from 0xd80208) returned ECC error

    <4>mtd->read(0xbf44 bytes from 0xd940bc) returned ECC error

    <4>Empty flash at 0x00d940b8 ends at 0x00d94800

    <4>mtd->read(0x510 bytes from 0xd9a2f0) returned ECC error

    VFS: Mounted root (jffs2 filesystem) on device 31:4.

    async_waiting @ 1

    async_continuing @ 1 after 6 usec

    <6>Freeing init memory: 144K

    <4>mtd->read(0x6b0 bytes from 0xd96950) returned ECC error

    <4>mtd->read(0x3e4 bytes from 0xd9b41c) returned ECC error

    <4>Node CRC 00000000 != calculated CRC 3454d0ec for node at 000af95c

    <4>mtd->read(0x704 bytes from 0xd9e8fc) returned ECC error

    <4>mtd->read(0x3dc bytes from 0xd9a424) returned ECC error

    <4>mtd->read(0x3e0 bytes from 0xd97420) returned ECC error

    <4>mtd->read(0x410 bytes from 0xd973f0) returned ECC error

    <4>mtd->read(0x448 bytes from 0xd973b8) returned ECC error

    <4>mtd->read(0x47c bytes from 0xd97384) returned ECC error

    <4>mtd->read(0x288 bytes from 0xd95d78) returned ECC error

    <4>mtd->read(0x6d8 bytes from 0xd95128) returned ECC error

    <4>mtd->read(0x804 bytes from 0xd95ffc) returned ECC error

    <4>mtd->read(0x7bc bytes from 0xd94844) returned ECC error

    <4>mtd->read(0x74 bytes from 0xd95f8c) returned ECC error

    <4>mtd->read(0x3e0 bytes from 0xd95c20) returned ECC error

    <4>mtd->read(0x6dc bytes from 0xd94924) returned ECC error

    <4>Node CRC 00000000 != calculated CRC 003cc291 for node at 000c6994

    <4>mtd->read(0x3e4 bytes from 0xd9b41c) returned ECC error

    <4>mtd->read(0x804 bytes from 0xd95ffc) returned ECC error

    <4>mtd->read(0x74 bytes from 0xd95f8c) returned ECC error

    <4>mtd->read(0x3e0 bytes from 0xd95c20) returned ECC error

    <4>mtd->read(0x6dc bytes from 0xd94924) returned ECC error

    <4>mtd->read(0x7a4 bytes from 0xd9e85c) returned ECC error

    <4>mtd->read(0x800 bytes from 0xd9e800) returned ECC error

    <4>mtd->read(0x68c bytes from 0xd9e174) returned ECC error

    <4>mtd->read(0x6e0 bytes from 0xd9c120) returned ECC error

    <4>mtd->read(0x240 bytes from 0xd9bdc0) returned ECC error

    <4>mtd->read(0x37c bytes from 0xd9bc84) returned ECC error

    <4>mtd->read(0x4a0 bytes from 0xd9bb60) returned ECC error

    <4>mtd->read(0x534 bytes from 0xd9bacc) returned ECC error

    <4>mtd->read(0x660 bytes from 0xd9b9a0) returned ECC error

    <4>mtd->read(0x718 bytes from 0xd9b8e8) returned ECC error

    <4>mtd->read(0x770 bytes from 0xd9b890) returned ECC error

    <4>mtd->read(0x7bc bytes from 0xd9b844) returned ECC error

    <4>mtd->read(0x424 bytes from 0xd95bdc) returned ECC error

    <5>JFFS2 notice: (458) jffs2_get_inode_nodes: Node header CRC failed at 0x000510. {4fe5,2100,02e054ac,9e003008}

    <4>mtd->read(0x6d0 bytes from 0xd9b930) returned ECC error

    <4>mtd->read(0x800 bytes from 0xd9b800) returned ECC error

    <4>mtd->read(0x790 bytes from 0xd94870) returned ECC error

    <4>mtd->read(0x800 bytes from 0xd94800) returned ECC error

    <4>JFFS2 warning: (458) jffs2_do_read_inode_internal: no data nodes found for ino #13

    <4>Returned error for crccheck of ino #13. Expect badness...

    <4>mtd->read(0x2c0 bytes from 0xd9bd40) returned ECC error

    <4>mtd->read(0x304 bytes from 0xd9bcfc) returned ECC error

    <4>mtd->read(0x3fc bytes from 0xd9bc04) returned ECC error

    <4>mtd->read(0x440 bytes from 0xd9bbc0) returned ECC error

    <4>mtd->read(0x5a0 bytes from 0xd9ba60) returned ECC error

    <4>mtd->read(0x5e4 bytes from 0xd9ba1c) returned ECC error

    <4>mtd->read(0xc0 bytes from 0xd9b740) returned ECC error

    <4>mtd->read(0x104 bytes from 0xd9b6fc) returned ECC error

    <5>JFFS2 notice: (458) jffs2_get_inode_nodes: Node header CRC failed at 0x069ba0. {b244,4e15,4e15b244,00000070}

    <4>mtd->read(0x184 bytes from 0xd9b67c) returned ECC error

    <4>mtd->read(0x1c8 bytes from 0xd9b638) returned ECC error

    <4>mtd->read(0x210 bytes from 0xd9b5f0) returned ECC error

    <4>mtd->read(0x264 bytes from 0xd9b59c) returned ECC error

    <4>mtd->read(0x2e4 bytes from 0xd9b51c) returned ECC error

    <4>mtd->read(0x328 bytes from 0xd9b4d8) returned ECC error

    <4>mtd->read(0x374 bytes from 0xd9b48c) returned ECC error

    <4>mtd->read(0x484 bytes from 0xd9b37c) returned ECC error

    <4>mtd->read(0x504 bytes from 0xd9b2fc) returned ECC error

    <4>mtd->read(0x548 bytes from 0xd9b2b8) returned ECC error

    <4>mtd->read(0x590 bytes from 0xd9b270) returned ECC error

    <4>mtd->read(0x5ec bytes from 0xd9b214) returned ECC error

    <4>mtd->read(0x658 bytes from 0xd9b1a8) returned ECC error

    <4>mtd->read(0x69c bytes from 0xd9b164) returned ECC error

    <4>mtd->read(0x6e8 bytes from 0xd9b118) returned ECC error

    <4>mtd->read(0x74c bytes from 0xd9b0b4) returned ECC error

    <4>mtd->read(0x1f8 bytes from 0xd9a608) returned ECC error

    <4>JFFS2 warning: (458) jffs2_do_read_inode_internal: no data nodes found for ino #32

    <4>mtd->read(0x240 bytes from 0xd9a5c0) returned ECC error

    <4>mtd->read(0x298 bytes from 0xd9a568) returned ECC error

    <4>mtd->read(0x2e4 bytes from 0xd9a51c) returned ECC error

    <4>mtd->read(0x364 bytes from 0xd9a49c) returned ECC error

    <4>mtd->read(0x3a8 bytes from 0xd9a458) returned ECC error

    <4>mtd->read(0x4a0 bytes from 0xd9a360) returned ECC error

    <4>mtd->read(0x4e4 bytes from 0xd9a31c) returned ECC error

    <4>mtd->read(0x608 bytes from 0xd9a1f8) returned ECC error

    <4>mtd->read(0x64c bytes from 0xd9a1b4) returned ECC error

    <4>mtd->read(0x6cc bytes from 0xd9a134) returned ECC error

    <4>mtd->read(0x710 bytes from 0xd9a0f0) returned ECC error

    <4>mtd->read(0x7bc bytes from 0xd9a044) returned ECC error

    <4>Returned error for crccheck of ino #32. Expect badness...

    <4>mtd->read(0x800 bytes from 0xd9a000) returned ECC error

    <4>mtd->read(0x340 bytes from 0xd99cc0) returned ECC error

    <4>mtd->read(0x384 bytes from 0xd99c7c) returned ECC error

    <4>mtd->read(0x2a4 bytes from 0xd9755c) returned ECC error

    <4>mtd->read(0x324 bytes from 0xd974dc) returned ECC error

    <4>mtd->read(0x368 bytes from 0xd97498) returned ECC error

    <4>mtd->read(0x3ac bytes from 0xd97454) returned ECC error

    <4>mtd->read(0x3c4 bytes from 0xd96c3c) returned ECC error

    <4>mtd->read(0x408 bytes from 0xd96bf8) returned ECC error

    <4>mtd->read(0x154 bytes from 0xd966ac) returned ECC error

    <4>mtd->read(0x198 bytes from 0xd96668) returned ECC error

    <4>mtd->read(0x498 bytes from 0xd96368) returned ECC error

    <4>mtd->read(0x4dc bytes from 0xd96324) returned ECC error

    <5>JFFS2 notice: (458) jffs2_get_inode_nodes: Wrong magic bitmask 0x0000 in node header at 0x069c1c.

    <4>mtd->read(0x548 bytes from 0xd962b8) returned ECC error

    <4>mtd->read(0x58c bytes from 0xd96274) returned ECC error

    <4>mtd->read(0x60c bytes from 0xd961f4) returned ECC error

    <4>mtd->read(0x650 bytes from 0xd961b0) returned ECC error

    <4>mtd->read(0x6d0 bytes from 0xd96130) returned ECC error

    <4>mtd->read(0x714 bytes from 0xd960ec) returned ECC error

    <4>mtd->read(0x794 bytes from 0xd9606c) returned ECC error

    <4>mtd->read(0x7d8 bytes from 0xd96028) returned ECC error

    <4>mtd->read(0x210 bytes from 0xd95df0) returned ECC error

    <4>mtd->read(0x254 bytes from 0xd95dac) returned ECC error

    <4>mtd->read(0x79c bytes from 0xd95064) returned ECC error

    <4>mtd->read(0x7e0 bytes from 0xd95020) returned ECC error

    <4>mtd->read(0x824 bytes from 0xd94fdc) returned ECC error

    <4>mtd->read(0xa4 bytes from 0xd94f5c) returned ECC error

    <4>mtd->read(0xe8 bytes from 0xd94f18) returned ECC error

    <4>JFFS2 warning: (458) jffs2_do_read_inode_internal: no data nodes found for ino #33

    <4>mtd->read(0x168 bytes from 0xd94e98) returned ECC error

    <4>mtd->read(0x1ac bytes from 0xd94e54) returned ECC error

    <4>mtd->read(0x22c bytes from 0xd94dd4) returned ECC error

    <4>mtd->read(0x270 bytes from 0xd94d90) returned ECC error

    <4>mtd->read(0x2f0 bytes from 0xd94d10) returned ECC error

    <4>mtd->read(0x334 bytes from 0xd94ccc) returned ECC error

    <4>mtd->read(0x3b4 bytes from 0xd94c4c) returned ECC error

    <4>mtd->read(0x3f8 bytes from 0xd94c08) returned ECC error

    <4>mtd->read(0x478 bytes from 0xd94b88) returned ECC error

    <4>mtd->read(0x4bc bytes from 0xd94b44) returned ECC error

    <4>mtd->read(0x53c bytes from 0xd94ac4) returned ECC error

    <4>mtd->read(0x580 bytes from 0xd94a80) returned ECC error

    <4>mtd->read(0x600 bytes from 0xd94a00) returned ECC error

    <4>Returned error for crccheck of ino #33. Expect badness...

    <4>mtd->read(0x644 bytes from 0xd949bc) returned ECC error

    <4>mtd->read(0x6b0 bytes from 0xd94950) returned ECC error

    <4>mtd->read(0x720 bytes from 0xd948e0) returned ECC error

     

  • 0 in reply to Benjamin Burns
    Prodigy 185 points

    I managed to fix the problem by upgrading to the latest (2011.09) version of u-Boot, rather than the version included with the latest SDK release and by adding support to the build for the nand write.trimffs command.

    To add the nand write.trimffs command, add "#define CONFIG_CMD_NAND_TRIMFFS" directly after "#define CONFIG_CMD_NAND" in includes/configs/da850evm.h

    This should work on other platforms using the davinci_nand MTD driver which are experiencing these errors.

    At this point, follow the normal instructions for writing a JFFS2 filesystem to NAND as you would for any other platform, but instead of using this uBoot command "nand write.jffs2," use the command "nand write.trimffs"

     

    Why?

    See this patch: http://lists.denx.de/pipermail/u-boot/2011-April/091588.html

    Apparently u-Boot's "nand write.jffs2" command will write empty pages.  Because erased pages are different than pages written to all FF's, the kernel attempts to perform ECC operations here.  The above patch causes write.jffs2 to skip empty pages during writes to NAND.

    The patch has since been reworked for the 2011.09 release of u-Boot such that "nand write.jffs2" does not change its behavior, and instead the behavior added by the patch has been moved to the specialized command "nand write.trimffs."  This is considered an edge case (probably davinci_nand driver detects empty pages differently than most others), so it must be configured separately from regular NAND commands (hence the extra #define above).

    Finally, this command successfully allows the filesystem to be written to NAND *very quickly* via JTAG by using u-Boot in place of the NANDWriter utility (with some manual intervention).  This will only be quicker with the more "enterprise class" JTAG devices, such as the XDS560 and friends, as the XDS100v2 is fixed to 1Mhz operation.  If you're using the XDS100v2 or similar, and if like me you don't have ethernet on your board, you're better off to load filesystem images via YMODEM with the 'loady' command in u-Boot.

    I'll be updating the wiki shortly with this information here - http://processors.wiki.ti.com/index.php/Put_JFFS2_Image_to_Flash#NAND_Flash

  • 0 in reply to Benjamin Burns
    Prodigy 150 points

    Hi.

     

    I'm working on my cutomed AM1808 board which has a Nand flash for system storage.

    I downloaded the 2011.09  u-boot, and use nand write.trimffs to burn jffs2 filesytem into nand flash. But still, there are lots of warning during boot

    Empty flash at 0x04f265c4 ends at 0x04f265c8
    Empty flash at 0x04f265cc ends at 0x04f265e0
    Empty flash at 0x04f265e8 ends at 0x04f265ec
    Empty flash at 0x04f265f0 ends at 0x04f265f8
    Empty flash at 0x04f265fc ends at 0x04f26610
    Empty flash at 0x04f26614 ends at 0x04f26620
    Empty flash at 0x04f2662c ends at 0x04f26630

    .........

    this is the linux kernle (2.6.37) configuration

    static struct davinci_nand_pdata da850_evm_nandflash_data = {
            .parts          = da850_evm_nandflash_partition,
            .nr_parts       = ARRAY_SIZE(da850_evm_nandflash_partition),
            .ecc_mode       = NAND_ECC_HW,
            .ecc_bits       = 4,
            .options        = NAND_USE_FLASH_BBT,
            .timing         = &da850_evm_nandflash_timing,
    };

     

    this is the u-boot config

    #define CONFIG_NAND_DAVINCI

    #define CONFIG_CMD_NAND_TRIMFFS

    #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
    #undef CONFIG_SYS_NAND_HW_ECC
    //#define CONFIG_SYS_NAND_HW_ECC
    #define CONFIG_SYS_MAX_NAND_DEVICE      1 /* Max number of NAND devices */
    #define NAND_MAX_CHIPS                  1

     

     

    thanks & best regards

  • 0 in reply to gogo49087
    Prodigy 185 points

    Let's open a new thread for your problem, gogo, as it may be a separate issue (albeit related) and this thread is already answered properly.  Also, please attach a full boot log to your new post.  I'm not sure how your memory is laid out but I can tell you that I see similar errors in my build when my init scripts are investigating MTD partitions which are not JFFS2 formatted (mtdblock0-mtdblock3, for instance).  If that's what's happening here, we'll be able to tell from your boot logs.

  • 0 in reply to Benjamin Burns
    Intellectual 420 points

    Hi Benjamin,

    We have these ECC errors on custom board for JFFS2 File System. (uboot 2010.12 and  linux 2.6.37 based on PSP 03.21.00.004)

    Which images of JFFS2 did you try based on arago or OE? Or Did you try ready images from link http://arago-project.org/files/releases/2009.11/images/da850-omapl138-evm/ ?

    Because we did not see like ECC errors for OE based x11-gpe type of JFFS2 file system, but arago based filesystemg gives ECC errors

    Are you sure to fix these ECC errors only upgrading uboot 2011.09? If it is ok, we suprised for working OE based x11-gpe image?

    Do you know older PSP release have ECC errors for JFFS2 based file system?

    If you are sure and TI knows this reliability problem of JFFS2 filesystem issue for Davinci platform, Why do not TI upgrade own PSP release or update section of known issues

    on http://processors.wiki.ti.com/index.php/DaVinci_PSP_03.21.00.04_Release_Notes or publish a patch?

    Best Regards,

    FERHAT YALDIZ

  • 0 in reply to Ferhatx
    Intellectual 625 points

    Hello,

    pls. could you be so kind to tell which are the instructions to build u-boot-2011.09? I am using SDK 5.03 u-boot sources:

    These are my instructions:

    make distclean CROSS_COMPILE=arm-arago-linux-gnueabi-

    make da850evm_config CROSS_COMPILE=arm-arago-linux-gnueabi-

    make all CROSS_COMPILE=arm-arago-linux-gnueabi-

    I get this error:

    make[1]: *** [lxt972.o] Error 1
    make[1]: se sale del directorio «/home/alberto/ti-sdk_05_03_02-am1808-source/u-boot-2011.09-psp04.06.00.03/arch/arm/cpu/arm926ejs/davinci»
    make: *** [arch/arm/cpu/arm926ejs/davinci/libdavinci.o] Error 2

    Thanks in advance

  • 0 in reply to alberto liberal
    Intellectual 420 points

    Hi Alberto,

    We did not use uboot-2011.09 version. But you can try to remove lxt972.o from makefile in given error directory.

    Because this file is not important for this platform.

    Best regards,

    FERHAT YALDIZ

  • 0 in reply to Ferhatx
    Intellectual 625 points

    Thanks Ferhat for your fast reply!!

    By the way, i have also tried to flash root file system in nand flash using u-boot 2010.12, Kernel 2.6.37 in PSP 03.21.00.04 and Toolchain gcc4.5.3. I have flashed u-boot and uImage in NAND flash i am booting kernel from flash and root file system from NFS. When i try to flash root file in Nand Flash i got this error (this is the reason to try to compile uboot-2011.09):

    root@am180x-evm:~# flash_erase -j /dev/mtd4 5 126                               
    flash_erase: error!: /dev/mtd4: unable to get NAND oobinfo                      
                 error 22 (Invalid argument)      

    Many thanks in advance

    Alberto        

  • 0 in reply to Ferhatx
    Prodigy 185 points

    Hi Ferhat,

    I'll try to answer your questions in order.

    I have not tried any prebuilt JFFS2 images on my board.  I have built JFFS2 images using a custom OpenEmbedded image recipe which I built myself, and I have built images from the root filesystem included with the TI SDK.  To do this I used the command:

    mkfs.jffs2 -n -r $PATH_TO_ROOTFS -e $ERASEBLOCK_SIZE_IN_KB -o $OUTPUT_FILENAME

    • Are you sure to fix these ECC errors only upgrading uboot 2011.09? If it is ok, we suprised for working OE based x11-gpe image?

    The version of u-Boot isn't important so long as it supports the nand write.trimffs command.  Remember that NAND is written an entire eraseblock at a time.  Because of this detail, the mkfs.jffs2 command above builds a JFFS2 image which has pages at the end that are filled with 0xFFs so that it fills the entire last eraseblock.  If u-Boot tries to write these pages it will calculate ECC data and write it to OOB.

    Why is that a problem?  Remember again that erase is a fundamentally (and physically) different operation as write.  The result of a successful erase is a page who's data and OOB areas are full of 0xFFs.  That is, the OOB area for a properly erased page has no ECC data.   As a result of this detail the JFFS2 garbage collection will see pages *written* full of 0xFFs rather than left as-is in their erased state, and it will think there is supposed to be valid data there.  Of course there isn't, and that's why we see these noisy error messages.

    • Do you know older PSP release have ECC errors for JFFS2 based file system?

    Not specifically.  I do know that the problem I detailed above will affect any version of JFFS2 (PSP or mainline) of which I am aware.

    I won't damage our relationship with TI by speaking on their behalf.  I can tell you that I have personally visited their headquarters in Dallas and discussed this and other issues on this platform with them at length.  I feel that they have done a very good job of listening to and addressing our individual concerns.  I have encouraged them to revisit their software support for the AM18XX platform.  It seems that they have incurred some "technical debt" here, and they're paying it back with high interest through their support teams.  It's my impression that they're clearly learning from this as they move forward with new products.  However just from looking at the commit logs on the arago git repository, it's clear that the kernel-davinci tree has entered a purely maintenance state.

    The best I can advise is to be a good community memeber and avoid taking a passive stance.  If you see something wrong or incomplete on the wiki, update it.  If you've fought some hard problem and there isn't documentation for it, write it.  If there are patches involved, submit them.  If they're not making it into the next PSP, fork their git repo and maintain your own.  Frankly, regardless of how amazing or poor the software support is, those of us who have bought into this chip are stuck with it for the lifetime of our products.  It's in everyone's best interest if we all do our best to help each other out.  Further, the more engaged and visible TI's customers are, the more incentive they have to continue kernel support.

    Hope this helps,

    Ben

  • 0 in reply to alberto liberal
    Prodigy 185 points

    Hi Alberto,

    This is a known problem.  Drop the -j.  You can still mount the newly erased partition as JFFS2, just make sure to let the garbage collector run to completion the first time you mount it, as it needs to go through and mark all the erased pages with cleanmarkers, and this can take a little while.  You can monitor its progress with the "top" command.

    Also - why are you using arguments "5 126" instead of "0 0?"  Is there some reason why you don't wish to erase the entire partition?  If you need to change your MTD partitions you can either edit the partition struct in your board init, or you can drop it entirely and specify MTD partition info on the kernel command line.

    Hope this helps,

    Ben

  • 0 in reply to Benjamin Burns
    Intellectual 625 points

    Thanks Ben

    these are the steps i am trying to do to flash a NAND root file of 250.5MB from Linux:

    flash_erase /dev/mtd4 0 0

    nandwrite -p /dev/mtd4 nandjffs2.bin

    Now i re-boot and these are the bootcmd and bootargs i am using:

    setenv bootcmd 'nboot.e 0xc0700000 0 0x200000; bootm'

    setenv bootargs mem=? console=ttyS2,115200n8 root=/dev/mtd4 rw rootfstype=jffs2

    Do you think that bootargs are OK, i am flashing 250.5MB root file, which value should be used in mem parameter?

    Many thanks for your help

  • 0 in reply to alberto liberal
    Prodigy 185 points

    We're getting off topic here.  I'd suggest opening a new thread if we need to discuss this further.

    In short, the "mem=" value tells the kernel how much RAM is installed.

    If you ever need to determine what a bootarg does, check out Documentation/kernel-parameters.txt in your kernel sources.  Here's a link to this file from the latest PSP on the arago gitweb: http://arago-project.org/git/projects/?p=linux-davinci.git;a=blob;f=Documentation/kernel-parameters.txt;h=01ece1b9213e97de22f1cc02faf4f0bae5165e96;hb=3af05b9be11d38655bb91dd94d04c8f8e205c32b

    At a minimum you should add "rootwait" to your bootargs, but if you're not using an initrd you should also add "noinitrd."  We also have the bootarg "ip=off" in there, as this tells the kernel to skip any kind of kernel-level network initialization for NFS boot and wait for usermode to handle it.

    Good luck,

    Ben

  • 0 in reply to alberto liberal
    Intellectual 625 points

    Thanks Ben,

    just a last question, how do you mount the newly erased partition as JFFS2?

    Best Regards

  • 0 in reply to Benjamin Burns
    Intellectual 640 points

    Hi Ben,

    I don't know if this message can still reach you. I see you mentioned using Jtag xds560 to write filesystem to NAND in this thread. Could you tell me how? Thanks.

    Frank

  • 0 in reply to Bigtree
    Prodigy 185 points

    Just connect the JTAG like you normally would for linux debug and halt at the u-boot prompt.  Then use the "load memory" feature in the  memory browser in CSS to transfer your binary to 0xC0700000, and proceed as usual.  This basically takes the place of the "loady" command if you were loading through the serial port before.  Just like with loady, you'll need to use "split" to break up your image into 8MiB chunks.

  • 0 in reply to Benjamin Burns
    Intellectual 640 points

    Thanks Ben. I will try. I have an urgent technical problem related to this thread. Could you help to answer? Here is the link of post. Thanks.

    http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/162474.aspx

    Frank

  • 0 in reply to Benjamin Burns
    Intellectual 640 points

    Hi Ben,

    I don't see the load memory selection  in emory browser in my Linux based CCSv5. I do see that in Windows based CCSv4. But I use Linux based CCS because of I use Linux for my development OS. Do you know where is the load memory in Linux CCS? Thanks.

    Frank

  • 0 in reply to Benjamin Burns
    Intellectual 640 points

    Hi Ben,

    I did find the load memory is changed to impot memory in my Linux version CCSv5. I can load uImage by that way to memory browser. But why you mention load it to 0xC0700000. I loaded the uImage to 0x80000000 as I would load through uboot tftp (tftp 0x80000000 umage). But after I loaded as a binay image to 0x80000000, then I try to boot in uboot by bootm 80000000. It failed and said wrong Image Format, cannot find Linux kernel. But if I tftp the same image to 0x80000000, it can boot up this way. Could you advise why Jtag load uImage is different from tftp by ethernet through uboot? Thanks.

    Frank

  • 0 in reply to Benjamin Burns
    Intellectual 930 points

    Benjamin Burns said:

    I managed to fix the problem by upgrading to the latest (2011.09) version of u-Boot, rather than the version included with the latest SDK release and by adding support to the build for the nand write.trimffs command.

    To add the nand write.trimffs command, add "#define CONFIG_CMD_NAND_TRIMFFS" directly after "#define CONFIG_CMD_NAND" in includes/configs/da850evm.h

    This should work on other platforms using the davinci_nand MTD driver which are experiencing these errors.

    hello,

    I have add the define in includes/configs/ti8168_evm.h of my u-boot. But when i use the command write.trimffs in the u-boot prompt, it did not work. I want to ask you if there else should do to enable the command of write.trimffs?