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 <[email protected]> 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 <[email protected]>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 <[email protected]>wrote: >>>> >>>>> On Wed, Nov 27, 2013 at 1:28 PM, Brian Mundell <[email protected]> >>>>> 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 [email protected]. >>>>> 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 [email protected]. >>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
