From: Andrew K. (m. l. account) <ak...@mi...> - 2010-09-17 01:43:23
|
Good evening everyone, This is a continuation on my "Overo Earth: R2766 changes to MMC/booting?" thread from July. It's not a MMC issue at all, it appears to be either U-boot or maybe something that's changed in the requirements on the expansion connector between the R2173 and R2766 revisions of the Overo Earth COM. I RMA'd my original unit (VERY fast turnaround, kudos to Gumstix are in order) and was excited to see that my replacement arrived today. I have a custom expansion board that is based on the Gumstix Tobi board. In fact, I started with the Tobi schematic and built my board around it. I have an R2173 Overo Earth COM that I've been doing all of my development with. It works perfectly with my board. However, when I remove this older COM and plug in an R2766 COM, I just get garbage on the console port. It looks almost like an incorrect baudrate or parity settings, but it's not quite that. It's hard to describe, but anyone who's done a lot of serial work kind of has a "feel" for what an incorrect baudrate/parity settings problem looks like. This is kind of a slower, "meandering" scribbling of garbage, with the occasional burst of garbage. I also know that it's not just an incorrect baudrate since the COM refuses to boot. If it were simply a wrong baudrate it would boot and the network would come up and I would be able to SSH in. Anyway -- This was the exact problem that I'd RMA'd my previous R2766 COM for. The new one is doing the same thing. Plug in the older R2173 COM and it works great. Plug in the new R2766 COM and it's garbage. There are two LEDs on the R2766 COM. When it's first powered on, a faint green LED lights up. After a few seconds of garbage on the console port, a much brighter blue LED lights up, and the garbage continues. Since I am now convinced that there is nothing wrong with the COMs themselves, I am forced to look at the differences between Overo Earth COM revisions. Has anything changed on the expansion connectors that would explain this odd behaviour on R2766 COMs but work just fine with R2173 COMs? -A. |
From: Andrew K. (m. l. account) <ak...@mi...> - 2010-09-17 02:09:29
|
On Thursday, September 16, 2010 09:43:14 pm Andrew Kohlsmith (mailing lists account) wrote: > There are two LEDs on the R2766 COM. When it's first powered on, a faint > green LED lights up. After a few seconds of garbage on the console port, > a much brighter blue LED lights up, and the garbage continues. I think I found something. I tried a different terminal program (I always use minicom). I downloaded and installed cutecom and something interesting showed up. When the new COM powers up, I receive a burst of garbage, the X-Loader comes up, then u-boot. Cutecom displays unprintable characters as hex escape sequences, and this is what it printed: -----8<---------8<------------8<---------8<------------8<---------8<------- \0x04\0x01\0x05\0x05\0xa3\0x06t\0xd8\0xb5b\0x81\0x01\0x00$U\0x16\0x0c @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00QT,0@\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0xf8 Texas Instruments X-Loader 1.4.2 (Apr 27 2010 - 08:23:25) Loading u-boot.bin from nand U-Boot 2009.11 (Apr 27 2010 - 08:24:38) -----8<---------8<------------8<---------8<------------8<---------8<------- It appears to boot normally from NAND, and I eventually get to the login prompt. However if I type anything at any time in the boot process (u-boot, the kernel or login prompt), the COM immediately reboots, and starts ove again at the burst of garbage followed by X-loader loading U-boot. The older (R2173) COM emits something similar on startup, but keypresses do not cause the COM to reboot immediately: -----8<---------8<------------8<---------8<------------8<---------8<------- \0x04\0x01\0x05\0x0140\0x1d\0xbbmL\0xb0`\0x00\0x12U\0x0b\0x0c\0x10@\0x80\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00QT,0@\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0xf8 Texas Instruments X-Loader 1.4.2 (Jul 8 2009 - 21:19:00) Loading u-boot.bin from nand U-Boot 2009.06-rc2 (Jul 08 2009 - 21:20:30) -----8<---------8<------------8<---------8<------------8<---------8<------- Now, I imagine that the garbage burst is some kind of header/ping for some commercial development tool or something similar, but the newer burst seems to confuse the crap out of minicom, where the older burst does not. Is there any way to disable/change this burst? I imagine it requires flashing a new X-loader into the NAND flash, something I'm not all that eager to do. Maybe someone knows a way to tell minicom not to freak out about it? Even with that aside, though, does anyone know why the R2766 COMs reboot immediately after receiving any serial input on their console port? I am using UART3 for the console, just as the Gumstix Tobi boards use, I am using the same 74AHC1G126 to buffer/tristate the FT232 -> GPIO165_IR_RXD3 net as the Tobi. This part of my board is identical to the Tobi (the Tobi shows the same problem with the new COM.) Since my board (and the Tobi) work fine with the older COM but not the newer one, I am convinced that something subtle must have changed in the expansion connector or the connection requirements between R2173 and R2766 Overo Earth COMs. Does anyone have any insights to this? -A. |
From: R. P. M. <log...@gm...> - 2010-09-17 05:49:14
|
That "burst of garbage" is the OMAP internal ROM serial boot ASIC signature. It is sent with even parity, so it will look like garbage when receiving with no parity. It cannot be disabled, it can only be avoided if you boot from a source that is before the serial port in the list of boot devices, IIRC which on Gumstix is only the USB. On 9/17/10, Andrew Kohlsmith (mailing lists account) <ak...@mi...> wrote: > On Thursday, September 16, 2010 09:43:14 pm Andrew Kohlsmith (mailing lists > account) wrote: >> There are two LEDs on the R2766 COM. When it's first powered on, a faint >> green LED lights up. After a few seconds of garbage on the console port, >> a much brighter blue LED lights up, and the garbage continues. > > I think I found something. I tried a different terminal program (I always > use > minicom). I downloaded and installed cutecom and something interesting > showed > up. > > When the new COM powers up, I receive a burst of garbage, the X-Loader comes > up, then u-boot. Cutecom displays unprintable characters as hex escape > sequences, and this is what it printed: > > -----8<---------8<------------8<---------8<------------8<---------8<------- > \0x04\0x01\0x05\0x05\0xa3\0x06t\0xd8\0xb5b\0x81\0x01\0x00$U\0x16\0x0c > @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x00\0x01\0x04\0x08 > @\0x00\0x00\0x00QT,0@\0x00\0x00\0x00\0x01\0x04\0x08 > @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0xf8 > > Texas Instruments X-Loader 1.4.2 (Apr 27 2010 - 08:23:25) > Loading u-boot.bin from nand > > > U-Boot 2009.11 (Apr 27 2010 - 08:24:38) > -----8<---------8<------------8<---------8<------------8<---------8<------- > > It appears to boot normally from NAND, and I eventually get to the login > prompt. However if I type anything at any time in the boot process (u-boot, > the kernel or login prompt), the COM immediately reboots, and starts ove > again > at the burst of garbage followed by X-loader loading U-boot. > > The older (R2173) COM emits something similar on startup, but keypresses do > not cause the COM to reboot immediately: > > -----8<---------8<------------8<---------8<------------8<---------8<------- > \0x04\0x01\0x05\0x0140\0x1d\0xbbmL\0xb0`\0x00\0x12U\0x0b\0x0c\0x10@\0x80\0x00\0x00\0x00\0x01\0x04\0x08 > @\0x00\0x00\0x00\0x01\0x04\0x08 > @\0x00\0x00\0x00QT,0@\0x00\0x00\0x00\0x01\0x04\0x08 > @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0xf8 > > Texas Instruments X-Loader 1.4.2 (Jul 8 2009 - 21:19:00) > Loading u-boot.bin from nand > > > U-Boot 2009.06-rc2 (Jul 08 2009 - 21:20:30) > -----8<---------8<------------8<---------8<------------8<---------8<------- > > Now, I imagine that the garbage burst is some kind of header/ping for some > commercial development tool or something similar, but the newer burst seems > to > confuse the crap out of minicom, where the older burst does not. > > Is there any way to disable/change this burst? I imagine it requires > flashing a > new X-loader into the NAND flash, something I'm not all that eager to do. > Maybe someone knows a way to tell minicom not to freak out about it? > > Even with that aside, though, does anyone know why the R2766 COMs reboot > immediately after receiving any serial input on their console port? I am > using > UART3 for the console, just as the Gumstix Tobi boards use, I am using the > same 74AHC1G126 to buffer/tristate the FT232 -> GPIO165_IR_RXD3 net as the > Tobi. This part of my board is identical to the Tobi (the Tobi shows the > same > problem with the new COM.) > > Since my board (and the Tobi) work fine with the older COM but not the newer > one, I am convinced that something subtle must have changed in the expansion > connector or the connection requirements between R2173 and R2766 Overo Earth > COMs. > > Does anyone have any insights to this? > > -A. > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Ors T. <lis...@gm...> - 2010-09-17 12:01:41
|
Hi, UART3 might be the key word here. AFAIK the OMAP boot ROM uses UART3 to boot from serial. br, Ors On Fri, Sep 17, 2010 at 7:48 AM, R. P. McMurphy <log...@gm...> wrote: > That "burst of garbage" is the OMAP internal ROM serial boot ASIC > signature. It is sent with even parity, so it will look like garbage > when receiving with no parity. It cannot be disabled, it can only be > avoided if you boot from a source that is before the serial port in > the list of boot devices, IIRC which on Gumstix is only the USB. > > On 9/17/10, Andrew Kohlsmith (mailing lists account) <ak...@mi...> > wrote: > > On Thursday, September 16, 2010 09:43:14 pm Andrew Kohlsmith (mailing > lists > > account) wrote: > >> There are two LEDs on the R2766 COM. When it's first powered on, a faint > >> green LED lights up. After a few seconds of garbage on the console > port, > >> a much brighter blue LED lights up, and the garbage continues. > > > > I think I found something. I tried a different terminal program (I > always > > use > > minicom). I downloaded and installed cutecom and something interesting > > showed > > up. > > > > When the new COM powers up, I receive a burst of garbage, the X-Loader > comes > > up, then u-boot. Cutecom displays unprintable characters as hex escape > > sequences, and this is what it printed: > > > > > -----8<---------8<------------8<---------8<------------8<---------8<------- > > \0x04\0x01\0x05\0x05\0xa3\0x06t\0xd8\0xb5b\0x81\0x01\0x00$U\0x16\0x0c > > @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x00\0x01\0x04\0x08 > > @\0x00\0x00\0x00QT,0@\0x00\0x00\0x00\0x01\0x04\0x08 > > @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0xf8 > > > > Texas Instruments X-Loader 1.4.2 (Apr 27 2010 - 08:23:25) > > Loading u-boot.bin from nand > > > > > > U-Boot 2009.11 (Apr 27 2010 - 08:24:38) > > > -----8<---------8<------------8<---------8<------------8<---------8<------- > > > > It appears to boot normally from NAND, and I eventually get to the login > > prompt. However if I type anything at any time in the boot process > (u-boot, > > the kernel or login prompt), the COM immediately reboots, and starts ove > > again > > at the burst of garbage followed by X-loader loading U-boot. > > > > The older (R2173) COM emits something similar on startup, but keypresses > do > > not cause the COM to reboot immediately: > > > > > -----8<---------8<------------8<---------8<------------8<---------8<------- > > \0x04\0x01\0x05\0x0140\0x1d\0xbbmL\0xb0`\0x00\0x12U\0x0b\0x0c\0x10@ > \0x80\0x00\0x00\0x00\0x01\0x04\0x08 > > @\0x00\0x00\0x00\0x01\0x04\0x08 > > @\0x00\0x00\0x00QT,0@\0x00\0x00\0x00\0x01\0x04\0x08 > > @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0xf8 > > > > Texas Instruments X-Loader 1.4.2 (Jul 8 2009 - 21:19:00) > > Loading u-boot.bin from nand > > > > > > U-Boot 2009.06-rc2 (Jul 08 2009 - 21:20:30) > > > -----8<---------8<------------8<---------8<------------8<---------8<------- > > > > Now, I imagine that the garbage burst is some kind of header/ping for > some > > commercial development tool or something similar, but the newer burst > seems > > to > > confuse the crap out of minicom, where the older burst does not. > > > > Is there any way to disable/change this burst? I imagine it requires > > flashing a > > new X-loader into the NAND flash, something I'm not all that eager to do. > > Maybe someone knows a way to tell minicom not to freak out about it? > > > > Even with that aside, though, does anyone know why the R2766 COMs reboot > > immediately after receiving any serial input on their console port? I am > > using > > UART3 for the console, just as the Gumstix Tobi boards use, I am using > the > > same 74AHC1G126 to buffer/tristate the FT232 -> GPIO165_IR_RXD3 net as > the > > Tobi. This part of my board is identical to the Tobi (the Tobi shows the > > same > > problem with the new COM.) > > > > Since my board (and the Tobi) work fine with the older COM but not the > newer > > one, I am convinced that something subtle must have changed in the > expansion > > connector or the connection requirements between R2173 and R2766 Overo > Earth > > COMs. > > > > Does anyone have any insights to this? > > > > -A. > > > > > > > ------------------------------------------------------------------------------ > > Start uncovering the many advantages of virtual appliances > > and start using them to simplify application deployment and > > accelerate your shift to cloud computing. > > http://p.sf.net/sfu/novell-sfdev2dev > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Norman T. <nlt...@gm...> - 2010-11-18 16:55:07
|
I direct this at RP McMurphy who responded to the question in the subject, but anyone else who has knowledge, feel free to chime in: I want to propose an alternate solution to the UART3 problems (i.e., this one, "noise" on the UART3 causing "reboots" or causing the autoboot sequence to stop, "chatter" to the "console" during the boot sequence, etc.) via this paragraph below: boot from the USB. While it appears that there is no way to simply "disable" this console usage, am I correct in the following assessment? (1) if we boot from the USB instead, the communications going to the console will route through the USB, at least until the kernel is loaded (the kernel will use the console specified in the Overo environment variable "console", which is currently limited to serial channels only). Question (2): Which USB is this, from the perspective of the expansion boards? How do know this about the boot order on Overo (or how would I determine the boot order of devices)? Question (3): How do you get the Omap to boot specifically from the USB port? Thanks. I hope none of these questions sound inane, but I am trying to get a handle on this. -Norman Tuttle NLT...@gm... On Fri, Sep 17, 2010 at 1:48 AM, R. P. McMurphy <log...@gm...> wrote: > That "burst of garbage" is the OMAP internal ROM serial boot ASIC > signature. It is sent with even parity, so it will look like garbage > when receiving with no parity. It cannot be disabled, it can only be > avoided if you boot from a source that is before the serial port in > the list of boot devices, IIRC which on Gumstix is only the USB. > > On 9/17/10, Andrew Kohlsmith (mailing lists account) <ak...@mi...> wrote: >> On Thursday, September 16, 2010 09:43:14 pm Andrew Kohlsmith (mailing lists >> account) wrote: >>> There are two LEDs on the R2766 COM. When it's first powered on, a faint >>> green LED lights up. After a few seconds of garbage on the console port, >>> a much brighter blue LED lights up, and the garbage continues. >> >> I think I found something. I tried a different terminal program (I always >> use >> minicom). I downloaded and installed cutecom and something interesting >> showed >> up. >> >> When the new COM powers up, I receive a burst of garbage, the X-Loader comes >> up, then u-boot. Cutecom displays unprintable characters as hex escape >> sequences, and this is what it printed: >> >> -----8<---------8<------------8<---------8<------------8<---------8<------- >> \0x04\0x01\0x05\0x05\0xa3\0x06t\0xd8\0xb5b\0x81\0x01\0x00$U\0x16\0x0c >> @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x00\0x01\0x04\0x08 >> @\0x00\0x00\0x00QT,0@\0x00\0x00\0x00\0x01\0x04\0x08 >> @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0xf8 >> >> Texas Instruments X-Loader 1.4.2 (Apr 27 2010 - 08:23:25) >> Loading u-boot.bin from nand >> >> >> U-Boot 2009.11 (Apr 27 2010 - 08:24:38) >> -----8<---------8<------------8<---------8<------------8<---------8<------- >> >> It appears to boot normally from NAND, and I eventually get to the login >> prompt. However if I type anything at any time in the boot process (u-boot, >> the kernel or login prompt), the COM immediately reboots, and starts ove >> again >> at the burst of garbage followed by X-loader loading U-boot. >> >> The older (R2173) COM emits something similar on startup, but keypresses do >> not cause the COM to reboot immediately: >> >> -----8<---------8<------------8<---------8<------------8<---------8<------- >> \0x04\0x01\0x05\0x0140\0x1d\0xbbmL\0xb0`\0x00\0x12U\0x0b\0x0c\0x10@\0x80\0x00\0x00\0x00\0x01\0x04\0x08 >> @\0x00\0x00\0x00\0x01\0x04\0x08 >> @\0x00\0x00\0x00QT,0@\0x00\0x00\0x00\0x01\0x04\0x08 >> @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0xf8 >> >> Texas Instruments X-Loader 1.4.2 (Jul 8 2009 - 21:19:00) >> Loading u-boot.bin from nand >> >> >> U-Boot 2009.06-rc2 (Jul 08 2009 - 21:20:30) >> -----8<---------8<------------8<---------8<------------8<---------8<------- >> >> Now, I imagine that the garbage burst is some kind of header/ping for some >> commercial development tool or something similar, but the newer burst seems >> to >> confuse the crap out of minicom, where the older burst does not. >> >> Is there any way to disable/change this burst? I imagine it requires >> flashing a >> new X-loader into the NAND flash, something I'm not all that eager to do. >> Maybe someone knows a way to tell minicom not to freak out about it? >> >> Even with that aside, though, does anyone know why the R2766 COMs reboot >> immediately after receiving any serial input on their console port? I am >> using >> UART3 for the console, just as the Gumstix Tobi boards use, I am using the >> same 74AHC1G126 to buffer/tristate the FT232 -> GPIO165_IR_RXD3 net as the >> Tobi. This part of my board is identical to the Tobi (the Tobi shows the >> same >> problem with the new COM.) >> >> Since my board (and the Tobi) work fine with the older COM but not the newer >> one, I am convinced that something subtle must have changed in the expansion >> connector or the connection requirements between R2173 and R2766 Overo Earth >> COMs. >> >> Does anyone have any insights to this? >> >> -A. >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: R. P. M. <log...@gm...> - 2010-11-22 13:25:30
|
(1) You can read about the boot sequence and how you can boot from various devices in the TI manual (in the Initialisation chapter). http://www.ti.com/litv/pdf/spruf98l I don't have any experience booting from the USB but my understanding is this. If you boot from the USB then you send in the boot code from a USB attached device (probably a PC). After that it depends upon the boot code that you uploaded as to which peripherals future messages will be delivered to. If you uploaded the normal U-Boot then it will still use UART3 as the output for subsequent booting messages, but you can always make your own boot code and do whatever you need from there. (2) The OMAP ROM always uses HSUSB0 for booting. It depends upon your expansion board as to where the physical connection for HSUSB0 is located. (3) The Overo is preconfigured to do peripheral booting. See the manual for boot mode 0b101111 (0x2F). On 11/19/10, Norman Tuttle <nlt...@gm...> wrote: > I direct this at RP McMurphy who responded to the question in the > subject, but anyone else who has knowledge, feel free to chime in: > > I want to propose an alternate solution to the UART3 problems (i.e., > this one, "noise" on the UART3 causing "reboots" or causing the > autoboot sequence to stop, "chatter" to the "console" during the boot > sequence, etc.) via this paragraph below: boot from the USB. While it > appears that there is no way to simply "disable" this console usage, > am I correct in the following assessment? > > (1) if we boot from the USB instead, the communications going to the > console will route through the USB, at least until the kernel is > loaded (the kernel will use the console specified in the Overo > environment variable "console", which is currently limited to serial > channels only). > Question (2): Which USB is this, from the perspective of the expansion > boards? How do know this about the boot order on Overo (or how would I > determine the boot order of devices)? > Question (3): How do you get the Omap to boot specifically from the USB > port? > > Thanks. I hope none of these questions sound inane, but I am trying to > get a handle on this. > > -Norman Tuttle > NLT...@gm... > > On Fri, Sep 17, 2010 at 1:48 AM, R. P. McMurphy <log...@gm...> wrote: >> That "burst of garbage" is the OMAP internal ROM serial boot ASIC >> signature. It is sent with even parity, so it will look like garbage >> when receiving with no parity. It cannot be disabled, it can only be >> avoided if you boot from a source that is before the serial port in >> the list of boot devices, IIRC which on Gumstix is only the USB. >> >> On 9/17/10, Andrew Kohlsmith (mailing lists account) <ak...@mi...> >> wrote: >>> On Thursday, September 16, 2010 09:43:14 pm Andrew Kohlsmith (mailing >>> lists >>> account) wrote: >>>> There are two LEDs on the R2766 COM. When it's first powered on, a faint >>>> green LED lights up. After a few seconds of garbage on the console >>>> port, >>>> a much brighter blue LED lights up, and the garbage continues. >>> >>> I think I found something. I tried a different terminal program (I >>> always >>> use >>> minicom). I downloaded and installed cutecom and something interesting >>> showed >>> up. >>> >>> When the new COM powers up, I receive a burst of garbage, the X-Loader >>> comes >>> up, then u-boot. Cutecom displays unprintable characters as hex escape >>> sequences, and this is what it printed: >>> >>> -----8<---------8<------------8<---------8<------------8<---------8<------- >>> \0x04\0x01\0x05\0x05\0xa3\0x06t\0xd8\0xb5b\0x81\0x01\0x00$U\0x16\0x0c >>> @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x00\0x01\0x04\0x08 >>> @\0x00\0x00\0x00QT,0@\0x00\0x00\0x00\0x01\0x04\0x08 >>> @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0xf8 >>> >>> Texas Instruments X-Loader 1.4.2 (Apr 27 2010 - 08:23:25) >>> Loading u-boot.bin from nand >>> >>> >>> U-Boot 2009.11 (Apr 27 2010 - 08:24:38) >>> -----8<---------8<------------8<---------8<------------8<---------8<------- >>> >>> It appears to boot normally from NAND, and I eventually get to the login >>> prompt. However if I type anything at any time in the boot process >>> (u-boot, >>> the kernel or login prompt), the COM immediately reboots, and starts ove >>> again >>> at the burst of garbage followed by X-loader loading U-boot. >>> >>> The older (R2173) COM emits something similar on startup, but keypresses >>> do >>> not cause the COM to reboot immediately: >>> >>> -----8<---------8<------------8<---------8<------------8<---------8<------- >>> \0x04\0x01\0x05\0x0140\0x1d\0xbbmL\0xb0`\0x00\0x12U\0x0b\0x0c\0x10@\0x80\0x00\0x00\0x00\0x01\0x04\0x08 >>> @\0x00\0x00\0x00\0x01\0x04\0x08 >>> @\0x00\0x00\0x00QT,0@\0x00\0x00\0x00\0x01\0x04\0x08 >>> @\0x00\0x00\0x00\0x01\0x04\0x08 @\0x00\0x00\0x00\0x01\0x04\0xf8 >>> >>> Texas Instruments X-Loader 1.4.2 (Jul 8 2009 - 21:19:00) >>> Loading u-boot.bin from nand >>> >>> >>> U-Boot 2009.06-rc2 (Jul 08 2009 - 21:20:30) >>> -----8<---------8<------------8<---------8<------------8<---------8<------- >>> >>> Now, I imagine that the garbage burst is some kind of header/ping for >>> some >>> commercial development tool or something similar, but the newer burst >>> seems >>> to >>> confuse the crap out of minicom, where the older burst does not. >>> >>> Is there any way to disable/change this burst? I imagine it requires >>> flashing a >>> new X-loader into the NAND flash, something I'm not all that eager to do. >>> Maybe someone knows a way to tell minicom not to freak out about it? >>> >>> Even with that aside, though, does anyone know why the R2766 COMs reboot >>> immediately after receiving any serial input on their console port? I am >>> using >>> UART3 for the console, just as the Gumstix Tobi boards use, I am using >>> the >>> same 74AHC1G126 to buffer/tristate the FT232 -> GPIO165_IR_RXD3 net as >>> the >>> Tobi. This part of my board is identical to the Tobi (the Tobi shows the >>> same >>> problem with the new COM.) >>> >>> Since my board (and the Tobi) work fine with the older COM but not the >>> newer >>> one, I am convinced that something subtle must have changed in the >>> expansion >>> connector or the connection requirements between R2173 and R2766 Overo >>> Earth >>> COMs. >>> >>> Does anyone have any insights to this? >>> >>> -A. >>> >>> >>> ------------------------------------------------------------------------------ >>> Start uncovering the many advantages of virtual appliances >>> and start using them to simplify application deployment and >>> accelerate your shift to cloud computing. >>> http://p.sf.net/sfu/novell-sfdev2dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |