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

[Manfred Huber]

Am 28.03.2013 09:45, schrieb 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);
>>>
<snip>
> 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?
Beagleboard has several ways to boot (NAND, SD/MMC, UART, ...). For the 
boot mode with UART, Beagleboard configures the UART and ends with a non 
empty transmitter. In a booting sequence where UART is before NAND, 
SD/MMC or wherever SPL starts from, we have not a clean UART.
>
<snip>

>>
>> 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.
Can you test this boars with my patch?
>
> Best regards
>
> Andreas Bießmann
>