BBB-RevC: Enable expansion header UARTs under Arch Linux ARM

This forum is for supported devices using an ARMv7 Texas Instruments (TI) SoC.

BBB-RevC: Enable expansion header UARTs under Arch Linux ARM

Postby mjgray » Thu Oct 06, 2016 4:34 am

To anyone it may concern,

I am attempting to enable UART1 (serial port #1) on expansion header P9 of a revision C Beagle Bone Black running Arch Linux ARM. Up to this point in time, all attempts that I have made have been unsuccessful. I am hoping that someone on this forum may be able to assist me in accomplishing this task. Below I have provided information about my Beagle Bone Black system.

System Information:
System: Beagle Bone Black - Revision C
Manufacture: element14
Power Source: ~5V DC 2.4A
File System Location: 4GB microSDHC Class 2 card
Operating System: Arch Linux ARM
Kernel Version: 4.7.6-1-ARCH (obtained via terminal command “uname -r”)
Graphical User Interface: XFCE version 4.12

The operating system was downloaded from https://archlinuxarm.org/about/downloads (Name: ARMv7 AM33x BeagleBone File: ArchLinuxARM-am33x-latest.tar.gz ) and installed using the instructions found at https://archlinuxarm.org/platforms/armv7/ti/beaglebone-black

So far I have attempted to enable UART1 using the directions provided at the following links: (I modified these instructions slightly during my attempts, as some of them cannot be followed exactly)
http://beaglebone.cameon.net/home/serial-ports-uart
https://archlinuxarm.org/forum/viewtopic.php?f=48&t=8603&p=46382&hilit=uart#p46382
https://billwaa.wordpress.com/2014/10/13/beaglebone-black-enable-all-uart-ports-at-boot/ (I could not complete these instructions as the file that I had did not match that which was described)

The following is how I verify that these attempts did not work:
- Attempting to connect to ttyO1 or ttyS1 using PuTTY with the default serial connection settings. (I check ttyS1 because after entering the command “dmesg | grep tty” in the terminal I discovered the following “Warning: Your ‘console=ttyO0’ has been replaced by ‘ttyS0’”. I suspect this might be the case with the rest of the UARTs)
- Checking to see if ttyO1 exists in /dev/
- Checking to see if ttyO1 or ttyS1 appear in the results from entering the following terminal command “dmesg | grep tty”

Thank you for taking the time to assist me with this matter. Please let me know if you have any questions.

Regards,


mjgray
mjgray
 

Re: BBB-RevC: Enable expansion header UARTs under Arch Linux

Postby summers » Thu Oct 06, 2016 9:02 am

the ttyO0 --> ttyS0 is a known issue, due to driver change. It shouldn't cause problems, but better to change TI uboot env varaiables ...

So all serial ports should come up as the /dev/ttySn - so check which of those exist.

the chip in the BBB can have up to 6 UARTs, but if I racall only a few are wire up. On the male pins believe its /dev/ttyS0 that is wired up - but would need to check at home.

Now /dev/ttyS0 will be grabbed automatically by the console. So if you attach a UART to the pins with the right voltage (3.3V), when you power up the BBB you should see a whole lot of messages, firstly uboot coming up, then the kernel, then logging. You should be able to log on late in the process via the UART.

So you problem could get the login process, I guess getty, is grabbing the UART to use as a terminal ....

Anyway check /dev/ttySn and see what exists, by drilling down under /sys (I think maybe /proc) you can see which exist. And see which is best to use. May just be simplest to switch the console away from ttyS0, and stop getty running on ttyS0, then you could use that ....

Hope this helps.

David

P.S. Oh yes, forgot to say - I've never tried using the UART on the female pins - which IIRC is UART1. My serial cable is female on the end. When I get time (unusual) I'll see if I can wire up the connection (somewhere think I have some loose pins, so should be able to do female on both sides, with a male-male pin ....)
Last edited by summers on Mon Oct 10, 2016 9:25 am, edited 1 time in total.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: BBB-RevC: Enable expansion header UARTs under Arch Linux

Postby mjgray » Thu Oct 06, 2016 7:51 pm

Hi David,

Thank you for responding to my post.

Item 1: $this->bbcode_second_pass_quote('summers', 't')he ttyO0 --> ttyS0 is a known issue, due to driver change. It shouldn't cause problems, but better to change TI uboot env varaiables ...
How would I change the TI uboot env variables? To be honest I am not very experienced with either Arch Linux or the Beagle Bone Black. If you could walk me through this I would really appreciate it.

Item 2: $this->bbcode_second_pass_quote('summers', 'S')o all serial ports should come up as the /dev/ttySn - so check which of those exist.
The following are all present in the /dev/ directory: ttyS0, ttyS1, ttyS2, ttyS3, ttyS4, and ttyS5
However, when I attempt to connect to any of these UARTs using PuTTY, I receive the following error captured in the screenshot below. Again I am using the default serial connection settings in PuTTY. The only thing that I change is ttySn.
Screenshot1.png

In debian, with UART1 enabled, I am able to connect to ttyO1 using PuTTY just fine. Could this be a problem with PuTTY on Arch Linux ARM? Is there a built in feature in Linux that could be used to verify that these UARTs are working?

Item 3: $this->bbcode_second_pass_quote('summers', 'M')ay just be simplest to switch the console away from ttyS0, and stop getty running on ttyS0, then you could use that ....
In this application It is best that I work with the UARTs on expansion header p9.

Again, Thank you for taking the time to assist me with this issue.

Regards,


mjgray
mjgray
 
Top

Re: BBB-RevC: Enable expansion header UARTs under Arch Linux

Postby summers » Fri Oct 07, 2016 10:43 am

Just starting to dig into it. Its interesting - look into the device tree:

$this->bbcode_second_pass_code('', 'cat /proc/device-tree/ocp/seria*')

the address are very different ttyS0 @ serial@44...
Whilst the others are at serial@48 ....

So looks like the UART are wired up differently. The kernel only seems to be bringing up ttyS0; but knows of the others in /sys/class/tty/ttyS*

ttyS1-S5 seem to be set up in

$this->bbcode_second_pass_code('', '/sys/devices/platform/serial8250/tty')

So its the serial8250 omap driver for all - which is good
So digging some more
Last edited by summers on Fri Oct 07, 2016 4:43 pm, edited 1 time in total.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: BBB-RevC: Enable expansion header UARTs under Arch Linux

Postby summers » Fri Oct 07, 2016 11:47 am

OK the serial ports are disabled in the device tree:

http://lxr.free-electrons.com/source/arch/arm/boot/dts/am33xx.dtsi

However on boot ttyS0 is enabled but S1-S5 are not:

$this->bbcode_second_pass_code('', 'cat /proc/device-tree/ocp/serial*/status')

So we'll need to change that bit in the device tree I guess. Now have only tangentially worked with the device tree. Know we can reset parts of it in uboot - and this is bound to be one of those things. So right code in /boot/uEnv.txt should do it ...

So start by reading the uboot manual re device tree.

ALso slightly worried that the BBB ref manual says you only get the GPIO pin on P9 to be UART1 in Mode0. Now how that mode is set isn't clear to me either. Must be a cpu function. Anyway I'd hazzard a guess that mode 0 is default - so suspect main issue is the device tree ...

And check this link

https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/device-tree-overlays

As seems apt on device tree overlays ....

And this code seems to work - does device tree overlays via the BBB capemgr:

$this->bbcode_second_pass_code('', 'echo BB-UART1 > /sys/devices/platform/bone_capemgr/slots')

Gives me

$this->bbcode_second_pass_code('', '[324233.824185] bone_capemgr bone_capemgr: part_number 'BB-UART1', version 'N/A'
[324233.831749] bone_capemgr bone_capemgr: slot #4: override
[324233.837260] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[324233.844393] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-UART1'
[324233.881999] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 190, base_baud = 3000000) is a 8250
[324233.899606] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-UART1-00A0.dtbo' loaded; overlay id #0
')

ANd then running on the BBB

$this->bbcode_second_pass_code('', 'screen /dev/ttyS1 115200')

and it works. I havn't plugged a cable in to see if I can get data across it - but looks good.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: BBB-RevC: Enable expansion header UARTs under Arch Linux

Postby mjgray » Sat Oct 08, 2016 5:47 am

Thank you very much David!

This issue is resolved.

Entering this command in the terminal enables UART1:
$this->bbcode_second_pass_quote('summers', '[')code]echo BB-UART1 > /sys/devices/platform/bone_capemgr/slots[/code]


It turns out that PuTTY requires root privileges in order to access UART1.

What gave me the clue to this was the command:
$this->bbcode_second_pass_quote('summers', '[')code]screen /dev/ttyS1 115200[/code]

I received an error that the "screen" command did not exist. Therefore I decided to look "screen" up under packages on the Arch Linux website: https://www.archlinux.org/packages/extra/x86_64/screen/
I installed this package and ran the above command again. I was able to transmit and receive over UART1 using loopback wiring (jumpering pins 24 and 26).
I than decided to try to use PuTTY on the root account. This eliminated the error I was getting. Therefore, by logging into the root account through the graphical user interface, I am able to access UART1 with PuTTY.

One last item regarding this issue:
I added the line above "echo BB-UART1 > /..." to the "uEnv.txt" file in the /boot/ directory, however UART1 was not enabled at boot. How can UART1 be set to be enabled at boot?

Regards,


mjgray
Last edited by mjgray on Sat Oct 08, 2016 5:18 pm, edited 1 time in total.
mjgray
 
Top

Re: BBB-RevC: Enable expansion header UARTs under Arch Linux

Postby summers » Sat Oct 08, 2016 1:00 pm

the /boot/uEnv.txt file is a file read by uboot for setting up uboot enviroment variables. These variables control how uboot boots up the kernel. Now we could hardwire into uboot to change the device tree, but as the BBB has the capemgr code in the kernel it allows modification of the device tree - this is a good fix for BBB as you can add different capes, and so the hardware is configerable. Don't know what RPi uses, but I would guess it would be good if they used the same.

Now IIRC on the adafruit link it said how to have devicetree overlays automatically loaded by the kernel - IIRC it was something you passed to the command line. So you would need to look into how the kernel command line is set up in uboot, and via its enviroment variables - and then modify to make sure the right extra bit is added ...

Only half a story here I know - need to get on with some other work right now, I'll come back to thios if I have time.

David
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: BBB-RevC: Enable expansion header UARTs under Arch Linux

Postby summers » Mon Oct 10, 2016 10:39 am

Quick search, and looks like you'll need to add to the kernel command line:

$this->bbcode_second_pass_code('', 'bone_capemgr.enable_partno=BB-UART1')

You'll need to know how commands get added to the kernel comand line via uboot env varaibles, e.g. start looking here:

https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/uboot-beaglebone/0001-arch-linux-arm-modifications.patch#L33

looks like the uboot env varaible you need to set is $this->bbcode_second_pass_code('', 'cape_enable') so in /boot/uEnv.txt try something like:

$this->bbcode_second_pass_code('', 'cape_enable=bone_capemgr.enable_partno=BB-UART1')

What is slightly annoying is that the capemgr is clearly a patch to the standard kernel - so its not the way that it is seen as setting up the device tree with reconfigurable hardware from the main linux kernel. Does make me suspect that preferred is rewriting the device tree in uboot. Now the device tree stub shows with pins you need to set and to what. So when I get bored I'll see if I can do the uboot commands that rewrite the device tree, or actually the pins, to the values for a UART1.
Last edited by summers on Mon Oct 10, 2016 4:38 pm, edited 1 time in total.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: BBB-RevC: Enable expansion header UARTs under Arch Linux

Postby mjgray » Mon Oct 10, 2016 4:25 pm

That did it.

UART1 is enabled at boot now.

Thank you.
mjgray
 


Return to Texas Instruments (TI)

Who is online

Users browsing this forum: No registered users and 3 guests