BeagleBone UARTs and uBoot

[n1ywb]

I just got my shiny new BeagleBone and I'm trying to use the uarts and
not meeting much success.

I have tried to use minicom to open several of the uarts under /dev/
ttyO1 etc. At first I tried using my null modem cable to my PC
(through a level converter) but I wasn't getting any comms, so then I
tried my edge-detecting logic probe and I'm not getting any signal
from the TXD pins. I've triple checked to make sure I'm on the right
pins on the right header.

Someone mentioned the pinmux issue. I was hoping that since the pins
are named UART1_TXD etc that I would not have to muck with the mux
config. In any event I can't seem to find ANY bone specific info on
changing pinmux-ing. Bear in mind that while I am a software engineer
by trade I am new to the whole beagle world. I have searched and
searched and gleaned and gleaned and I think I need to look at the
bone uBoot sources to check or change the pinmux but I can't for the
life of me find it. Could somebody please provide a URL?

Has anybody else had success with the Bone UARTs? Could you please
describe your steps to win?

A howto on the subject of changing pinmux settings including steps to
get and build uboot would be radical.

Thanks,
Jeff

[Jacek Radzikowski]

check /var/log/messages for ttyUSBx ports created when you connect the
USB cable.
BeagleBone has a serial to usb converter built in, so all you need to
do is to connect the board with USB cable and use the board's usb tty.

j.

> --
> You received this message because you are subscribed to the Google Groups "Beagle Board" group.
> To post to this group, send email to beagl...@googlegroups.com.
> To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
>

--
Given a choice between two theories, take the one which is funnier

[n1ywb]

Thanks Jacek but I'm trying to talk to a peripheral, I got the console
working in about 5 minutes :)

I just talked to jkridner on #beagleboard and he suggested poking /sys/
kernel/debug/omap_mux/uart... Now I'm just trying to figure out what
the magic incantations to write to those files are ;)

On Dec 12, 10:56 pm, Jacek Radzikowski <jacek.radzikow...@gmail.com>
wrote:

> > For more options, visit this group athttp://groups.google.com/group/beagleboard?hl=en.

[Jacek Radzikowski]

Ah, ok. I understood that you had problems with getting the BB console to work.

j.

> For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.

[n1ywb]

I whipped up a python script to set the pinmuxes the way I wanted and
now I'm getting data!!! Yay! Now I can go to bed.

root@beaglebone:~# cat mux.py
#!/usr/bin/python
import os
import logging

DDR_IN = (1 << 5)
DDR_OUT = (0 << 5)
PULL_R_UP = (1 << 4)
PULL_R_DOWN = (0 << 4)
PULL_R_EN = (1 << 3)
PULL_R_DIS = (0 << 3)

uart1_pin_mux = [
('uart1_rxd', (0 | DDR_IN)),
('uart1_txd', (0)),
]

logging.basicConfig(level=logging.DEBUG)

for (fname, mode) in uart1_pin_mux:
logging.debug("%s = %s" % (fname, mode))
with open(os.path.join('/sys/kernel/debug/omap_mux', fname), 'wb') as
f:
f.write("%X" % mode)

On Dec 13, 12:15 am, Jacek Radzikowski <jacek.radzikow...@gmail.com>
wrote:

[Charlie Fullerton]

Very interesting.. Yet I don't understand pin muxing enough to decipher
your code.. Can you add some notes or explanations?

Thanks!

[n1ywb]

Each pin has a 32 bit word in memory which controls it's mode and mux
settings. The mode is the first 3 bits, the 4th bit is the pull-up-
down resistor enable bit, and the 5th bit is the pull-direction bit,
i.e. pull up or pull down, and the 6th bit is direction, e.g. input or
output. When you open the appropriate file in the omap_mux dir and
write to it, the kernel reads your string, interprets it as a hex
number, and writes that number to the appropriate location in memory.
It knows what the correct location for each file is, in fact if you
cat the file it shows you the memory address. So basically all you do
is take the mode, bitwise-or it with whatever flags you like, convert
it to the a hex string, and write it to the file.

(1 << 3) takes the number 1 and bit-shifts it 3 places to the left, so
b00001 becomes b01000. Then by binary-or-ing one or more of those
values together you can create a bitmask in a way that clearly
communicates what's going on. You could just as easily do the math in
your head and say pinmux = 0x00000024 or whatever but it's much harder
to see what's going on there.

5 4 3 210
pinmux bits = W X Y ZZZ where

W = data direction bit
X = pull up/down bit
Y = pull enable
ZZZ = 3 bit mode number, 0-7

I more or less copied this code out of the bone uboot source file
board/ti/am335x/mux.c, ported it to python, made it write to debugfs
instead of directly to memory, and changed the bit names for clarity.

On Dec 13, 10:00 am, Charlie Fullerton <cwfullerton21...@gmail.com>
wrote:

[MariaM]

Hi, n1ywb I see that u are expert on this, could u give me some help
as I need to use UART1
I'me running code in nodejs using serial port node module (npm install
serialport)

var SerialPort = require("serialport").SerialPort ;
var serialPort = new SerialPort('/dev/ttyO1' , {baudrate : 9600} );

serial is successfully created, now writing

serialPort.write("TEST");

I get no data on header P9 pin 24 ( UART1_TX)

Maybe the mux is not correct configured for this ttyO1 so this data is
writed but does not goes to the P9 pin 24 ( UART1_TX)

Can u give me some lights to solve this

Tanks