Other Parts Discussed in Thread: TPS65910, AM3354
Hi,
with a custom board (AM3354, TPS65910, MT41K256M16HA-125:E) the MLO gets stuck. Normal boot setup is to boot from SD-card. The MLO is loaded from SD-card and transferred to 0x402f0400. This I could see through the JTAG.
In a debugging session (as described in http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5) the MLO gets stuck at execution of rtc32k_enable (similar as described in https://e2e.ti.com/support/arm/sitara_arm/f/791/t/343695).
MLO is u-boot 2013.07, function is s_init as below:
/*
* early system init of muxing and clocks.
*/
void s_init(void)
{
/*
* Save the boot parameters passed from romcode.
* We cannot delay the saving further than this,
* to prevent overwrites.
*/
#ifdef CONFIG_SPL_BUILD
save_omap_boot_params();
#endif
/* WDT1 is already running when the bootloader gets control
* Disable it to avoid "random" resets
*/
writel(0xAAAA, &wdtimer->wdtwspr);
while (readl(&wdtimer->wdtwwps) != 0x0)
;
writel(0x5555, &wdtimer->wdtwspr);
while (readl(&wdtimer->wdtwwps) != 0x0)
;
#ifdef CONFIG_SPL_BUILD
/* Setup the PLLs and the clocks for the peripherals */
pll_init();
/* Enable RTC32K clock */
rtc32k_enable();
All power rails have their correct voltages. What could cause the CPU to fail in this early stadium? DDR-RAM initialization should happen later - after board type detection. Any ideas to analyze this effect more in depth?
Regards
Arndt