Commit Message

SPL hangs on a beagleboard during the serial initialization (line 40 of drivers/serial/ns16550.c). The reason is the non-empty shift register of TX (transmit FIFO is empty). To avoid the hangup include/configs/omap3_beagle.h has to be changed like in include/configs/igep00x0.h:
Best regards,
Manfred Huber

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!

On 2013-03-19 15:49, Tom Rini 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!>
Thanks for your answer. I have only one Beagleboard Revision C4
(CONTROL_IDCODE of the OMAP3530 is 0x4B7AE02F). My host is a Ubuntu
12.10 (Quantal Quetzal) and I use the gcc-arm-linux-gnueabihf
cross-compiler version 4.7.2-1.
Compiling the actual u-boot leaded to the reported error. All version
since commit cb55b3320014b7f6014416c556fe506efbf0a84b led to the
hanging. All version before boots correctly.
Adding the define to omap3_beagle.h leads to a correct booting for all
versions. Also a reset of the uart at the beginning of the init function
leads to a correct booting. So I exclude that the hardware is defective.
If you can tell me your compiler and version I can try to use your
cross-compiler.
Best regards,
Manfred

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.
Thanks a lot and best regards,
Javier

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRSRB2AAoJENk4IS6UOR1WP9YP/2McsjKVfEFq1Xooosts6v7Y
iyLfGg/yYxszfFABTtCwMUn/GjCw5kLjLQB3zISOdR15GTneZ3NCiXcLY6Z/AgId
2gCDV7MOg1WSXyItIn6M+ra/Dt+HMT5VrwN8Z10GPpzQj58HCiJV/12115mMQKLN
fWIRCMALetJkIddogNrcZluIJDwR9ye3QTy8p6jE8uy5QBvuu3QyDr+CrJKq3gEk
BKuC0+9xLjHSMG8KcGG4QEObmzOFyw227lR6Cmfdw8cK52XE2v+11jZk/3vFHfFf
xlL117wRzd8H1r9LGY8SNnzIuz+G6hDwa1n7kpmYLW6S8I5F5b4gOsS7pmA908CQ
vognhGq4GSg6SZEqFk6s4OcqfdEG4+dCcXxFLy0iD0GeAkvet4G97SqQgvVAbJ8m
By1gsrwsK05j5rtPeA3ELSbM4AOu8jVJZI210eZYyRHW+b4qyA7Sl+W4CqDHiwLk
SGt4UT0S6/6fnV9M4oKq3xhh3R59ZYhkeUiOFoL4cUwOlp9PXbaWgkiNGyYZBCoQ
5XmfNGGyiT5bcueeyR1Swtw8UNX+FA4sncnJrtELFqRpb9SNFJq3GdTx9gNAJz6a
Q+RS41IApAUz8vPq0Kg8JWF0h7C1IqRWMzLi3mIXpxZCbYy+0ElAgLMp3XeKbYhx
SF/nnpv1PKMGWQVobw0s
=9RxY
-----END PGP SIGNATURE-----

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

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

Hi all,
probably I found the error. It should be a bug in the ROM code of the OMAP3.
Depending on the Booting Sequence of the OMAP3, SPL is hanging or not.
If ROM code configures UART3 before SPL starts from NAND it will lead to
a hang of the SPL. If UART3 is not configured, SPL boots correctly from
NAND.
If ROM code configures UART3 it leaves the UART in a bad state. Although
Transmitter is not empty (TEMT is not set), ROM code disables the UART.
Therefore Transmitter can never get empty.
In a normal Booting Sequence where NAND is for UART3 the bug will never
appear.
There are some solutions:
1. Configuring UART3 first and let Transmitter send until Transmitter is
empty.
2. Soft reset of Transmitter. (OMAP3 specific, NS16550 has no soft reset)
3. ...
Please tell me your assessment.
Best regards,
Manfred Huber