AM3358: Request for BCH16 ECC generation example for AM335x with Micron MT29F8G08 NAND

Dear Hong Guan64,

We are currently developing a product using the AM3358 processor and Micron NAND Flash (MT29F8G08ABACAWP-IT:C), which has a page structure of 4096+224 bytes.
To support this NAND, we need to implement BCH16 ECC in our custom NAND image generation tool.

We found the following TI forum post that mentions a patch for BCH16 ECC in StarterWare v02.00.00.07:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/241321/patch-for-16-bit-bch-ecc-in-starterware

We also reviewed this related post about flashing NAND using Lauterbach JTAG on AM62x:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1422565/faq-how-to-flash-gpmc-nand-with-lauterbach-jtag-on-am62x

However, the second link only provides a precompiled binary.
For our tool development, we need the full source implementation of BCH16 ECC (e.g., bch_global.c, nandlib, or any equivalent module).

If this source is included in StarterWare, could you kindly provide the full StarterWare package (preferably the latest version)?
If the code is distributed elsewhere, we would greatly appreciate your guidance on how to access it.

We are developing a NAND flashing tool and require ECC encoding that matches the AM335x hardware ECC (BCH16) and Micron NAND specifications.

Thank you for your support.

Best regards,

GIHWAN AHN said:

We found the following TI forum post that mentions a patch for BCH16 ECC in StarterWare v02.00.00.07:

The e2e was on baremetal code running on AM335x target, and is not relevant to you as I think you're looking for reference source code running on host side.

I sent you an e2e forum friend request, and will share a reference host side code once you accept my friend request.
Best,
-Hong

Hello,

I have read the license agreement (EULA.rtf) and I accept the terms on behalf of myself and BIXOLON Co., Ltd.

Best regards,

Dear Hong Guan64,

We are currently validating our NAND programming process using a custom bin2nand utility based on TI’s BCH16 ECC source code.

According to the master reference image provided, the page layout appears to follow this structure:

4096 + {2 (0xFF) + (26 × 8) + 14 (0xFF)}

However, when running the ECC code you provided, we observed that the first byte of the final 14-byte area is being generated as 0x00 instead of 0xFF.

* Please refer to the image below for a comparison:

As shown, both the master image and the reference ECC output consistently use 0xFF in this padding area, whereas our result differs.

Could you kindly confirm:

• Whether this behavior (0x00 in that area) is intentional, and

• Whether it is acceptable to manually fill this 14-byte padding region with 0xFF instead, to ensure compatibility with the master image and avoid verification mismatches during production?

We greatly appreciate your guidance to help ensure consistency and correctness.

Thank you for your support.

Best regards,

Dear Hong Guan64

Thank you for your continued assistance.

While developing a NAND programming utility based on TI's BCH16 ECC source code, we observed that the first byte of the final padding region in the OOB area is being generated as 0x00.

According to your documentation, we understand that this padding region is not involved in actual ECC validation. However, the master image generated by TI UniFlash consistently fills this area with 0xFF, and this discrepancy may lead to verification mismatches during production.

We would greatly appreciate your clarification on the following points:

1. Is the output of 0x00 in this padding byte by TI's BCH16 ECC code the intended behavior?

2. If the expected behavior is to output 0xFF, would it be possible to obtain a modified version of the ECC generation code that fills this area accordingly?

3. If code modification is not feasible, is it functionally acceptable to use the 0x00 value as generated, without causing any reliability or compatibility issues?

We are requesting this confirmation to ensure compatibility and consistency during our production and validation process.

Thank you very much for your support.

Best regards,

BIXOLON Co., Ltd.

Hello GIHWAN,

Hong Guan64 said:

In fact, all padding bytes are not used for BCH checking in code (rom/u-boot/kernel...)
But it is ok to fill "0xFF" to the first padding byte to match the reference binary as needed.

Please feel free to try the attached patch.
Best,
-Hong

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/nand_5F00_image_5F00_2.patch

Dear Hong Guan64,

Apologies for the repeated inquiry, and thank you again for your continued support.

We would like to confirm the following regarding ECC padding behavior:

1. Is it possible to obtain a version of the .exe utility that fills the ECC padding area with 0xFF, as done by UniFlash?

2. If not available, can you confirm that using the currently provided .exe, which fills the padding with 0x00, is acceptable and will not cause any issues?

We truly appreciate your kind support and assistance throughout this process.
Thank you very much.

Best regards,
Gihwan Ahn
BIXOLON Co., Ltd.

Hi Hong Guan64,

Thank you very much for your reply. We've tested the changes and can confirm that the issue is resolved. Your help was very valuable to us.

Best regards,