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

[Javier Martinez Canillas <javier@dowhile0.org>]

On Thu, Mar 21, 2013 at 12:09 AM, Manfred Huber <man.huber@arcor.de> wrote:
> 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@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.
>

I see the same behavior in the IGEPv2. I tested mainline U-boot + your
"[PATCH] omap3_beagle: Enable CONFIG_SYS_NS16550_BROKEN_TEMT" patch
and SPL boots OK on my board.

> 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.
>

I prefer this approach if it doesn't affect other boards.

> 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
>
>

Best regards,
Javier