Hi Tony, On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote: > * Bedia, Vaibhav <vaibhav.bedia@xxxxxx> [130705 01:17]: > > > > I just checked the behavior on my AM335x-EVM. Current mainline boots fine > > provided I don't use earlyprintk. The offending patch [1] in this case is the one > > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently > > also results in the console UART getting reset and idled during bootup and that's where > > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see > > the system booting fine. > > > > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in > > omap_serial_early_init() to get earlyprintk working again. > > Hmm nothing should get idled while earlyprintk is running, and then when the > serial driver kicks in it should not idle anything by default. And for DT based > booting we should not have mach-omap2/serial.c initialize anything. > If I add in the HWMOD flags without any reverts I get to the point where the serial driver comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2] just like Mark reported. > I wonder if this is because the timeouts get now initialized to 0 instead > of -1 for the serial driver? > You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i am missing something DT-boot will start off with timeout set to 0 and then get forced to -1. Regards, Vaibhav === [1] [ 0.000000] Booting Linux on physical CPU 0x0 <...> [ 0.190107] SMP: Total of 1 processors activated (363.72 BogoMIPS). [ 0.196711] CPU: All CPU(s) started in SVC mode. [ 0.205580] devtmpfs: initialized <stops here if booted with earlyprintk> [2] [ 0.000000] Booting Linux on physical CPU 0x0 <...> [ 1.453364] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568 [ 1.467121] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled <stops here if booted with earlyprintk> -- 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
