Menu
▾
▴
Re: [Gumstix-users] Overo Earth console problem with R2766, but R2173 boards are fine
|
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 > |