[U-Boot] Beagleboard: SPL hangs on serial init

[Manfred Huber]

Am 20.03.2013 02:27, schrieb Tom Rini:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/19/2013 08:05 PM, Javier Martinez Canillas wrote:
>> On Tue, Mar 19, 2013 at 3:49 PM, Tom Rini <trini at ti.com> wrote:
>>> On Sat, Mar 16, 2013 at 02:13:54PM +0100, Manfred Huber wrote:
>>>
>>>> I'm surprised that no one is interested in a functioning
>>>> Beagleboard. Has no one tested the Beagleboard since
>>>> 2012-09-19?
>>>
>>> I don't see this problem on mine (classic and xM), which is
>>> probably part of the why.  I'm inclined to accept the patch, but
>>> can you try two things please: - How reproducible is this
>>> problem, with the host and beagleboard combination you have?
>>> 100%? - Do you have another beagleboard or another host PC (or
>>> USB-Serial dongle) you can try?
>>>
>>> Thanks!
>>>
>>> -- Tom
>>
>> Hi,
>>
>> I had this issue on another TI OMAP3 based board (IGEPv2) which
>> use an DM3730 processor. Other IGEP board users reported that
>> U-Boot hung on their boards and that a patch to not wait for the
>> Transmitter Empty (TEMT) to initialize the serial console fixed
>> the issue. So I added the CONFIG_SYS_NS16550_BROKEN_TEMT config
>> option and used it for IGEP boards (igep00x0) to make them boot
>> again.
>>
>> Back then I also tested on a Beagleboard Rev. C4 since it has the
>> same ns16550 UART controller than the IGEPv2 as far as I
>> understood. I used the exact U-Boot version, USB-Serial cable,
>> host PC and terminal emulation program that I used for the IGEPv2
>> and the Beagleboard booted correctly. This is the same behavior
>> that Tom had on his Beagleboard.
>>
>> Since it worked on the Beagle I thought the issue was only present
>> on IGEP boards but now Manfred says that he has the same issue on
>> his Beagleboard. I now wonder if all IGEPv2 are broken or only my
>> board and the ones of the users that cared to report this and
>> other IGEPv2 can boot without CONFIG_SYS_NS16550_BROKEN_TEMT.
>
> Yeah, this is very perplexing.  I'm thinking we need to enable this
> "quirk" for all of the "omap" platforms except for OMAP3_ZOOM (which
> iirc has a different uart chip wired up rather than the SoC uart).
>
> - --
> Tom

As I described in my first mail the reason is the missing UART_LSR_TEMT 
bit in the line status register. Comparing the UART_LSR_THRE bit instead 
works in my case.

Maybe Javier can test on his IGEP board if it works for him to compare 
the UART_LSR_THRE bit instead of the UART_LSR_TEMT bit.

Another solution would be to make a soft reset of the UART as first 
command in the init function. This works also in my case.

On the other hand we can try to identify which OMAP3 has this behavior. 
The module version register of the UART returns version 4.6.

Best regards,
Manfred