AM3354: NAND programming for production

Bob Duke

Part Number: AM3354

I am trying to get a NAND part programmed before installation on a AM3354-based baseboard.

The vendor has had trouble duplicating the AM335x ECC algorithm on their NAND programmer. They were using the bin2nand source code (provided by TI) as a reference.

After all that, however, I realized that I may be able to use the bin2nand application to create an image file they can just write to the NAND directly.

I have four image files to put on the NAND: MLO, u-boot.img, uImage (Kernel), and ubi.img (Filesystem). I am able to flash these files to the NAND from Linux using the standard nandwrite/flash_erase utils.

Given this, what is the best approach to using the bin2nand tool to create a NAND image that has ECC data that is compatible with the AM3354 hardware (BCH8)? Do I need to dump the entire NAND to a single file and process that? Do I need to use a TI version of nand2bin to accomplish this? Should I create an image for each partition separately using bin2nand on each of the four image files?

Thank you for any guidance or suggestions before I have to fully reverse engineer the source code.

The NAND is partitioned (via the kernel) as (SZ_256K = 0x40000) :

        {
                .name = "MLO",
                .offset = 0,                  /* mtd1 Offset = 0x0 */
                .size = SZ_256K,
        },
        {
                .name = "MLO.backup1",
                .offset = MTDPART_OFS_APPEND, /* mtd2 Offset = 0x40000 */
                .size = SZ_256K,
        },
        {
                .name = "MLO.backup2",
                .offset = MTDPART_OFS_APPEND, /* mtd3 Offset = 0x80000 */
                .size = SZ_256K,
        },
        {
                .name = "MLO.backup3",
                .offset = MTDPART_OFS_APPEND, /* mtd4 Offset = 0xc0000 */
                .size = SZ_256K,
        },
        {
                .name = "U-Boot",
                .offset = MTDPART_OFS_APPEND, /* mtd5 Offset = 0x100000 */
                .size = 8 * SZ_256K,
        },
        {
                .name = "U-Boot Env",
                .offset = MTDPART_OFS_APPEND, /* mtd6 Offset = 0x300000 */
                .size = 1 * SZ_256K,
        },
        {
                .name = "Kernel",
                .offset = MTDPART_OFS_APPEND, /* mtd7 Offset = 0x340000 */
                .size = 20 * SZ_256K,
        },
        {
                .name = "File System",
                .offset = MTDPART_OFS_APPEND, /* mtd8 Offset = 0x840000 */
                .size = MTDPART_SIZ_FULL,
        },

NAND Part: MT29F4G08ABAEAWP:E

Datasheet: www.micron.com/.../mt29f4g08abaeawp

over 7 years ago

0 RonB over 7 years ago

TI__Mastermind 30746 points

Bob,

I'll try to get you some more feedback in the next day or so. I believe using the 4 files should work fine, but it might be easier in the long run to build up a single image.

0 JJD over 7 years ago in reply to RonB

TI__Guru* 90565 points

Bob, I would use bin2nand on each of the 4 images. This probably would be the most efficient to use when programming the NAND, and then you can flash each image to any portion of the NAND, without unnecessarily program in padding to align the different images.

Regards,
James

0 Bob Duke over 7 years ago in reply to JJD

Intellectual 301 points

Thanks James. I can't seem to figure out the correct way to do this with the bin2nand tool. The "-block" option help says

-block 16|32|64|128 - Block size (number of pages), default: 64

For this part (datasheet linked in top post), the block size is 256kB and each page is 4kB, so it would appear the block option should be set to 64. So, when I run bin2nand with these options I get this output:

$ du -sb uImage
3870056    uImage

$ bin2nand -page 4096 -spare 224 -verbose -bch 8 -block 64 uImage uImage.ecc
**********************************************************************************
       (C) 2013 TEXAS INSTRUMENTS. All rights reserved                          
                  Image Formating Tool for NAND Memories                        
                                                                                
**********************************************************************************

  NAND type.................. RAW
  NAND page size............. 4096
  NAND spare area (bytes).... 224
  NAND block size (pages).... 64
  Correctable sectors........
  Uncorrectable sectors......
  Source file................ uImage
  Output file................ uImage.ecc
  Input image size........... 262144
  Output image size.......... 262144
  Generating image...
  Page: 064/064 Sector: 8/8
  Done.

$ du -sb uImage.ecc
276480    uImage.ecc

So, looking at the source code I see that the tool only reads in the first (Blocksize*Pagesize = 4096*64 = 262144) of the input file (and reports the output file length as the same).

Now, if I try something like (where 3870056/4096 ~= 945):

$ bin2nand -page 4096 -spare 224 -verbose -bch 8 -block 945  uImage uImage.ecc
**********************************************************************************
       (C) 2013 TEXAS INSTRUMENTS. All rights reserved                          
                  Image Formating Tool for NAND Memories                        
                                                                                
**********************************************************************************

  NAND type.................. RAW
  NAND page size............. 4096
  NAND spare area (bytes).... 224
  NAND block size (pages).... 945
  Correctable sectors........
  Uncorrectable sectors......
  Source file................ uImage
  Output file................ uImage.ecc
  Input image size........... 3870056
  Output image size.......... 3870720
  Generating image...
  Page: 945/945 Sector: 8/8
  Done.

$ du -sb uImage.ecc 
4082400	uImage.ecc

So here it looks more correct: the input image size is reported correctly. The resulting output file, uImage.ecc, has a size equal to 945 * (4096+224) = 4082400 which at least makes some sense.

Does my second example look like correct usage to you?

0 JJD over 7 years ago in reply to Bob Duke

TI__Guru* 90565 points

Hi Bob, your second one is correct. Seems like the block definition in the help is a little misleading.

The -block parameter is the number of blocks to contain the image. So the parameter should conform to the following equation:

Block size > (Input Image size in bytes)/(page size)

As an example, if you input image is 3Mbytes, then:

3000000/4096 = 732.42

Then set the block size to 733

Regards,

James

Processors

Processors forum

AM3354: NAND programming for production