But whether or not I get serial debug information on those headers, the real question is if I'm really in the right place for configuring the cape, or whether I'm just passing bootargs that configure how the armhf (and assorted other system chips) talks to the rest of the system and/or the debug headers. If this wasn't the case, why would cape config hang boot? And since 9600 baud is super common for coms with routers, it seems like maybe I'm not really talking to the cape rs232 chips, which basically would never ship without being able to handle/pass 9600 baud coms?
Assuming I can't get the cape working, is there a way to just use the debug headers as a console and throw the cape away, just solder a 9-pin DSUB to those headers? But I guess I'd still need 9600 baud. On Tuesday, December 3, 2013 11:52:25 AM UTC-8, William Hermans wrote: > > Brian, it really is not that hard. Personally I use an MSP430 Launchpad > v1.15 to get the serial console from the Serial debug header. I can not > read / see output from uboot as I believe it is hard coded to 115200bps ( > msp430 LP's max baud is 9600 ), but i get the Linux boot terminal just > fine. That is once /etc/inittab is read from / loaded with the proper > setting for me on the Serial Debug port > > Anyway, like I said until you hook up to the Serial debug header and get > boot time messages, you're likely to never know whats going wrong. You can > buy some FTDI adapters fairly cheaply, and if they cost too much for you > soem USB to serial adapter can be had for as little as $1.26 (ish) each > with free shipping. From Hong Kong no doubt. > > > On Tue, Dec 3, 2013 at 11:46 AM, Brian Mundell > <hexbl...@gmail.com<javascript:> > > wrote: > >> I suppose I could debug using the header, but really the question is how >> BBB used ttyO0 vs. ttyO2, i.e. does it think ttyO0 is a default console >> used as a virtual "display" in the absence of hdmi out? Otherwise, why >> would changing baud make boot fail? I am tempted to re-flash the eMMC yet >> again with the same image I am using, then just add a second line: >> >> console=ttyO2,9600n8 >> >> and leaving the ttyO0 console line uncommented, so it tries to create 2 >> separate consoles, will this break things? >> >> The other obvious idea would be just to rip off the serial cape and just >> do pinouts for my serial out from one of the headers to a 9-pin DSUB and be >> done. This is the hardest I've ever worked to get any serial out from an >> embedded board, which is the most basic coms there is. I don't want to use >> usb -> serial because I'm using this on a solar project, and I need the >> lowest power possible, and I believe that takes more power. Come to think >> of it, if I didn't need the low power, I would've burned the whole BBB idea >> long ago, this is impossibly hard for an impossibly simple task: serial >> coms using minicom. >> >> Still, if I get this figured out and working, I'll publish a howto to >> give back to the rest of the community, as I feel sorry for others trying >> to make this (seemingly simple) thing work. >> >> On Monday, December 2, 2013 3:31:56 PM UTC-8, William Hermans wrote: >>> >>> I woud recommend that you get a 3v3 ttl serial debug cable if you do not >>> have one already, and debug over the serial debug device ttyO0. >>> >>> I know you're trying to get serial on a cape working but this is the >>> only real way you'll know what is going on at boot time. So until you get >>> one of these adapters, you can end up being stuck on this problem >>> indefinitely. >>> >>> The cables cost around $20, but if you're saavy with electronics and >>> USB<-> serial adapters you can get something much cheaper. Also here is a >>> quick simple pinout of the serial debug header. >>> >>> https://lh4.googleusercontent.com/-3oca40vrH-g/Ubd5TjD-0_I/ >>> AAAAAAAAALU/-GibZBaTvKk/s1024/beaglebone-black-serial.jpg >>> >>> Just make sure you use 3v3 ttl !!! >>> >>> >>> On Mon, Dec 2, 2013 at 11:29 AM, Brian Mundell <hexbl...@gmail.com>wrote: >>> >>>> I changed the baud rate, so it looks like: >>>> >>>> console=ttyO2,9600n8 >>>> >>>> and now it won't boot with the cape on. If I pull the cape off and then >>>> try to boot, I get to the penguin icon on my hdmi display, and it sits >>>> there for probably 5 minutes (presumably timing out while waiting for >>>> console?) and I can never ping/ssh (or get a physical console on the hdmi >>>> display). Is there a key sequence (or button sequence) to do the >>>> equivalent >>>> of passing commands manually through GRUB when a system won't boot? How >>>> does uboot handle this, or should I just re-image the eMMC again? Might I >>>> have a defective cape? >>>> >>>> >>>> On Thursday, November 28, 2013 2:25:19 AM UTC-8, William Hermans wrote: >>>>> >>>>> console=ttyO0,9600n8 >>>>> >>>>> The above works for a fact, at least on my own BBB. I have to use this >>>>> BAUD rate since I use an MSP430 Launchpad as a serial debug interface( >>>>> and >>>>> max BAUD rate is 9600 bps ) As for the rest, I couldn't say. >>>>> >>>>> >>>>> On Wed, Nov 27, 2013 at 1:06 PM, Robert Nelson <robert...@gmail.com>wrote: >>>>> >>>>>> On Wed, Nov 27, 2013 at 1:28 PM, Brian Mundell <hexbl...@gmail.com> >>>>>> wrote: >>>>>> > Ok, I flashed eMMC with the >>>>>> > https://rcn-ee.net/deb/rootfs/wheezy/debian-7.2-console-armh >>>>>> f-2013-11-15.tar.xz >>>>>> > image (from a live image running on a microSD) successfully and >>>>>> rebooted >>>>>> > into the eMMC. >>>>>> > >>>>>> > Now I see /boot/uboot/uEnv.txt like I expect. But when I changed the >>>>>> > >>>>>> > console=ttyO0,115200n8 >>>>>> > >>>>>> > to >>>>>> > >>>>>> > console=ttyO2,9600n8 >>>>>> > >>>>>> > (to connect to the serial cape connected to my serial-managed >>>>>> firewall box) >>>>>> > the BBB wouldn't boot. After I reflashed the eMMC to the same image >>>>>> as >>>>>> > above, it booted again. >>>>>> > >>>>>> > I'm wondering if the ttyO0 is reserved for some pins in case I need >>>>>> a >>>>>> > "serial monitor" if my hdmi out breaks, and whether I can add a >>>>>> second ttyOx >>>>>> > of ttyO2 (which matches my UART2 tx/rx jumper settings on the cape) >>>>>> somehow >>>>>> > with setserial (or whatever), since my dmesg shows: >>>>>> > >>>>>> > root@arm:/boot/uboot# dmesg | grep tty >>>>>> > [ 0.000000] Kernel command line: console=ttyO0,115200n8 >>>>>> > root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc ip= >>>>>> > [ 0.524587] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) >>>>>> is a >>>>>> > OMAP UART0 >>>>>> > [ 1.267931] console [ttyO0] enabled >>>>>> > [ 1.805555] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) >>>>>> is a >>>>>> > OMAP UART2 >>>>>> > >>>>>> > which seems to say that it sees ttyO2 at UART2, but that ttyO2 isn't >>>>>> > enabled, no? >>>>>> > >>>>>> > could I add a second console directive in uEnv.txt or should I do >>>>>> something >>>>>> > else? >>>>>> >>>>>> Works here: (with serial cape set on usart2) >>>>>> >>>>>> >>>>>> debian@arm:/boot/uboot$ cat uEnv.txt | grep console >>>>>> #console=ttyO0,115200n8 >>>>>> console=ttyO2,115200n8 >>>>>> >>>>>> before uEnv.txt change.. >>>>>> [ 0.524853] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is >>>>>> a OMAP UART0 >>>>>> [ 1.270648] console [ttyO0] enabled >>>>>> [ 1.807671] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) is >>>>>> a OMAP UART2 >>>>>> >>>>>> after: >>>>>> [ 0.524574] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is >>>>>> a OMAP UART0 >>>>>> [ 0.668322] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) is >>>>>> a OMAP UART2 >>>>>> [ 2.008782] console [ttyO2] enabled >>>>>> >>>>>> ttyO0: >>>>>> reading /dtbs/am335x-boneblack.dtb >>>>>> 24884 bytes read in 11 ms (2.2 MiB/s) >>>>>> Kernel image @ 0x80200000 [ 0x000000 - 0x32fdb0 ] >>>>>> ## Flattened Device Tree blob at 815f0000 >>>>>> Booting using the fdt blob at 0x815f0000 >>>>>> Using Device Tree in place at 815f0000, end 815f9133 >>>>>> >>>>>> Starting kernel ... >>>>>> >>>>>> Uncompressing Linux... done, booting the kernel. >>>>>> >>>>>> Debian GNU/Linux 7 arm ttyO0 >>>>>> >>>>>> arm login: >>>>>> (i didn't change /etc/crontab, so login still appeared..) >>>>>> >>>>>> ttyO2: >>>>>> [ 23.786194] usb usb2: New USB device found, idVendor=1d6b, >>>>>> idProduct=0002 >>>>>> [ 23.793506] usb usb2: New USB device strings: Mfr=3, Product=2, >>>>>> SerialNumber=1 >>>>>> [ 23.801107] usb usb2: Product: MUSB HDRC host driver >>>>>> [ 23.806326] usb usb2: Manufacturer: Linux 3.8.13-bone30 musb-hcd >>>>>> [ 23.812654] usb usb2: SerialNumber: musb-hdrc.0.auto >>>>>> [ 23.833483] hub 2-0:1.0: USB hub found >>>>>> [ 23.850025] hub 2-0:1.0: 1 port detected >>>>>> apache2: Could not reliably determine the server's fully qualified >>>>>> domain name, using 127.0.1.1 for ServerName >>>>>> . ok >>>>>> [ ok ] Loading cpufreq kernel modules...done (none). >>>>>> [ ok ] Starting periodic command scheduler: cron. >>>>>> [ ok ] Starting system message bus: dbus. >>>>>> [ ok ] CPUFreq Utilities: Setting ondemand CPUFreq >>>>>> governor...CPU0...done. >>>>>> Starting very small Busybox based DHCP server: Starting >>>>>> /usr/sbin/udhcpd... >>>>>> udhcpd. >>>>>> [ ok ] Starting OpenBSD Secure Shell server: sshd. >>>>>> [ 26.108307] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready >>>>>> >>>>>> (bootlog) >>>>>> >>>>>> btw: i didn't change the baud rate, but that should work... >>>>>> >>>>>> Regards, >>>>>> >>>>>> -- >>>>>> Robert Nelson >>>>>> http://www.rcn-ee.com/ >>>>>> >>>>>> -- >>>>>> For more options, visit http://beagleboard.org/discuss >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "BeagleBoard" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to beagleboard...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>> >>>>> >>>>> -- >>>> For more options, visit http://beagleboard.org/discuss >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "BeagleBoard" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to beagleboard...@googlegroups.com. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to beagleboard...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
