DRA77P: SDRAM check failure

Giuseppe Noto

Prodigy 80 points

Part Number: DRA77P

Hello,

we have found in some custom boards based on DRA770, an unsystematic error.

Sometimes (about one time on about 10 tests) the board hangs after a warm or cold reboot.

When problem occurs u-boot firmware, after SDRAM initialization, prints on console the error code:

SDRAM: identified size not same as expected size identified: 80 expected: 80000000

Have you any idea about this problem? When can the above error be triggered?

Thanks for help,

Giuseppe

over 4 years ago

0 Vineet Roy over 4 years ago

TI__Mastermind 37435 points

SDK version ?

Regards

Vineet

0 Giuseppe Noto over 4 years ago in reply to Vineet Roy

Prodigy 80 points

Processor SDK Linux Automotive Release version 3.04.00.03.

For your reference, I provide you also u-boot version:

VERSION = 2016
PATCHLEVEL = 05

Regards,

Giuseppe

0 Keerthy J over 4 years ago in reply to Giuseppe Noto

TI__Guru**** 162770 points

Hi Giuseppe,

Could you also share the logs with us? If most boards work with the same u-boot/MLO binaries
and some are not then i suspect something wrong with the hardware on the failing boards.

Best Regards,
Keethy

0 Giuseppe Noto over 4 years ago in reply to Keerthy J

Prodigy 80 points

Hi Keerthy,

below the debug log that we obtain when issue occurs:

1150 -> optimize_vcore_voltage:efuse 0x4a003b20 bits=16 Vnom=1150, using efuse value 1010
1010
1150 -> optimize_vcore_voltage:efuse 0x4a0025f4 bits=16 Vnom=1150, using efuse value 1015
1015
0 -> 0
1250 -> optimize_vcore_voltage:efuse 0x4a003b14 bits=16 Vnom=1250, using efuse value 1095
1095
1060 -> optimize_vcore_voltage:efuse 0x4a0025e0 bits=16 Vnom=1060, using efuse value 950
950
1060 -> optimize_vcore_voltage:efuse 0x4a0025cc bits=16 Vnom=1060, using efuse value 945
945
cor: 1015
do_scale_vcore: volt - 1015 offset_code - 0x3a
IODELAY: IO delay recalibration successfully completed

core Dpll locked, but not for ideal M = 266,N = 4 values, current values are M = 532,N= 9
per Dpll locked, but not for ideal M = 96,N = 4 values, current values are M = 1920,N= ��j
mpu Dpll locked, but not fod

BR,

Giuseppe

0 Keerthy J over 4 years ago in reply to Giuseppe Noto

TI__Guru**** 162770 points

Hi Giuseppe,

So this happens once in ten times. Can you also help share the successful boot log?
Also double checking this happens on some boards and not consistently.

I will check with experts if you can share the success log as well.

Best Regards,
Keerthy

0 Giuseppe Noto over 4 years ago in reply to Keerthy J

Prodigy 80 points

Hi Keerthy,

below debug log when wake up is ok:

gmac Dpll already locked with idealnominal opp values>>sdram_init()
in_sdram = 0
sdram_init 1547
>>do_sdram_init() 4c000000
dra7_ddr3_init 409
dra7_ddr3_init 413
HW leveling success
do_sdram_init 1294
<<do_sdram_init() 4c000000
>>do_sdram_init() 4d000000
dra7_ddr3_init 409
dra7_ddr3_init 413
HW leveling success
do_sdram_init 1294
<<do_sdram_init() 4d000000
get_ram_size() successful<<sdram_init()
Enable clock module - 4a008778
Enable clock module - 4a008780
>>spl:board_init_r()
TLB table from 00000000x to 00000000x
dram_bank_mmu_setup: bank: 0
dram_bank_mmu_setup: bank: 1
Enable clock module - 4a008778
Enable clock module - 4a008780
using memory lx-lx for malloc()
spl_init()
both manifests valid, tags: 18 19
mpu: 1010
do_scale_vcore: volt - 1010 offset_code - 0x4f
mm: 0
gpu: 1095
do_scale_vcore: volt - 1095 offset_code - 0x60
eve: 950
do_scale_vcore: volt - 950 offset_code - 0x33
iva: 945
do_scale_vcore: volt - 945 offset_code - 0x33
NOR u-boot @ 0x08000000 (m=1)
spl: payload image: *s load addr: 0x4 size: 402915360
Starting full u-boot...
image entry point: 0x

BR,

Giuseppe

0 Keerthy J over 4 years ago in reply to Giuseppe Noto

TI__Guru**** 162770 points

Hi Giuseppe,

What is the DDR part used in your custom board? Is that same as TI DRA76 EVM?
What are the changes that you have done on u-boot to enable your DDR part?

That will give us some clues. This might be configuration related issue.

Please share the above details so that we can check with our DDR expert.

Best Regards,
Keerthy

0 Giuseppe Noto over 4 years ago in reply to Keerthy J

Prodigy 80 points

Hello Keerthy,

sorry for delay in the answer.

About your question in our custom board we have 2 banks of DDR3 with code MT41K256M16TW-107AAT.

Below the detailed configuration for DDR that we have in our code.

Thanks for help.

BR,

Giuseppe

/**************************************************************************************/

//The following structure comes from the TI Excel utility

const struct emif_regs emif_regs_ddr3_666_mhz_1cs_dra76_1 = {

.sdram_config_init = 0x61862B32,

.sdram_config = 0x61862B32,

.sdram_config2 = 0x00000000,

.ref_ctrl = 0x1000514D,

.ref_ctrl_final = 0x10000512,

.sdram_tim1 = 0xD33367EC,

.sdram_tim2 = 0x40B37FE4,

.sdram_tim3 = 0x409F8AD8,

.read_idle_ctrl = 0x00050000,

.zq_config = 0x5007190B,

.temp_alert_config = 0x00000000,

.emif_rd_wr_lvl_rmp_ctl = 0x80000000,

.emif_rd_wr_lvl_ctl = 0x00000000,

.emif_ddr_phy_ctlr_1_init = 0x0024400E,

.emif_ddr_phy_ctlr_1 = 0x0E24400E,

.emif_rd_wr_exec_thresh = 0x00000305,

.emif_rd_wr_lvl_rmp_win = 0x00000000,

.emif_ddr_ext_phy_ctrl_1 = 0x04040100, // EMIF1_EXT_PHY_CTRL_1

.emif_ddr_ext_phy_ctrl_2 = 0x006B00B0, // EMIF1_EXT_PHY_CTRL_2

.emif_ddr_ext_phy_ctrl_3 = 0x006B00B0, // EMIF1_EXT_PHY_CTRL_3

.emif_ddr_ext_phy_ctrl_4 = 0x006B00B5, // EMIF1_EXT_PHY_CTRL_4

.emif_ddr_ext_phy_ctrl_5 = 0x006B00B6, // EMIF1_EXT_PHY_CTRL_5

/* Disable ECC */

.emif_ecc_ctrl_reg = 0x00000000,

.emif_ecc_address_range_1 = 0x00000000,

.emif_ecc_address_range_2 = 0x00000000

};

//The following structure comes from the TI Excel utility

const struct emif_regs emif_regs_ddr3_666_mhz_1cs_dra76_2 = {

.sdram_config_init = 0x61862B32,

.sdram_config = 0x61862B32,

.sdram_config2 = 0x00000000,

.ref_ctrl = 0x1000514D,

.ref_ctrl_final = 0x10000512,

.sdram_tim1 = 0xD33367EC,

.sdram_tim2 = 0x40B37FE4,

.sdram_tim3 = 0x409F8AD8,

.read_idle_ctrl = 0x00050000,

.zq_config = 0x5007190B,

.temp_alert_config = 0x00000000,

.emif_rd_wr_lvl_rmp_ctl = 0x80000000,

.emif_rd_wr_lvl_ctl = 0x00000000,

.emif_ddr_phy_ctlr_1_init = 0x0024400E,

.emif_ddr_phy_ctlr_1 = 0x0E24400E,

.emif_rd_wr_exec_thresh = 0x00000305,

.emif_rd_wr_lvl_rmp_win = 0x00000000,

.emif_ddr_ext_phy_ctrl_1 = 0x04040100, // EMIF1_EXT_PHY_CTRL_1

.emif_ddr_ext_phy_ctrl_2 = 0x006B00A7, // EMIF1_EXT_PHY_CTRL_2

.emif_ddr_ext_phy_ctrl_3 = 0x006B00A6, // EMIF1_EXT_PHY_CTRL_3

.emif_ddr_ext_phy_ctrl_4 = 0x006B009B, // EMIF1_EXT_PHY_CTRL_4

.emif_ddr_ext_phy_ctrl_5 = 0x006B0099, // EMIF1_EXT_PHY_CTRL_5

/* Disable ECC */

.emif_ecc_ctrl_reg = 0x00000000,

.emif_ecc_address_range_1 = 0x00000000,

.emif_ecc_address_range_2 = 0x00000000

};

void emif_get_reg_dump(u32 emif_nr, const struct emif_regs **regs)

{

switch (emif_nr) {

case 1:

*regs = &emif_regs_ddr3_666_mhz_1cs_dra76_1;

break;

case 2:

*regs = &emif_regs_ddr3_666_mhz_1cs_dra76_2;

break;

}

//These values have been taken from the Demo board configuration

/* Ext phy ctrl regs */

static const u32 ext_phy_ctrl_const_base_emif1[] = {

0x10040100,

0x00A400A4,

0x00A900A9,

0x00B000B0,

0x00A400A4,

0x00390039,

0x00320032,

0x00440044,

0x00550055,

0x007F007F,

0x004D004D,

0x00430043,

0x00560056,

0x00540054,

0x00600060,

0x0,

0x00600020,

0x40010080,

0x08102040,

0x0,

0x0

};

//These values have been taken from the Demo board configuration

/* Ext phy ctrl regs */

static const u32 ext_phy_ctrl_const_base_emif2[] = {

0x04040100,

0x006B009F,

0x006B00A2,

0x006B00A8,

0x006B00B2,

0x002F002F,

0x00600073,

0x00600071,

0x0060007C,

0x0060007E,

0x00600084,

0x00400053,

0x00400051,

0x0040005C,

0x0040005E,

0x00400064,

0x00800080,

0x40010080,

0x08102040,

0x005B008F,

0x005B0092,

0x005B0098,

0x005B00A2,

0x00300043,

0x00300041,

0x0030004C,

0x0030004E,

0x00300054,

0x00000077

};

void emif_get_ext_phy_ctrl_const_regs(u32 emif_nr, const u32 **regs, u32 *size)

{

switch (emif_nr) {

case 1:

*regs = ext_phy_ctrl_const_base_emif1;

*size = ARRAY_SIZE(ext_phy_ctrl_const_base_emif1);

break;

case 2:

*regs = ext_phy_ctrl_const_base_emif2;

*size = ARRAY_SIZE(ext_phy_ctrl_const_base_emif2);

break;

}

static const struct dmm_lisa_map_regs lisa_regs = {

.dmm_lisa_map_0 = 0,

.dmm_lisa_map_1 = 0,

.dmm_lisa_map_2 = 0,

.dmm_lisa_map_3 = 0x80740300, /* 2G interleaved */

.is_ma_present = 0x1

};

void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs)

{

*dmm_lisa_regs = &lisa_regs;

}

/****************************************************************************************/

0 Kevin S over 4 years ago in reply to Giuseppe Noto

TI__Mastermind 38300 points

Hi,

As a quick check, can you try setting the hi-lighted values to 0?

static const u32 ext_phy_ctrl_const_base_emif2[] = {

0x04040100,

0x006B009F,

0x006B00A2,

0x006B00A8,

0x006B00B2,

0x002F002F,

0x00600073,

0x00600071,

0x0060007C,

0x0060007E,

0x00600084,

0x00400053,

0x00400051,

0x0040005C,

0x0040005E,

0x00400064,

0x00800080,

0x40010080,

0x08102040,

0x005B008F,

0x005B0092,

0x005B0098,

0x005B00A2,

0x00300043,

0x00300041,

0x0030004C,

0x0030004E,

0x00300054,

0x00000077

};

Thanks,
Kevin

0 Giuseppe Noto over 4 years ago in reply to Kevin S

Prodigy 80 points

Hi,

we are testing your possible solution with success.

If we have correctly understood with this modification we go to disable SW leveling (because HW leveling is in use) observing this reference manual note:

NOTE: The EMIF_EXT_PHY_CONTROL_2 through EMIF_EXT_PHY_CONTROL_21 registers
have to be configured only in case of software leveling.

Have we correctly understood?

Thanks for your support.

BR,

Giuseppe

0 Kevin S over 4 years ago in reply to Giuseppe Noto

TI__Mastermind 38300 points

Hi,

I am not sure I fully understand your question.

You should use hardware leveling. The registers EMIF_EXT_PHY_CONTROL_2 through EMIF_EXT_PHY_CONTROL_21 should get programmed with the values obtained by hardware leveling (u-boot code should be doing this already). You do not need to program these registers before DRAM initialization or hardware leveling.

Best regards,
Kevin

Processors

Processors forum

DRA77P: SDRAM check failure