On Thu, Mar 28, 2013 at 9:45 AM, Andreas Bießmann <andreas.de...@googlemail.com> wrote: > Dear Manfred Huber, > > On 03/28/2013 07:06 AM, Manfred Huber wrote: >> On 2013-03-27 14:37, Andreas Bießmann wrote: > > <snip> > >>> On 03/25/2013 11:02 PM, Manfred Huber wrote: > > <snip> > >>>> + serial_out(UART_LCR_DLAB, &com_port->lcr); >>>> + serial_out(baud_divisor & 0xff, &com_port->dll); >>>> + serial_out((baud_divisor >> 8) & 0xff, &com_port->dlm); >>>> + serial_out(UART_LCRVAL, &com_port->lcr); >>>> + serial_out(0, &com_port->mdr1); >>> >>> Do we need to setup baud a.s.o. here? Isn't it enough to issue an soft >>> reset of the UART? I'm not in this material, I just wonder if we can >>> omit some of the lines here cause we set e.g. the BAUD later on. >>> >> >> The reason to setup the baud is for the shift register. It only works >> with programmed baud registers. A soft reset would also work, but as >> Scott Wood said it would corrupt the last character. On the other hand >> the character should be corrupted by disabling the UART. I have no >> preferred solution: programming the UART or a soft reset. Maybe someone >> wants to decide. > > Well, I think also that re-programming the UART will destroy the last > character in shift register anyway. > I wonder which use-case requires UART flushing in u-boot context before > initializing the UART for u-boot correctly. Can someone explain this to > me? Shouldn't we always start here from the very beginning and setup > UART as configured? > >> >>>> + } >>>> +#endif >>>> + >>>> while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT)) >>>> ; >>>> -#endif >>>> >>>> serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier); >>>> #if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \ >>> >>> I managed to apply your patch anyhow. A short test on a tricorder board >>> showed no harm to the boot process. So please get your patch clean and >>> resend, then I will add my tested-by. >>> >>> As Javier pointed out please think about using the >>> CONFIG_SYS_NS16550_BROKEN_TEMT instead of SPL && OMAP34XX. >>> Another solution could be to have this TEMT | THRE check in >>> unconditionally, this however would require a lot more testing. >>> Especially with the release date in mind. >> >> It's not critical. So I guess it's not needed for this release. > > Well, if there are boards in the field that will not boot with the next > release I think it is critical. > We do have some omap3 (omap35xx and am37xx) based boards here. I can > recall a situation where some few boards did not boot from sd-card while > serial debug cable was attached (AFAIR this was not the case when > booting from NAND). The root cause was never investigated, so maybe we > suffered exactly this bug. > > Best regards > > Andreas Bießmann
Hi Andreas, When I first hit this bug I tried removing the serial debug cable and this made my IGEPv2 to boot correctly. Then I looked at the latest changes to the serial ns16550 driver and found that cb55b332 "serial/ns16550: wait for TEMT before initializing" was the culprit commit that made my board to not boot. So, if I remember correctly, it seems as you hit the exact same bug (I didn't try to boot from NAND back then though) Best regards, Javier _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
