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