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

login
register
mail settings
Submitter man.huber@arcor.de
Date Feb. 27, 2013, 1:09 p.m.
Message ID <1679653192.50708.1361970554739.JavaMail.ngmail@webmail21.arcor-online.net>
Download mbox | patch
Permalink /patch/224164/
State Superseded
Delegated to: Tom Rini
Headers show

Comments

man.huber@arcor.de - Feb. 27, 2013, 1:09 p.m.
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
man.huber@arcor.de - March 16, 2013, 1:13 p.m.
I'm surprised that no one is interested in a functioning Beagleboard. 
Has no one tested the Beagleboard since 2012-09-19?

Best regards,
Manfred Huber

On 2013-02-27 14:09, man.huber@arcor.de wrote:
> 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:
>
> diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
> index 59255c4..63cd30b 100644
> --- a/include/configs/omap3_beagle.h
> +++ b/include/configs/omap3_beagle.h
> @@ -81,6 +81,9 @@
>   #define CONFIG_SYS_NS16550_REG_SIZE    (-4)
>   #define CONFIG_SYS_NS16550_CLK         V_NS16550_CLK
>   
> +/* define to avoid U-Boot to hang while waiting for TEMT */
> +#define CONFIG_SYS_NS16550_BROKEN_TEMT
> +
>   /*
>    * select serial console configuration
>    */
>
> Best regards,
> Manfred Huber
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Tom Rini - March 19, 2013, 2:49 p.m.
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!
man.huber@arcor.de - March 19, 2013, 11:52 p.m.
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
Javier Martinez Canillas - March 20, 2013, 12:05 a.m.
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
Tom Rini - March 20, 2013, 1:27 a.m.
-----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-----
man.huber@arcor.de - March 20, 2013, 11:09 p.m.
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
Javier Martinez Canillas - March 21, 2013, 9:08 p.m.
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
man.huber@arcor.de - March 23, 2013, 10:11 a.m.
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

Patch

diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 59255c4..63cd30b 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -81,6 +81,9 @@ 
 #define CONFIG_SYS_NS16550_REG_SIZE    (-4)
 #define CONFIG_SYS_NS16550_CLK         V_NS16550_CLK
 
+/* define to avoid U-Boot to hang while waiting for TEMT */
+#define CONFIG_SYS_NS16550_BROKEN_TEMT
+
 /*
  * select serial console configuration
  */