On Apr 2, 2013, at 5:32 AM, Sricharan R <r.sricha...@ti.com> wrote: >> On first blush, it looks like having both cm_l3instr_intrconn_wp1_clkct and >> cm_l3instr_intrconn_wp1_clkctrl is a mistake. > > First, on which board are you testing ?. I tested the mainline on my 4460 > ES1.1 PANDA and it booted.
One custom board still under development and also on the same Pandaboard you have. But further testing showed that CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION (and the related EMIF defines) stopped working somewhere between commits a268170 and 417c558. Returning to the pre-canned SDRAM modes allowed booting to work again. The reason I suspected the clocks was that they were the *only* difference in the entire debug log between the working and hanging cases. I don't know why the SDRAM state difference which was the real cause did not produce even a single difference in the log. > As you said the unnecessary entry in omap_common.h should be removed and typo > in prcm-regs.c > I can correct this, but does correcting this gets you working again ? > Enabling these two clocks should have nothing to do with boot. Correct. As I later found, the clocks in question are non-essential for u-boot and were not causing the hang. > Also why are you enabling the non-essential clocks ? Because I must be able to boot Linux kernels as far back as 3.0.8 which predates this paradigm shift. > Now enabling non-essential clocks is deprecated and they are **not** by > enabled by default. As a point of clarification, are you asserting that CONFIG_SYS_CLOCKS_ENABLE_ALL and CONFIG_SYS_ENABLE_PADS_ALL have been officially deprecated (e.g.: is planned for removal from u-boot)? There is no mention of this anywhere within the source tree, including in any documentation or README and, IMO, it would be very premature given that at least 4 Linux kernel lines needing these inits are still within their longterm support window. But clearly until such removal happens dropping any that were previously handled is a regression. Thanks for the assistance! -Mike _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
