A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
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.
Both NAND clashes have a page size of 2048, but the spare area increased from 64 bytes to 128 bytes (per 2048 bytes), so you might need to use BCH16 ECC with MT29F2G08ABAGAH4, whereas BCH8 works for MT29F4G08ABADAH4 with its 64 bytes of OOB.
Check also the last digits of the NAND part number to ensure it does not have the Error Correction field selected (after the Operating Temperature Range field): "E" = Internal ECC enabled Check that the bootmode matches the ECC capability of the NAND based on the part number.
The NAND can get away with BCH8, but the ROM bootloader is trying to use BCH16 based on the size of the spare area. You may only need to update the primary bootloader image. Once any secondary bootloader is running (ie. uboot equivalent), the image it reads does not have to be BCH16.
I believe the GPMC ECC hardware can be used to create the BCH16 codes while writing to the NAND flash. This way the programmer can react to bad blocks that could be different from board to board. How are you currently programming the NAND?
You could study the uBoot mtd source and programming sequence
Source: see uBoot source code (omap_gpmc.c, omap_elm.c, am335x_spl_bch.c) in am335x-evm-linux-sdk-src-07.03.00.005\board-support\u-boot-2020.01+gitAUTOINC+2781231a33-g2781231a33\drivers\mtd\nand\raw\ Download from www.ti.com/.../PROCESSOR-SDK-AM335X
