I’m trying to pass console info of ttyO2 to match my jumper settings/baud 9600 on a RS232 cape, but my kernel says:
dmesg | grep tty
[ 0.000000] Kernel command line: console=ttyO0,115200n8 fixrtc root=/dev/mmcblk1p2 …
As I understand in Angstrom, I would pass my boot args for console as /media/BEAGLEBONE/uEnv.txt or some such, how do I do this in Debian Wheezy?
uEnv.txt on the boot partition... /boot/uboot/uEnv.txt when running the system..
Regards,
I looked to see if i could find that file for numerous hours… It was not there. Should it be created, then edited to have what I need in it?
Okay so obviously, your running that other image. Well that user
doesn't post here, so go ask the question on his site..
Otherwise run the images hosted here:
http://elinux.org/BeagleBoardDebian#Demo_Image
or
http://elinux.org/BeagleBoardDebian#eMMC:_BeagleBone_Black
Which happen to be made for developers to actually change things...
Regards,
The file (uEnv.txt) was created and the contents of it say just this:
console=ttyO2,9600n8
There is nothing else in that file. After I rebooted with this file in place it is still not passing traffic through minicom to a Junpier NS5GT and back.
Ok so I am going to re-flash this eMMC and see if I can get it set up. Thank you very much Robert for the help. Post my results later.
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,
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.
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?
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.
Just make sure you use 3v3 ttl !!!
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.
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.
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.
