AM4378: Clarification on ECC Scheme for NAND Boot with AM4378

I'm on PTO this week but I will be picking up E2E support again next week. Thanks.

Hi Andreas,

We have reviewed the Micron NAND datasheet and confirmed that the NAND device in use has the following characteristics:

• Page size: 4096 bytes

• Spare (OOB) area: 224 bytes

According to the AM437x TRM and Figure 5-15 “NAND ECC Scheme Selection Procedure,” the ROM code automatically selects between BCH8 and BCH16 based on the spare area size.

Given that:

1. Number of sectors per page = 4096 ÷ 512 = 8 sectors

2. Required ECC bytes = 8 × 26 = 208 bytes

3. Available spare area = 224 bytes

4. Since 224 ≥ 208, BCH16 is expected to be selected by the ROM code
   
   

We also examined the relevant U-Boot patch and found that the SPL NAND driver (am335x_spl_bch.c) supports only BCH8 ECC with 1-sector granularity. It does not support BCH16 or multi-sector ECC operations.
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2023.04-next&id=c0176ab8dd53f86e193c578ec4781400e9fb18e3

Therefore, in this configuration, when the ROM code selects BCH16 but the SPL (which is loaded via ROM) uses a BCH8-only driver, the SPL cannot correctly read and decode its subsequent stage (i.e., U-Boot proper). This may result in boot failure due to ECC errors during the SPL stage.

To address this, the U-Boot patch appears to force the ECC mode to BCH8 with 1-sector operation when building the SPL. This ensures that the SPL will always read the U-Boot image using a BCH8-compatible format, allowing the boot process to succeed even if the ROM initially selected BCH16. After applying the patch, the device worked properly.

We hope this understanding is correct and would appreciate your confirmation or any additional insights on this behavior.

Thanks,

Conor

Hi Andreas,

Regarding the operation of the AM437x NAND boot, please confirm whether the following understanding is correct.

1. The SPL NAND driver (am335x_spl_bch.c) only supports BCH8 with 1-sector ECC. It does not support BCH16 or multi-sector ECC modes.

2. The definition CONFIG_NAND_OMAP_ECCSCHEME = OMAP_ECC_BCH16_CODE_HW applies to the main U-Boot and Linux kernel, but not to the SPL.

3. ECC is not added to the prebuilt binaries (e.g., MLO, u-boot.img) during build time. Instead, ECC is generated and applied by U-Boot or the SoC’s ECC engine at the time of NAND flashing.

4. Therefore, the MLO (SPL image) must be written using BCH8 ECC to be correctly read by the ROM and SPL, whereas U-Boot and the Kernel can be written using BCH16 ECC.

Could you please confirm if the above understanding is correct?

[Background]

• On a device where a u-boot.img without the patch was written, the SPL and U-Boot loaded successfully, but the Kernel failed to boot due to an ECC error (as seen in the previously attached boot log).

• Rewriting only the u-boot.img on the same device with the patched version resulted in successful booting of SPL, U-Boot, and the Kernel.

• The u-boot.config file includes the definition #define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH16_CODE_HW, so we assumed that BCH16 is in use.

Thanks,

Conor

Hi Conor,

while I'm out of the office this week let me loop in a colleague that may have some past experience with the AM43x ECC topic here to see if we can move ahead in some way.

Regards, Andreas

Hi Andreas,

Since we are in pre-production, we need to resolve this issue as soon as possible, so I would be very grateful if you could assign another colleague to handle it until you return.

Thanks,

Conor

Hi Conor,
Let's merge the following e2e into this one as the two e2e looks like on the same issue.
https://e2e.ti.com/support/processors-group/processors/f/791/t/1515021
Based on the log from the other e2e, the Linux SDK 8.2 is used in your testing. is my understanding correct?
I supported another customer on gpmc-nand issue on AM335x last year, and it turns out that there was gpmc-nand issue on Linux SDK 8.2 and SDK 9.1. This is the FAQ on how to fix the gpmc-nand issue in SDK 9.1 on AM335x for your reference.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1407372/faq-how-to-flash-and-boot-linux-from-nand-with-am335x-linux-sdk-9-1
Best,
-Hong

Hi Hong,

You are correct in your understanding that you are using Linux SDK 8.2.

We understand that SPL does not support multi-sector ECC. However, we would like to clarify whether it is true that the SPL forcibly switches the ECC scheme to BCH8, regardless of the ECC configuration in U-Boot.

【Background of the issue】

• On a board with an unpatched u-boot.img, SPL successfully starts and loads U-Boot, but the Kernel fails to boot due to ECC errors.

• When we replaced only the u-boot.img with a patched version, SPL → U-Boot → Kernel booted successfully.

• The following configuration is defined in include/configs/am335x_xxx.h, and we believed BCH16 was being used:

  #define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH16_CODE_HW
  

Based on this behavior, we assumed that BCH16 ECC correction was working properly, but we would like to confirm whether this understanding is correct.

Additionally, we would like to confirm the following:

• We understand that the built binary images (SPL, U-Boot, Kernel) do not contain ECC data by default. Instead, ECC is calculated and applied during NAND write operations by the U-Boot driver and the CPU's hardware ECC engine.

• We are writing each image to its respective offset using U-Boot (e.g., SPL to 0x0, U-Boot to 0x20000, Kernel to 0x200000), and we expect ECC is added at write-time based on the active ECC setting (OMAP_ECC_BCH16_CODE_HW).

Given the above, can we assume that:

1. If BCH16 is enabled in U-Boot at the time of writing, BCH16 ECC is properly written to NAND?

2. Or, does the SPL enforce a switch to BCH8 during its own operation regardless of the NAND contents?

Best regards,
Conor

Hi Conor,
1/. ROM loads the first stage BL (i.e. SPL) using the BCH scheme based on nand device OOB size etc... which mandates SPL binary has to be flashed to nand with raw+BCH with the matching BCH scheme determined by ROM.
2/. Considering SPL/u-boot/kernel... are all flashed to nand via u-boot on your setup, it would be practically necessary to choose the same BCH scheme as used by ROM to flash all binaries (SPL/u-boot/kernel...) to nand.
3/. In order to boot from nand with SDK 8.2, I'd recommend refer to the FAQ in my last reply, and apply the u-boot patches (at least the first two patches).
Best,
-Hong

Hi Hong,

Thank you for your reply.

We are currently investigating a NAND boot issue on the AM437x platform. We have already reviewed known GPMC-NAND-related issues through available FAQs and forums, and we are now assessing whether any similar latent issues may exist in other functional areas.

Specifically, we are concerned about potential scenarios where the system appears to function normally but may suddenly fail to boot or operate due to subtle or timing-related issues.

At this point, we have already reviewed the following official resources:

Processor SDK Linux 08.02.00.24 Release Notes（AM437x）

AM437x Device Silicon Errata

If there are any additional known issues—other than those documented in the above sources—related to the TI-provided software environment (SPL, U-Boot, Processor SDK, ti-u-boot, etc.), we would greatly appreciate it if you could share them with us.

Thanks,

Conor

Hi Hong,

I have an additional question.
Am I correct in understanding that the inquiry in this thread is related to LCPD-25271 in the Release Notes?

Thanks,

Conor

Hi Conor,
Yes, there's an issue on gpmc-nand boot in Linux SDK8.2 & SDK9.1.
Let's apply the patches as noted in the FAQ, and re-test on your setup.
Best,
-Hong