| Message ID | 1679653192.50708.1361970554739.JavaMail.ngmail@webmail21.arcor-online.net |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
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
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
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 */