AM3352: u-boot upgrade caused change in cold-boot behavior

Thomas Nichols

Part Number: AM3352
Other Parts Discussed in Thread: TPS65910

I am using the Olimex AM3352-SOM and u-boot 2016.09 with this patch. Since that release is rather old I've tried to upgrade to the TI SDK v8.4 branch (based on u-boot release v2021.01.) Thie branch all seems to work fine except: on cold boot (i.e. power on,) the module does not boot (zero console output!) until I press the reset button. After that I can software reboot or HW reset and it works 100%. I've tried this on several mainboards and I'm certain there is some SW change that is causing boot to fail on first power on.

What might have been defined in the original 2016.09 branch that could affect this behavior? Presumably something in the SPL?

Thank you in advance.

over 2 years ago

0 Hong Guan64 over 2 years ago

TI__Guru 68100 points

Hello,
Reading your issue description seems like correlated with board reset HW or logic somehow?
Given there's no serial output, do we have JTAG access on board to find out to which point in code SPL runs up to?
Best,
-Hong

0 Thomas Nichols over 2 years ago in reply to Hong Guan64

Prodigy 80 points

Hello Hong - thank you for the reply. Unfortunately I don't have access to JTAG at the moment so I am flying a bit blind.

Another engineer suggested the issue may lie in that the Olimex AM3352-SOM does not use the TPS65910 PMIC and instead uses fixed regulators for VDD_CORE and VDD_MPU. In the v2021.01 codebase I am building as TARGET_AM335X_EVM_MINI which assumes the presence of the PMIC. I tried adding the following with no luck:

void am33xx_spl_board_init(void)
{
	/* Get the frequency */
	dpll_mpu_opp100.m = am335x_get_efuse_mpu_max_freq(cdev);

	/* Set CORE Frequencies to OPP100 */
	do_setup_dpll(&dpll_core_regs, &dpll_core_opp100);

	/* Set MPU Frequency to what we detected now that voltages are set */
	do_setup_dpll(&dpll_mpu_regs, &dpll_mpu_opp100);
}

0 Hong Guan64 over 2 years ago in reply to Thomas Nichols

TI__Guru 68100 points

Hello,
I'm attaching a short note on SPL boot flow for your reference.
For SPL boot on AM335x EVM with PMIC, initial SPL boot flow is listed below, where PMIC is configured in scale_vcores_generic(freq).

board_early_init_f()
{
prcm_init();				/* PMIC, DPLL */
set_mux_conf_regs();		/* PIN_MUX */
}

void prcm_init(void)
{
	scale_vcores();
	setup_dplls();
}

void scale_vcores(void)
{
	int freq;

	gpi2c_init();
	freq = am335x_get_efuse_mpu_max_freq(cdev);

	if (board_is_beaglebonex())
		scale_vcores_bone(freq);
	else
		scale_vcores_generic(freq);
}

Best,
-Hong

8037.spl_boot_flow_v1.pdf

+1 Thomas Nichols over 2 years ago in reply to Hong Guan64

Prodigy 80 points

Thanks very much! Doing some more research and comparison to the original board.c I believe the issue may actually have been in the sdram_init(). This snippet is from the Olimex board.c and when I copy it into board_mini.c (replacing the existing fn) it appears to work. I have to confirm on Monday.

static const struct ddr_data ddr3_data = {
	.datardsratio0 = MT41K256M16HA125E_RD_DQS,
	.datawdsratio0 = MT41K256M16HA125E_WR_DQS,
	.datafwsratio0 = MT41K256M16HA125E_PHY_FIFO_WE,
	.datawrsratio0 = MT41K256M16HA125E_PHY_WR_DATA,
};

static const struct cmd_control ddr3_cmd_ctrl_data = {
	.cmd0csratio = MT41K256M16HA125E_RATIO,
	.cmd0iclkout = MT41K256M16HA125E_INVERT_CLKOUT,

	.cmd1csratio = MT41K256M16HA125E_RATIO,
	.cmd1iclkout = MT41K256M16HA125E_INVERT_CLKOUT,

	.cmd2csratio = MT41K256M16HA125E_RATIO,
	.cmd2iclkout = MT41K256M16HA125E_INVERT_CLKOUT,
};

static struct emif_regs ddr3_emif_reg_data = {
	.sdram_config = MT41J512M8RH125_EMIF_SDCFG,
	.ref_ctrl = MT41K256M16HA125E_EMIF_SDREF,
	.sdram_tim1 = MT41K256M16HA125E_EMIF_TIM1,
	.sdram_tim2 = MT41K256M16HA125E_EMIF_TIM2,
	.sdram_tim3 = MT41K256M16HA125E_EMIF_TIM3,
	.zq_config = MT41K256M16HA125E_ZQ_CFG,
	.emif_ddr_phy_ctlr_1 = MT41K256M16HA125E_EMIF_READ_LATENCY,
};

const struct ctrl_ioregs ioregs = {
	.cm0ioctl		= MT41K256M16HA125E_IOCTRL_VALUE,
	.cm1ioctl		= MT41K256M16HA125E_IOCTRL_VALUE,
	.cm2ioctl		= MT41K256M16HA125E_IOCTRL_VALUE,
	.dt0ioctl		= MT41K256M16HA125E_IOCTRL_VALUE,
	.dt1ioctl		= MT41K256M16HA125E_IOCTRL_VALUE,
};

void sdram_init(void)
{
	config_ddr(400, &ioregs,
		   &ddr3_data,
		   &ddr3_cmd_ctrl_data,
		   &ddr3_emif_reg_data, 0);

	udelay(500);
}

#define OSC (V_OSCK/1000000)
const struct dpll_params dpll_ddr = {
		400, OSC-1, 1, -1, -1, -1, -1};
		// 303, OSC-1, 1, -1, -1, -1, -1};

const struct dpll_params *get_dpll_ddr_params(void)
{
  return &dpll_ddr;
}

Processors

Processors forum

AM3352: u-boot upgrade caused change in cold-boot behavior