# FreeBSD 10.3 on beaglebone black: how to use all UART?



## coredumb (Jul 13, 2016)

Hi,
I'm using FreeBSD on various hardware including some Beaglebone blacks, which is great and runs smoothly.
A BBB sports four UARTs, spread over the it's expansion port headers P8 and P9, one of which via pins GPIO0_30 and GPIO0_31 on header P9. Unfortunately (or maybe because I'm too unexperienced) this Serial4 has no corresponding device under /dev to let me use it with e.g. minicom or ntpd.

So, my question is: how do I create serial devices to hardware ports on that computer? In FreeBSD Handbook there are a few chapters covering serial port setup. They care about normal PC hardware all the time. I got some forwarding pointers though, stty(1) and /etc/ttys to name two. If I grep uart in /var/run/dmesg.boot, I only see one (uart0) listed. Why's that? Where are the remaining three?

Can anyone please push me in the right direction?

Thanks in advance!


----------



## Phishfry (Jul 13, 2016)

Have you checked out `gpioctl -lv` on the pins to see the state?


----------



## Phishfry (Jul 14, 2016)

The reason I ask is there are pin mux states and you need to check out how they are defined by default then proceed from there.
Arm uses Flattened Device Tree for hardware and DTB and DTS describe the hardware.

The first few paragraphs explain the way things work in a simple fashion. Also covers serial ports.
https://www.bidouilliste.com/blog/2015/11/28/Porting-FreeBSD-to-a-new-ARM-Board-Part-2/


----------



## coredumb (Jul 14, 2016)

Oh wow, now I feel very much pushed   Thanks Phishfry for the numerous pages to study. I wasn't aware of the complexity behind this matter, though. The FDT thing seems to be a OS independent framework to tackle the rise of lots of Embedded Systems with the lack of non-standard hardware features. I am still asking myself why BBB hasn't yet all of it's hardware capabilities described and established (in the device tree) since it is quite some time on the market. The only reason against that I can think of is multiplexing several features on gpios.


----------



## coredumb (Jul 14, 2016)

Some progress here: to activate an additional UART, I dug into this Flattened Device Tree thing. What I've found is a binary representation (.dtb) of a text version (.dts) file that holds information about physically available hardware(features) for the kernel to grab and use at boot time. It resides under `/boot/dtb/beaglebone-black.dtb` on my 10.3 system. To convert it into a readable format, `dtc -I dtb -O dts /boot/dtb/beaglebone-black.dtb  -o ~/beaglebone-black.dts` did the trick.
The text version holds a lot of stuff, a serial port section looks like this:

```
serial@48024000 {
    compatible = "ti,ns16550";
    reg = <0x48024000 0x1000>;
    reg-shift = <0x2>;
    interrupts = <0x4a>;
    interrupt-parent = <0x1>;
    clock-frequency = <0x2dc6c00>;
    uart-device-id = <0x4>;
    status = "disabled";
};
```
I did the obvious thing to enable it. After the last line was gone for uart4, I used the above mentioned command in reverse to write a binary file back where the kernel finds it at  boot time. Which it did.

First surprise after reboot was that FreeBSD didn't enumerate all enabled uart according to this .dtb. Instead, it starts with 0 and goes on incrementing. My enabled uart4 showed up as /dev/ttyu1{.init|.lock} and cuau1{.init|.lock} under /dev. Not much of a problem.

Secondly, it doesn't work. I connected it to `minicom -D /dev/cuau1 -8 --baudrate 9600` and no flow control, but without success. The counterpart was minicom on a different system with a sparkfun ftdi adapter on 3.3 V levels as a known working unit. I played with a lot of settings, even switched RX and TX lines. Not a single byte travelled over the wires.

I've no idea what to do next except reading more man pages


----------



## Phishfry (Jul 14, 2016)

What was the pin states for your comm4 pins when you checked gpioctl?

Gonzo has added many of the BBB features. Perhaps you could contact him. I have a feeling if the port was available it would work. He even has a touchscreen LCD supported for BBB.
http://kernelnomicon.org/?p=534

The Arm mailing list would also be a good place to dig in deeper.


----------



## coredumb (Jul 14, 2016)

Phishfry said:


> What was the pin states for your comm4 pins when you checked gpioctl?



Thanks for coming back to this. I ran the command earlier, but wasn't able to figure out the mapping between the output list and the expansion header pinout in BBB System Reference Manual (Rev. A5.3), where GPIOs are listed like gpio0[31] or GPIO3_20. So there seems to be some sort of block-and-index scheme. The index never exceeds 31, clearly being a 5-bit number. This in no way (I can see) maps to

```
root@beaglebone:~ # gpioctl -lv
pin 00:    0    gpio_0<>, caps:<IN,OUT,PU,PD>
:
pin 06:    0    gpio_6<>, caps:<IN,OUT,PU,PD>
pin 07:    0    gpio_7<IN,PD>, caps:<IN,OUT,PU,PD>
:
pin 98:    0    gpio_98<>, caps:<IN,OUT,PU,PD>
pin 99:    0    gpio_99<>, caps:<IN,OUT,PU,PD>
pin 100:    0    gpio_100<>, caps:<IN,OUT,PU,PD>
pin 101:    0    gpio_101<>, caps:<IN,OUT,PU,PD>
:
pin 127:    0    gpio_127<>, caps:<IN,OUT,PU,PD>
```
which is a linear list and, by the way, is a non-BBB specific tool. The manpage doesn't cover this BBB-centric question. Also GPIO doesn't help here. It's manpage scratches slightly _device a10_gpio_, an ARM related GPIO controller, but that's it. More research required, which I haven't done, yet.



> Gonzo has added many of the BBB features. Perhaps you could contact him. I have a feeling if the port was available it would work. He even has a touchscreen LCD supported for BBB. http://kernelnomicon.org/?p=534



Yeah, maybe this could help. I ran over his web page earlier, too, but only now realized, that he's the author of gpioctl. 



> The Arm mailing list would also be a good place to dig in deeper.


Good idea. Thanks again for your help and suggestions!!


----------



## coredumb (Jul 15, 2016)

coredumb said:


> This in no way (I can see) maps to
> 
> ```
> root@beaglebone:~ # gpioctl -lv
> ...



Now, after reading this web page, things brighten up a bit, it provides the missing link. There a multiple GPIO _controllers_ on a BBB, not a single one. Yesterday, when editing `/boot/dtb/beaglebone-black.dts` as part of the Flattened Device Tree, I found this fragment
	
	



```
gpio {
    #gpio-cells = <0x3>;
    compatible = "ti,gpio";
    gpio-controller;
    reg = <0x44e07000 0x1000 0x4804c000 0x1000 0x481ac000 0x1000 0x481ae000 0x1000>;
    interrupts = <0x60 0x61 0x62 0x63 0x20 0x21 0x3e 0x3f>;
    interrupt-parent = <0x1>;
    linux,phandle = <0x3>;
    phandle = <0x3>;
};
```
indicating (to me) that there's one single controller. This gets backed by the fact that there's only one listed here: 
	
	



```
root@beaglebone:~ # ls -l /dev/gpio*
crw-------  1 root  wheel  0x1d Jul 14 18:08 /dev/gpioc0
```
Okay, the web page explains that each controller carries 32 GPIOs. They're staggered in the way, that every 32 IOs the next controller comes into play when running through the IOs starting at zero.

Now I can identify UART4_RxD/gpio0_30 as GPIO 30 and UART4_TxD/gpio0_31 as GPIO 31 on the list by`gpioctl -lv`. GPIO30 happens to be an input, which is good, 31 was an input too, which I turned into an output to be a TxD by `gpioctl -c 31 OUT`. Although everything looks hunky-dory now, minicom can't send or receive anything on this port. And after reboot 31 it's an input pin again, so a permanent solution's still missing. More research required ...


----------



## Phishfry (Jul 15, 2016)

I used a script and did an on-off cycle and used a LED to the pins to figure it out myself. I have only dabbled in the topic. Had to see it work and then it was like -Now what-? I bought some thermocouples and related gear and have not gotten to it yet.
I have a RTC module for my rpi2 but gave up on that too easily.

Are you using COM1 thru COM3 currently and need COM4?
What is your project, if you don't mind me asking.


----------



## coredumb (Jul 16, 2016)

Phishfry said:


> Are you using COM1 thru COM3 currently and need COM4?
> What is your project, if you don't mind me asking.



Oh, no worries ... The BBB is supposed to become a time server (s1) with the help of a GPS and a DCF77 antenna modules. UART0 (J1) is also in use while connected to a text terminal (getty console). And some ideas in the direction of remote  programming of microcontrollers via remote serial interface (on a different BBB).

Regarding those spare UARTs, right in the beginning everything looked quite promising. Some howtos for Linux-powered RasPi or Beagles with recent OS releases I read along the way had like two commands: to change the mapping (those BBB GPIO modes) and to activate the com ports.
In my case, I spent lots of hours tweaking the FDT descriptions alone on a trial-and-error basis. With dozens of reboots to bring changes into effect, of course. Literally every .dts for a BBB I could find was substantially different (except those who copied from each other w/ reference and acknowledge). New keys everywhere, fancy values too. Other hierachies on file top-level or strange groupings among the uarts. No reference I could find for clarification, that would match those items on my BBB. A mess. And a very tolerant interpreter/parser ...


----------



## Phishfry (Jul 17, 2016)

From a quick glance at the uart ports I see 6 are there. One reserved as the debug console at uart0 and uart3 looks special too. So uart 1 and uart 2 should be usable along with uart 4 and uart 5.
https://billwaa.wordpress.com/2014/10/02/beaglebone-black-enable-on-board-serial-uart/

This looks like the official overlay for UART4 and 5
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-00A0.dts
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART5-00A0.dts

https://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004762.html
A patch in the last post here. 
https://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004902.html


----------



## Phishfry (Jul 17, 2016)

As you can see those mailing list posts are old. It does give you the files to investigate. I would check the source and see if these patches were already applied or if the code structure looks very different.


----------



## Phishfry (Jul 17, 2016)

I am not sure if you would merge the overlays from bb.org-overlays into your boards DTB or use the FDT overlay mechanism that Gonzo is working on.


----------



## OlivierW (May 17, 2017)

Hello,

Does anyone have successfully enabled others UART?
I'm running a BeagleBone Green with FreeBSD 12.0-CURRENT #0 r314137 and the dts file is in a format different from everything I could find on the internet.

The UART section looks like:

```
serial@44e09000 {
                        compatible = "ti,am3352-uart", "ti,omap3-uart";
                        ti,hwmods = "uart1";
                        clock-frequency = <0x2dc6c00>;
                        reg = <0x44e09000 0x2000>;
                        interrupts = <0x48>;
                        status = "okay";
                        dmas = <0x29 0x1a 0x0 0x29 0x1b 0x0>;
                        dma-names = "tx", "rx";
                        pinctrl-names = "default";
                        pinctrl-0 = <0x2d>;
                };

                serial@48022000 {
                        compatible = "ti,am3352-uart", "ti,omap3-uart";
                        ti,hwmods = "uart2";
                        clock-frequency = <0x2dc6c00>;
                        reg = <0x48022000 0x2000>;
                        interrupts = <0x49>;
                        status = "disabled";
                        dmas = <0x29 0x1c 0x0 0x29 0x1d 0x0>;
                        dma-names = "tx", "rx";
                };

                serial@48024000 {
                        compatible = "ti,am3352-uart", "ti,omap3-uart";
                        ti,hwmods = "uart3";
                        clock-frequency = <0x2dc6c00>;
                        reg = <0x48024000 0x2000>;
                        interrupts = <0x4a>;
                        status = "disabled";
                        dmas = <0x29 0x1e 0x0 0x29 0x1f 0x0>;
                        dma-names = "tx", "rx";
                };

                serial@481a6000 {
                        compatible = "ti,am3352-uart", "ti,omap3-uart";
                        ti,hwmods = "uart4";
                        clock-frequency = <0x2dc6c00>;
                        reg = <0x481a6000 0x2000>;
                        interrupts = <0x2c>;
                        status = "disabled";
                };

                serial@481a8000 {
                        compatible = "ti,am3352-uart", "ti,omap3-uart";
                        ti,hwmods = "uart5";
                        clock-frequency = <0x2dc6c00>;
                        reg = <0x481a8000 0x2000>;
                        interrupts = <0x2d>;
                        status = "disabled";
                };

                serial@481aa000 {
                        compatible = "ti,am3352-uart", "ti,omap3-uart";
                        ti,hwmods = "uart6";
                        clock-frequency = <0x2dc6c00>;
                        reg = <0x481aa000 0x2000>;
                        interrupts = <0x2e>;
                        status = "disabled";
                };
```

With dmesg, I'm getting:

```
# dmesg | grep -i uart
uart0: <TI UART (16550 compatible)> mem 0x44e09000-0x44e0afff irq 11 on simplebus0
uart0: console (115384,n,8,1)
```


I've been able to "enable" uart2, uart3 and uart4 by changing their status from "disabled" to "okay" and adding 
	
	



```
dma-names = "tx", "rx";
```
. Now in dmesg I'm getting 3 more UART:

```
# dmesg | grep -i uart
uart0: <TI UART (16550 compatible)> mem 0x44e09000-0x44e0afff irq 11 on simplebus0
uart0: console (115384,n,8,1)
uart1: <TI UART (16550 compatible)> mem 0x48022000-0x48023fff irq 12 on simplebus0
uart2: <TI UART (16550 compatible)> mem 0x48024000-0x48025fff irq 13 on simplebus0
uart3: <TI UART (16550 compatible)> mem 0x481a6000-0x481a7fff irq 14 on simplebus0
```

But I can't use them. I've wired RX and TX together and I can only use UART2 (name from BBG pinout: https://raw.githubusercontent.com/SeeedDocument/BeagleBone_Green/master/images/PINMAP_UART.png not the name from the DTS file or from dmesg).

BTW: why the BeagleBone Black/Green has its UART named from 0 to 5 and the DTS file is from 1 to 6?

Where does the values on the "dmas" line comes from? I tried to look in the 4000+ pages of the AM335x Technical Reference Manual: I could find the memory map (reg) of the UART, the interrupts numbers, but couldn't find those "dmas" lines.

What should I do to enable those UART? I would need at least UART4 (name from BBG pinout), only RX and TX, I've no use of RTS & CTS.
Where can I find up to date information about this dts file and how to understand it?

Best Regards.


----------



## aragats (May 17, 2017)

OlivierW said:


> why the BeagleBone Black/Green has its UART named from 0 to 5 and the DTS file is from 1 to 6?


Who knows why! The same is with MMC devices, do not pay attention.


OlivierW said:


> I'm getting 3 more UART . . . But I can't use them


The CPU has multiplexers at all pins, each pin may have up to 8 functions. You have to configure the corresponding pins correctly.
Here is a useful spreadsheet describing those functions.


OlivierW said:


> Does anyone have successfully enabled others UART?


I have it on my schedule, but since I'm doing it for work, I cannot switch to this task right now.


----------



## OlivierW (May 18, 2017)

Thanks a lot aragats! This spreadsheet is very helpful to find the correspondence between pin numbers and the names found with the gpioctl tool.

But I still don't understand some stuff…
If I run:

```
# gpioctl -f /dev/gpioc0 -lv
pin 00: 0       gpio_0<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 01: 0       gpio_1<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 02: 0       gpio_2<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 03: 0       gpio_3<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 04: 1       gpio_4<IN,PU>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 05: 1       gpio_5<IN,PU>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 06: 1       gpio_6<IN>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 07: 0       gpio_7<IN,PD>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 08: 0       gpio_8<IN>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 09: 0       gpio_9<IN>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 10: 1       gpio_10<IN>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 11: 0       gpio_11<IN>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 12: 0       gpio_12<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 13: 0       gpio_13<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 14: 1       gpio_14<IN,PU>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 15: 1       gpio_15<IN,PU>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 16: 0       gpio_16<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 17: 0       gpio_17<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 18: 0       gpio_18<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 19: 0       gpio_19<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 20: 0       gpio_20<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 21: 0       gpio_21<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 22: 0       gpio_22<IN,PD>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 23: 0       gpio_23<IN,PD>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 24: 0       gpio_24<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 25: 0       gpio_25<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 26: 0       gpio_26<IN,PD>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 27: 0       gpio_27<IN,PD>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 28: 0       gpio_28<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 29: 0       gpio_29<IN,PD>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 30: 1       gpio_30<IN,PU>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 31: 1       gpio_31<IN,PU>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
```

And I wire UART2 RX and TX together, I can send data with "echo 123 > /dev/cuau2" and receive it with "cat /dev/cuau2".
UART2 RX is "pin 02: 0       gpio_2<>"
UART2 TX is "pin 03: 0       gpio_3<>"

Now I'd like to try to make UART4 works.
UART4 RX is "pin 30: 1       gpio_30<IN,PU>"
UART4 TX is "pin 31: 1       gpio_31<IN,PU>"
So, I'm using:
`# gpioctl -f /dev/gpioc0 -c 30
# gpioctl -f /dev/gpioc0 -c 31`
and now I have UART4 RX/TX configured like UART2:

```
pin 02: 0       gpio_2<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 03: 0       gpio_3<>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
```
Then I wire UART4 RX/TX together, but they don't communicate.

For the working UART2, I have:

```
# stty -f /dev/cuau2
speed 9600 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb clocal
```
And I have checked the others /dev/cuau* devices and they all have the same parameters except cuau0 which is busy, but it's special as it's the console).

I've also tried the same with UART1 RX/TX ("pin 14: 0       gpio_14<>" and "pin 15: 0       gpio_15<>"), but also no success.

I'm probably missing something. Do I have something else to change in the pin mode or the DTS/DTB file?


----------



## aragats (May 19, 2017)

If you want to use DTS files, I believe you can find most of them by running
	
	



```
$ find /usr/src -name "*bone*dts*"
/usr/src/sys/gnu/dts/arm/am335x-bonegreen.dts
/usr/src/sys/gnu/dts/arm/am335x-bone.dts
/usr/src/sys/gnu/dts/arm/am335x-bone-common.dtsi
/usr/src/sys/gnu/dts/arm/am335x-boneblack.dts
/usr/src/sys/boot/fdt/dts/arm/beaglebone-black.dts
/usr/src/sys/boot/fdt/dts/arm/beaglebone-common.dtsi
/usr/src/sys/boot/fdt/dts/arm/beaglebone.dts
```
You can find examples of pin configuration in those files and add your pins, e.g. in am335x-bone-common.dtsi:
	
	



```
i2c2_pins: pinmux_i2c2_pins {
        pinctrl-single,pins = <
            AM33XX_IOPAD(0x978, PIN_INPUT_PULLUP | MUX_MODE3)
            AM33XX_IOPAD(0x97c, PIN_INPUT_PULLUP | MUX_MODE3)
```
the 1st parameter is the _DT Offset_ from the spreadsheet or-ed with 0x800, the 2nd is the direction and pullup/pulldown parameter and 3rd parameter is the pin mode (0..7).


----------



## tingo (May 20, 2017)

Beware: GPIO on Beaglebone is 3.3 V only. So if you are going to use it for *real* serial ports you need level converters...


----------



## aragats (May 20, 2017)

tingo said:


> GPIO on Beaglebone is 3.3 V only. So if you are going to use it for *real* serial ports you need level converters


Yes, good point! Universal converters (3.3-5V TTL) are widely available (e.g. at eBay ― starting from $1.5).


----------



## OlivierW (May 24, 2017)

Thanks aragats and tingo!

aragats, I don't know if I "want" to use DTS or if I can just use the gpioctl tool.
For now I've used "beaglebone-green.dts" decompiled from "/boot/dtb/am335x-bonegreen.dtb" to enable the others UART as explained in my first post.

My /usr/src/ folder is empty because otherwise the source use too much spaces. Anyway, I can find the files you mentions in:
https://github.com/freebsd/freebsd/tree/master/sys/gnu/dts/arm
https://github.com/freebsd/freebsd/tree/master/sys/boot/fdt/dts/arm

Well, I'll have to dig about this dts file format to understand it… because in the section you show me, I have in my DTS file:

```
pinmux_i2c2_pins {
        pinctrl-single,pins = <0x178 0x33 0x17c 0x33>;
```


tingo, sure, I'll only wire some 3.3V devices (GPS and µC).

aragats, yes, and some years ago there was quite a lot of 12V RS-232 devices too


----------



## OlivierW (May 24, 2017)

Can I just compile "/usr/src/sys/gnu/dts/arm/am335x-bonegreen.dts" and have the same file result as "/boot/dtb/am335x-bonegreen.dtb"?
Because it'll probably be much easier to deal with functions, constants,… instead of weird numbers from nowhere 

Edit:
Well, I've just tried it:

```
# dtc -I dts -o /tmp/am335x-bonegreen.dtb -O dtb -b 0 /tmp/dts-src/dts/arm/am335x-bonegreen.dts
Error: /tmp/dts-src/dts/arm/am335x-bonegreen.dts:10.1-9 syntax error
FATAL ERROR: Unable to parse input tree
```
dtc errors are so helpful… :-(


----------



## Phishfry (May 24, 2017)

The dts files in the /gnu directory are not for FreeBSD. They are for pulling device entries and they are what developers use to port a new platform to FreeBSD. They are the Linux dts files. So  changes would be necessary to accommodate FreeBSD usage.


----------



## aragats (May 24, 2017)

OlivierW said:


> I don't know if I "want" to use DTS


I might expressed it incorrectly. I meant those "system" DTSs which are loaded by kernel at boot time.
The example you tried:


OlivierW said:


> # dtc -I dts -o /tmp/am335x-bonegreen.dtb -O dtb -b 0 /tmp/dts-src/dts/arm/am335x-bonegreen.dts


won't work outside of that original tree since those .dts have several includes.
If you want to compile a stand alone DTB file, you should create an "overlay" which will override the settings set at boot time. You will get a _.dtbo_ instead of _.dtb_.


----------



## aragats (May 24, 2017)

OliverW , take a look and try building overlay examples from https://github.com/beagleboard/bb.org-overlays.
I think the overlay approach is easier and safer, you'll not need to modify the system files.
To load an overlay automatically you should include its name in the kernel command line (just an example from my BBB):
	
	



```
... cape_universal=enable bone_capemgr.enable_partno=BB-LCD10:00A2,BB-SPIDEV0 ...
```


----------



## aragats (May 24, 2017)

Phishfry said:


> The dts files in the /gnu directory are not for FreeBSD


DTS stands for Device Tree [description] Source, they are platform-independent.
I haven't read thoroughly, but I believe this is a good source of basic info.


----------



## OlivierW (May 24, 2017)

Phishfry ok, thanks 

aragats thanks for the explanation. I had seen those overlays in a previous post by Phishfry but I couldn't find how to make them work.
After quite some fight, it seems I've successfully compiled "BB-UART4-00A0.dtbo".


If it can help someone, I cloned the bb.org-overlays repo with:
`git clone https://github.com/beagleboard/bb.org-overlays`

Then I tried to compile directly with dtc but I got a "syntax error", then I found here: https://github.com/beagleboard/bb.org-overlays/issues/28 I needed to use "make" (well, gmake on FreeBSD).

Then with `gmake src/arm/BB-UART4-00A0.dtbo` I had an error about "-@" not being known by dtc: "dtc: invalid option -- @", of course the versions in base (1.4.0) and ports (1.4.2) were too old. This "-@" option appeared in 1.4.3 and the current version is 1.4.4.
I tried to compile 1.4.4 but got an error, so went with 1.4.3.

Here are all the commands used:
`cd /tmp
pkg install git-lite gmake bison
git clone https://git.kernel.org/pub/scm/utils/dtc/dtc.git
cd /tmp/dtc
git checkout tags/v1.4.3
gmake
cd /tmp/bb.org-overlays
gmake src/arm/BB-UART4-00A0.dtbo DTC=/tmp/dtc/dtc`
and you'll get "src/arm/BB-UART4-00A0.dtbo" :-D


Now, I don't know where I should move this dtbo file, in "/boot/dtb/"? And the "cape_universal=" line should go in "/boot/msdos/bb-uenv.txt"?


----------



## aragats (May 24, 2017)

Yeah, that could be a problem, this was written back in 2015, not sure if something is changed.
However, the following mailing list thread is interesting:
https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015855.html.
It particular it contains real working examples!


----------



## Phishfry (May 25, 2017)

dtbo goes in the root of the fat partition and a dtoverlay=### entry in config.txt to point it.
It works just like Linux dtbo.

Here are good examples
https://www.raspberrypi.org/documentation/configuration/device-tree.md


----------



## Phishfry (May 25, 2017)

I am not sure that dtbo work on anything but the RPi3/ARM64. I know it works there. I am using it.
Maybe Gonzo backported it to ARMv6. I dunno.


----------



## Phishfry (May 25, 2017)

The dtbo seems like a great solution for not compiling kernel to add new devices. You just compile the dtbo and add to config.txt.
In reality most accessories need to have their support in the kernel so you are compiling anyway.
Example1: RTC. Had to add DS3230 to kernconf, so compile kernel.
Example2 OW_Temp. Same thing, not in default kernel needs recompile.

So dtbo really isn't revolutionary but better for some devices.

A handbuilt dts is the way I do it generally. I modify the default dts adding entries.


----------



## OlivierW (May 25, 2017)

It's quite confusing…
I first tried "cape_universal=enable bone_capemgr.enable_partno=BB-UART1-00A0,BB-UART4-00A0" in "/boot/msdos/bb-uenv.txt": not working.

Then I tried "fdt_overlays="BB-UART1-00A0.dtbo,BB-UART4-00A0.dtbo"" in "/boot/loader.conf", from the thread pointed by aragats : https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015975.html : not working.

I tried both options above with a single and two .dtbo files.


Phishfry : I don't have a config.txt file. Should I create it?
And the article mention: "overlays/acme-board.dtbo", so should I move my .dtbo files in /boot/overlays? At the moment they are in /boot/dtb.

It's difficult to find up to date information how to use these DTB and DTBO files.
As I'm running "FreeBSD 12.0-CURRENT #0 r314137", I would say the best up to date information is in this thread from March 2017: https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015855.html

And is there a way to debug? How can I be sure my DTBO files are valid and loaded? I can't find anything in dmesg.


Edit: Phishfry, I just read your two last messages, it's not encouraging :-( But in the mailing list pointed above DTBO files seems to work.


----------



## Phishfry (May 25, 2017)

Actually here is gonzo in that same mailing list post describing how to do it, so check that out. It does work on ARMv7
https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015975.html


```
3. Copy it to /boot/dtb/ directory on your BBB

4. Enable overlay in /boot/loader.conf by adding following line:

fdt_overlays="am335x-beaglebone-tscadc.dtbo"

--
gonzo
```

So maybe only newer ARM64/RPi3 uses the config.txt method. I never heard of fdt overlays in /boot/loader.conf


----------



## OlivierW (May 25, 2017)

I can't even compile the "am335x-beaglebone-tscadc.dts" file.
I tried with dtc 1.4.0 from base, 1.4.2 from ports and 1.4.3 from: https://git.kernel.org/pub/scm/utils/dtc/dtc.git and I'm getting:
`# dtc -I dts -O dtb -o am335x-beaglebone-tscadc.dtbo am335x-beaglebone-tscadc.dts
Error: am335x-beaglebone-tscadc.dts:2.2-8 syntax error
FATAL ERROR: Unable to parse input tree`

`# /usr/local/bin/dtc -I dts -O dtb -o am335x-beaglebone-tscadc.dtbo am335x-beaglebone-tscadc.dts
Error: am335x-beaglebone-tscadc.dts:2.2-8 syntax error
FATAL ERROR: Unable to parse input tree`

`# /tmp/dtc/dtc -I dts -O dtb -o am335x-beaglebone-tscadc.dtbo am335x-beaglebone-tscadc.dts
Error: am335x-beaglebone-tscadc.dts:7.14-15 syntax error
FATAL ERROR: Unable to parse input tree`

I don't know what those numbers means "2.2-8" and "7.14-15". It can't be line numebrs, or else they would be the same in the 3 versions.


----------



## Phishfry (May 25, 2017)

I don't think you want multiple overlays. Combine all your accessories into one dtbo.
Overlay is just that. The boards default dts is still used its just the accessories that can go into the dtbo. 

The original method still works -adding devices into your boards dts.


----------



## Phishfry (May 25, 2017)

The ADC device example is not the easiest device to learn this. Probably one of the hardest.
I picked something easier to figure out what works. I started at RTC.


----------



## OlivierW (May 25, 2017)

Well, I found about the multiples overlays on gonzo's blog: https://kernelnomicon.org/?p=498
And as I said, I also tested with a single overlay in a "/boot/msdos/bb-uenv.txt" or "/boot/loader.conf", without more success.



Phishfry said:


> A handbuilt dts is the way I do it generally. I modify the default dts adding entries.


You start from which DTS file? A decompiled one from /boot/dtb or one from FreeBSD source? And if it's from source, from which folder (you told me previously the one in the "gnu" folder couldn't work without modification for FreeBSD)?


----------



## OlivierW (May 25, 2017)

OlivierW said:


> And is there a way to debug? How can I be sure my DTBO files are valid and loaded? I can't find anything in dmesg.



Well, I just found: `sysctl -b hw.fdt.dtb | dtc -I dtb` on gonzo's blog: https://kernelnomicon.org/?p=743

And it seems my DTBO files don't change anything in the output of this command.


----------



## Phishfry (May 25, 2017)

This is the source I edit on BBB.
/usr/src/sys/boot/fdt/dts/arm/beaglebone-black.dts

I back up the original so I can revert.


----------



## Phishfry (May 25, 2017)

The real trick on dts editing seems to be correct placement in the tree under the proper parent device.


----------



## aragats (May 25, 2017)

OlivierW said:


> I first tried "cape_universal=enable bone_capemgr.enable_partno=BB-UART1-00A0,BB-UART4-00A0" in "/boot/msdos/bb-uenv.txt": not working.


I think the syntax depends on uboot version. I used to build it from git long time ago.



Phishfry said:


> In reality most accessories need to have their support in the kernel so you are compiling anyway.


Yeah, for the same reason I just "forked" one of the include files (am335x-bone-common.dtsi) and added my changes to it, e.g. I needed _mmc2_.


----------



## Phishfry (May 25, 2017)

I have to confess I use crochet for all my Arm compiling. It just makes it so easy.
https://github.com/freebsd/crochet
You still have to modify your source to suit your accessory but I do not enjoy cross compiling.

So I modify boards kernconf adding needed 'gadget' module, then edit dts to suit, run crochet to see if successful. Crochet saves your build and recompiling takes 5-10 minutes after your first compiling run.


----------



## OlivierW (May 25, 2017)

Phishfry said:


> This is the source I edit on BBB.
> /usr/src/sys/boot/fdt/dts/arm/beaglebone-black.dts
> 
> I back up the original so I can revert.



Thanks, I tried but it failed:
`# /tmp/dtc/dtc -I dts -o /tmp/bbg-from-scratch.dtb -O dtb -b 0 head/sys/boot/fdt/dts/arm/beaglebone-black.dts
Error: head/sys/boot/fdt/dts/arm/beaglebone-black.dts:30.1-2 syntax error
FATAL ERROR: Unable to parse input tree`


Actually, I built my image with crochet. But I would still have to edit those DTS files to enable UART.

Well, it's 3:22 here in France: time to sleep. I'll try again later. Thanks again a lot aragats and Phishfry for all your help!


----------



## OlivierW (May 29, 2017)

Hello,

I fought again for a few hours, and still failing to enable any others UART.
First question, does anyone know why in the original "beaglebone-green.dts" there are "pinmux_uart0_pins {" and "uart2_pins {" blocks? Why one of them is prefixed with "pinmux_" and not the other one?


I tried to decompile the 2 .dtbo files I compiled the other day: "BB-UART1-00A0.dtbo" and "BB-UART4-00A0.dtbo" and use them in my modified "beaglebone-green.dts" file (because the .dtbo files doesn't seems to be loaded and I've not been able to compile a .dts from scratch as suggested by Phishfry (see my post just above this one)).
So, now I have:

```
pinmux_uart1_pins {
        pinctrl-single,pins = <0x184 0x8 0x180 0x28>;
        linux,phandle = <0x51>;
        phandle = <0x51>;
};

pinmux_uart4_pins {
        pinctrl-single,pins = <0x74 0xe 0x70 0x2e>;
        linux,phandle = <0x52>;
        phandle = <0x52>;
};
```

just after this block:

```
uart2_pins {
        pinctrl-single,pins = <0x150 0x29 0x154 0x9>;
        linux,phandle = <0x2e>;
        phandle = <0x2e>;
};
```

I've recompiled but I still can't use UART1 or UART4.
I've checked with `sysctl -b hw.fdt.dtb | dtc -I dtb` to be sure my modifications were present, and they were there.

I've also tried using "uart1_pins" and "uart4_pins" (without the "pinmux_" prefix): no more luck.
The "phandle" values 0x51 and 0x52 are just random values which weren't already used in the .dts file.

I don't know what else to try.


----------



## comarius (Sep 13, 2019)

Hi,
Is 2019 and I am having same issues I have open couple of topics on this forum.
I am running into this post, lucky... I guess

Any success on your side or you never solved. I am on this UART thing for the last 3 days..

Thank you


----------



## OlivierW (Oct 2, 2019)

Hello,
I have never solved this problem and couldn't find more time to work on this project :-(
Good luck, I hope you'll find a solution and will share it here


----------

