AM5749: ECC not working anymore

Primoz Fiser

Intellectual 402 points

Part Number: AM5749

Tool/software:

Hi,

we have a custom board based on AM5749 SoC and custom U-Boot based on AM57XX-EVM board.

When using SDK 6.x and U-Boot v2019, memory ECC works without any problems.

Recently, we migrated to SDK 8.X and ported all the U-Boot changes to v2021.

Our board is stuck in dra7_enable_ecc() function in arch/arm/mach-omap2/emif-common.c.

If we disable ECC in EMIF config, board boots again but ECC is obviously not working.

Here is our EMIF config:

/*
 * MT41K512M16VRN-107 (with ECC enabled) memory timings
 * This is a twin die of MT41K512M8 (also used for the ECC), so see that
 * datasheet for most timings.
 */
const struct emif_regs am57xx_emif_532mhz_512m16_ecc_regs = {
	.sdram_config_init		= 0x61851bb2,
	.sdram_config			= 0x61851bb2,
	.sdram_config2			= 0x08000000,
	.ref_ctrl			= 0x000040f1,
	.ref_ctrl_final			= 0x00001035,
	.sdram_tim1			= 0xeeef265b,
	.sdram_tim2			= 0x308f7fda,
	.sdram_tim3			= 0x409f88a8,
	.read_idle_ctrl			= 0x00090000,
	.zq_config			= 0x5007190b,
	.temp_alert_config		= 0x00000000,
	.emif_ddr_phy_ctlr_1_init	= 0x0024400b,
	.emif_ddr_phy_ctlr_1		= 0x0e24400b,
	.emif_ddr_ext_phy_ctrl_1	= 0x10040100,
	.emif_ddr_ext_phy_ctrl_2	= 0x00910091,
	.emif_ddr_ext_phy_ctrl_3	= 0x00950095,
	.emif_ddr_ext_phy_ctrl_4	= 0x009b009b,
	.emif_ddr_ext_phy_ctrl_5	= 0x009e009e,
	.emif_rd_wr_lvl_rmp_win		= 0x00000000,
	.emif_rd_wr_lvl_rmp_ctl		= 0x80000000,
	.emif_rd_wr_lvl_ctl		= 0x00000000,
	.emif_rd_wr_exec_thresh		= 0x00000305,
	.emif_ecc_ctrl_reg		= 0xD0000001,
    // This needs to be not quite 2G due to LISA3 carve out
   .emif_ecc_address_range_1       = 0x7EFF0000,
   .emif_ecc_address_range_2       = 0x00000000,
};

And DMM config:

const struct dmm_lisa_map_regs am574x_2gx1_ecc_lisa_regs = {
	.dmm_lisa_map_3 = 0xFF020100,
	.dmm_lisa_map_2 = 0x80700100,
	.is_ma_present  = 0x1
};

We are disabling ECC with:

-       .emif_rd_wr_exec_thresh         = 0x00000305,
-       .emif_ecc_ctrl_reg              = 0xd0000001,
-       // This needs to be not quite 2G due to LISA3 carve out
-       .emif_ecc_address_range_1       = 0x7EFF0000,
-       .emif_ecc_address_range_2       = 0x00000000,
+       .emif_rd_wr_exec_thresh         = 0x00000305
 };

Any idea what might be wrong in SDK 8.x regarding ECC?

We didn't change DRAM configuration at all.

1 month ago

0 Primoz Fiser 1 month ago

Intellectual 402 points

Found a culprit in arch/arm/mach-omap2/emif-common.c:

static void dra7_reset_ddr_data(u32 base, u32 size)
{
#if defined(CONFIG_TI_EDMA3) && !defined(CONFIG_DMA)
	enable_edma3_clocks();

	edma3_fill(EDMA3_BASE, 1, (void *)base, 0, size);

	disable_edma3_clocks();
#else
	memset((void *)base, 0, size);
#endif
}

dra7_reset_ddr_data() doesn't work when CONFIG_TI_EDMA3 is missing.

On the TI am57xx-evm and others, the CONFIG_TI_EDMA3 is enabled implicitly with CONFIG_TI_QSPI=y.

However, on our board, CONFIG_TI_QSPI is missing; hence, the missing CONFIG_TI_EDMA3.

Last but not least, if dra7_reset_ddr_data() doesn't work with CPU zeroing memory using memset() and needs EDMA3 method anyway, this should be fixed in emif-common.c!

There should not be an option to conditionally use EDMA3 but rather a mandate?

Thanks for your input.

BR,
Primoz

0 Josue Zamitiz-Ayala 1 month ago in reply to Primoz Fiser

TI__Mastermind 32295 points

Hello Primoz,

If I understand correctly, your issue is fixed when you enable CONFIG_TI_QSPI=y? or the single module for EDMA3?

Is this how your SDK 6.3 image was made as well?

Primoz Fiser said:
There should not be an option to conditionally use EDMA3 but rather a mandate?

I believe this is dependent of an individual project and its requirements, for our image it is solely for demonstrative purposes and each customer should customize their kernel to their project needs.

See https://software-dl.ti.com/processor-sdk-linux/esd/AM57X/09_03_06_05/exports/docs/linux/Overview_Technical_Support.html#processor-sdk-technical-support

-Josue

0 Primoz Fiser 1 month ago in reply to Josue Zamitiz-Ayala

Intellectual 402 points

Hi Josue Zamitiz-Ayala ,

I am just wondering, would it not make sense to make a hard dependency on CONFIG_TI_EDMA3=y when DRA7XX is selected if dra7_reset_ddr_data() doesn't work without it?

diff --git a/arch/arm/mach-omap2/omap5/Kconfig b/arch/arm/mach-omap2/omap5/Kconfig
index 5394529658bc..14dd8000fadc 100644
--- a/arch/arm/mach-omap2/omap5/Kconfig
+++ b/arch/arm/mach-omap2/omap5/Kconfig
@@ -7,6 +7,7 @@ config DRA7XX
        bool
        select IODELAY_RECALIBRATION
        select SYS_OMAP_ABE_SYSCK
+       select TI_EDMA3
        help
          DRA7xx is an OMAP based SOC with Dual Core A-15s.

+1 Josue Zamitiz-Ayala 1 month ago in reply to Primoz Fiser

TI__Mastermind 32295 points

Primoz,

No need for this when this is a pre-requisite for another part of the design, most DRA7x devices were meant for the automotive market which had QSPI as a hard requirement, AM57xx SW inherited this.

I am glad you got it working! I am gonna assume you found your solution and close this thread.

Best,

Josue

Processors

Processors forum

AM5749: ECC not working anymore