Enabling ttyO4 with DTR/DSR/RTS without the capemgr

I just upgraded to kernel 3.14.4 and have now run headfirst into the lack of capemgr. I had a nice DTS overlay file to enable ttyO4 with DTR/DSR/CTS and that’s now of course useless. Not only that, but the dts files in https://github.com/RobertCNelson/dtb-rebuilder.git for ttyO4 are quite different. Is there any documentation for this stuff or does anyone have a DTS that includes the modem control signals?
Thorsten

The thing I don’t understand is why this stuff has to be so complicated. I understand that the device tree is necessary to be able to support the thousands of ARM SoC and boards, and that that’s going to be complicated, but the HW for the BBB is fixed. Would it be possible to start with a simple file that lists the ~80 I/O pins of the BBB and next to each one has a little selector for which of the ~8 possible functions one would like to enable for this pin; and then compile this file into a DTS? It seems to me that a flat file like this is something anyone can grok and edit. The DTS files require hours of research and tinkering…
Thorsten

Have a look at this thread How to make BBB pins work after Ubuntu Trusty install?
specifically the post by Pierre Kancir https://github.com/khancyr/dtb-rebuilder/wiki - it might help you.
There is yet another change coming soon, as Robert indicated in the above posts.

good luck

Jan

Make sure the ttyO4 driver is loaded via the device-tree (use the
dtb-rebuilder if needed), and setup the pin multiplexing with the
installed-by-default "universal" overlay. The intent is to provide
user-mode control of pin multiplexing so you should be able to enable
just the Rx/Tx pins or whatever combination of data and handshake pins
are needed for your application.

You can use config-pin to setup the I/O pin multiplexing (just run
config-pin -h if you need instructions), or you can set a default pin
mode in a custom overlay if you want the settings to take place earlier
in the boot process. An example of using the default pinmux mode can be
found in the HDMI dtsi, which sets the pins to default to HDMI mode (but
they can still be changed using config-pin after boot, give it a try):

https://github.com/beagleboard/linux/blob/3.14/arch/arm/boot/dts/am335x-boneblack-nxp-hdmi-audio.dtsi#L12

Make sure the ttyO4 driver is loaded via the device-tree (use the
dtb-rebuilder if needed), and setup the pin multiplexing with the
installed-by-default “universal” overlay. The intent is to provide
user-mode control of pin multiplexing so you should be able to enable
just the Rx/Tx pins or whatever combination of data and handshake pins
are needed for your application.

Hello Charles,

I am about in the same situation. As far as I have understood the “installed-by-default ‘universal’” overlay is bound into the Kernel. Am I right?
In that case, I see that the one bound into Robert’s latest builds is intended for BB-Black, and exports all pins that are not HDMI and not eMMC. Also right?
However, I want to run the 3.14 on BB-White, and am in special need for P8.03 P8.04 and P8.05, which are not exported as they are eMMC on the BB-Black.
What is your recommendation for this situation?

Cheers, Guenter

IIRC, on a 'White U-Boot should be loading a different device tree
without the HDMI and eMMC sections included. Even on a 'Black you can
handle the eMMC pins just like the HDMI (don't have the eMMC hard-code
the pinmux values, but use a default pinmux-helper setting instead).

This wasn't done for eMMC on the 'Black because of the potential for
corrupting data. If a ham-fisted user switches some HDMI pins to the
wrong mode, the video display might become unusable, but do the same
thing with an eMMC pin and you're almost certainly looking at serious
data corruption.

Anyway, you'll need to fold the eMMC pinmux pins into the 'bone (white)
overlay and you can then use config-pin to setup multiplexing as
desired. This hasn't been implemented yet mostly due to a lack of time
(and a focus more on moving forward with the 'Black than legacy support
for the 'White). Send a pull-request if you get this working and it can
be added to the default kernel builds.

I don’t see how to make this stuff work… I used dtb-rebuilder to produce the provided DTB with ttyO4:

ls -ls /boot/dtbs/uname -r/tty

88 -rw-r–r-- 1 root root 86762 Dec 26 21:37 /boot/dtbs/3.14.4.1-bone-armhf.com/am335x-boneblack-ttyO1.dtb
88 -rw-r–r-- 1 root root 86762 Dec 26 21:37 /boot/dtbs/3.14.4.1-bone-armhf.com/am335x-boneblack-ttyO2.dtb
84 -rw-r–r-- 1 root root 85197 Dec 26 21:37 /boot/dtbs/3.14.4.1-bone-armhf.com/am335x-boneblack-ttyO4.dtb
84 -rw-r–r-- 1 root root 85197 Dec 26 21:37 /boot/dtbs/3.14.4.1-bone-armhf.com/am335x-boneblack-ttyO5.dtb
84 -rw-r–r-- 1 root root 85077 Dec 26 21:37 /boot/dtbs/3.14.4.1-bone-armhf.com/am335x-bone-ttyO1.dtb
84 -rw-r–r-- 1 root root 85077 Dec 26 21:37 /boot/dtbs/3.14.4.1-bone-armhf.com/am335x-bone-ttyO2.dtb
84 -rw-r–r-- 1 root root 85077 Dec 26 21:37 /boot/dtbs/3.14.4.1-bone-armhf.com/am335x-bone-ttyO4.dtb
84 -rw-r–r-- 1 root root 85077 Dec 26 21:37 /boot/dtbs/3.14.4.1-bone-armhf.com/am335x-bone-ttyO5.dtb

I edited uEnv.txt to set the dtb:

cat /boot/uboot/uEnv.txt

dtb=am335x-boneblack-ttyO4.dtb
uenvcmd=run findmmc1; run findmmc0; if run loaduimage; then run loadfdt; run mmcboot; fi;
optargs=fixrtc capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
findmmc1=if test $board_name = A335BNLT; then setenv mmc1 1; else setenv mmc1 0; fi
findmmc0=setenv mmcdev 0; mmc dev ${mmcdev}; if mmc rescan; then setenv mmc0 1; else setenv mmc0 0; fi
mmcroot=/dev/mmcblk0p2 rw
loadfdt=ext4load mmc ${mmcdev}:2 ${fdtaddr} /boot/dtbs/${fdtfile}
loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot /dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi

I don’t see any /dev/ttyO4 appearing after a reboot:

ls /dev/ttyO*

/dev/ttyO0 /dev/ttyO1

I don’t see how to figure out whether uboot loaded the proper dtb, dunno where that ends up in any log file. Dunno how to troubleshoot this any further.

Anything in dmesg?

About? I don’t see any errors or so.
`

dmesg | egrep tty

[ 0.000000] Kernel command line: console=ttyO0,115200n8 fixrtc capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait fixrtc
[ 2.525915] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88, base_baud = 3000000) is a OMAP UART0
[ 3.361270] console [ttyO0] enabled
[ 3.372171] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89, base_baud = 3000000) is a OMAP UART1
[ 8.610436] usb 2-1: pl2303 converter now attached to ttyUSB0
`

Sorry, that was all I had. I don't know how to make post-capemgr stuff work, either (and barely understand how to make capemgr things work!).

I don't see how to make this stuff work... I used dtb-rebuilder to produce
the provided DTB with ttyO4:

# ls -ls /boot/dtbs/`uname -r`/*tty*
88 -rw-r--r-- 1 root root 86762 Dec 26 21:37
/boot/dtbs/3.14.4.1-bone-armhf.com/am335x-boneblack-ttyO1.dtb
88 -rw-r--r-- 1 root root 86762 Dec 26 21:37
/boot/dtbs/3.14.4.1-bone-armhf.com/am335x-boneblack-ttyO2.dtb
84 -rw-r--r-- 1 root root 85197 Dec 26 21:37
/boot/dtbs/3.14.4.1-bone-armhf.com/am335x-boneblack-ttyO4.dtb
84 -rw-r--r-- 1 root root 85197 Dec 26 21:37
/boot/dtbs/3.14.4.1-bone-armhf.com/am335x-boneblack-ttyO5.dtb
84 -rw-r--r-- 1 root root 85077 Dec 26 21:37
/boot/dtbs/3.14.4.1-bone-armhf.com/am335x-bone-ttyO1.dtb
84 -rw-r--r-- 1 root root 85077 Dec 26 21:37
/boot/dtbs/3.14.4.1-bone-armhf.com/am335x-bone-ttyO2.dtb
84 -rw-r--r-- 1 root root 85077 Dec 26 21:37
/boot/dtbs/3.14.4.1-bone-armhf.com/am335x-bone-ttyO4.dtb
84 -rw-r--r-- 1 root root 85077 Dec 26 21:37
/boot/dtbs/3.14.4.1-bone-armhf.com/am335x-bone-ttyO5.dtb

I edited uEnv.txt to set the dtb:

# cat /boot/uboot/uEnv.txt
dtb=am335x-boneblack-ttyO4.dtb

Didn't you say you're using a BeagleBone (White) and not the 'Black?

uenvcmd=run findmmc1; run findmmc0; if run loaduimage; then run loadfdt;
run mmcboot; fi;
optargs=fixrtc capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
findmmc1=if test $board_name = A335BNLT; then setenv mmc1 1; else setenv
mmc1 0; fi
findmmc0=setenv mmcdev 0; mmc dev ${mmcdev}; if mmc rescan; then setenv
mmc0 1; else setenv mmc0 0; fi
mmcroot=/dev/mmcblk0p2 rw
loadfdt=ext4load mmc ${mmcdev}:2 ${fdtaddr} /boot/dtbs/${fdtfile}
loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv
mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot
/dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi

I don't see any /dev/ttyO4 appearing after a reboot:

# ls /dev/ttyO*
/dev/ttyO0 /dev/ttyO1

I don't see how to figure out whether uboot loaded the proper dtb, dunno
where that ends up in any log file. Dunno how to troubleshoot this any
further.

You can poke around in /proc/device-tree/... to see what's in the "live"
device tree. That should help figure out if you're loading the expected
file.

Also, if you've got a USB serial cable, you can pause the startup
sequence and poke around a bit with U-Boot to see what dtb file it's
trying to load.

Didn’t you say you’re using a BeagleBone (White) and not the 'Black?

Nope. this is also posted with the 'Black tag. dl4mea interjected a message about the 'White.

I don’t see how to figure out whether uboot loaded the proper dtb, dunno
where that ends up in any log file. Dunno how to troubleshoot this any
further.

You can poke around in /proc/device-tree/… to see what’s in the “live”
device tree. That should help figure out if you’re loading the expected
file.

Do you have any suggestions for what to look for? I tried setting the model to something I’d recognize, e.g.:

`

egrep -i model /root/dtb-rebuilder/src/arm/am335x-boneblack-ttyO4.dts

model = “TI AM335x BeagleBone Black w/ttyO4”;
`

but then I see:

`

more /proc/device-tree/model

TI AM335x BeagleBone
`

which is not even what the std BBB dts has:
`

egrep -i model /home/tve/dtb-rebuilder/src/arm/am335x-boneblack.dts

model = “TI AM335x BeagleBone Black”;

`

so it seems like one has to go through the whole serial boot console mess to debug any of this :frowning:

I attached a serial cable, but it doesn’t say anything useful. I guess it’s too much asking for uboot to log what it’s doing…
`

SD/MMC found on device 1
reading uEnv.txt
678 bytes read in 5 ms (131.8 KiB/s)
Importing environment from mmc …
gpio: pin 55 (gpio 55) value is 1
Checking if uenvcmd is set …
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd …
mmc_send_cmd : timeout: No status update
Card did not respond to voltage select!
mmc0(part 0) is current device
Card did not respond to voltage select!
Card did not respond to voltage select!
** Bad device mmc 0 **
3574064 bytes read in 620 ms (5.5 MiB/s)
31547 bytes read in 74 ms (416 KiB/s)
Booting from mmc …
Kernel image @ 0x80200000 [ 0x000000 - 0x368930 ]

Flattened Device Tree blob at 80f80000

Booting using the fdt blob at 0x80f80000
Using Device Tree in place at 80f80000, end 80f8ab3a
`

After some debugging I found…

  • I have to set fdtfile=am335x-boneblack-ttyO4.dtb in uEnv.txt, not dtb=…
  • uBoot loads the dtbs from /boot/dtbs, not from /boot/dtbs/uname -r, which is where the dtb-rebuilder drops them
    I have uBoot 2013.07, maybe some of the info pertains to a newer version. Not sure I want to go through the trouble of finding a newer version and trying that… Dunno how to determine the uboot version on a running system without rebooting with attached serial…
    I hope this info helps someone else… But if you’re at this level expect to waste hours and hours troubleshooting…

Interesting, and good to know. I somehow got a 2015 version of uboot onto my eMMC (I was building my own kernel and putting it on an SD card, how the eMMC version got changed, I'll never know). I know the uEnv.txt line for disabling capes works with that uBoot, no idea if I'd be able to load a whole new dtb that way.

Sorry, was home with family over Christmas break away from the internet.

I changed this in July-August 2014, so if your image is prior to that:

fdtfile=

post

dtb=

The full spec of this change is documented here:

http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

Regards,