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

[Javier Martinez Canillas]

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