Hi, On Sat, Jul 6, 2013 at 6:36 AM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > With that worked out, throwing my standard printascii() hack into the > kernel results in boot messages... up to the point where the timer is > calibrated. So, it looks like either interrupts, clocks, or the OMAP > timers are non-functional with DT based kernels on the SDP board. > > Any ideas? I'm a bit late to the party due to travel and other things going on, but I have the exact same thing happening with multi_v7_defconfig on my Panda ES right now -- it gets stuck on calibrating delay loop. I needed to enable DEBUG_LL and early printk to not just get a dead system though. What happened in my case was that MACH_OMAP4 was no longer enabled so clocks weren't registered. I wonder if we can improve debugability of that somehow. Before Arnd's patch to flip the MACH_OMAP2PLUS option around, they got enabled by default I think. So now I needed: -CONFIG_ARCH_OMAP2PLUS=y +CONFIG_ARCH_OMAP3=y +CONFIG_ARCH_OMAP4=y CONFIG_SOC_OMAP5=y +CONFIG_SOC_AM33XX=y ...in the defconfig. This is pretty painful, and I don't know if we want to rethink Arnd's patch since it will break existing defconfigs out there that rely on OMAP2PLUS enabling the socs instead of the other way around. Opinions? -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
