[U-Boot] [PATCH 1/1 v2] omap3_beagle: Enabling UART3 first allows the Transmitter to be empty

[Andreas Bießmann]

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