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

[Tom Rini]

On Thu, Mar 28, 2013 at 10:50:44AM +0100, Andreas Bie??mann wrote:
> Hi Javier,
> 
> On 03/28/2013 10:11 AM, Javier Martinez Canillas wrote:
> > 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>
> 
> >>> 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?

We shouldn't be concerned with what is destroyed here as it's going to
be related to ROM trying (and then failing and moving on from) to load
via UART the next program.  We've already started and are running, so
the UART is ours to do with as we need.  If ROM did load us over UART it
really should already be in a clean state.

> <snip>
> 
> > 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.
> 
> Thanks for clarification. So there is a need to flush UART before
> initializing it in u-boot context as said by Scott's comment in
> cb55b332, at least for some systems.
> 
> I think Manfred's proposed solution in this patch is ok. It fixes a bug
> when transiting from (some) OMAP ROM code to SPL, therefore we should
> have the code conditionally on SPL and OMAP. Maybe we find out later,
> that this also matches other combinations. But for now I think we should
> just take Manfred's solution in this release, Tom?

Agreed.

> Many thanks to you Manfred for forcing attention on this bug and
> providing a solution.

And also very much agreed!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130328/598a67b1/attachment.pgp>