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 <hexblad...@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- >>> armhf-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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
