On Thu, Mar 28, 2013 at 9:45 AM, Andreas Bießmann andreas.devel@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