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