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

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!
 
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.
 
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:
Code:
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 :)
 
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.
 
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
Code:
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!!
 
This in no way (I can see) maps to
Code:
root@beaglebone:~ # gpioctl -lv
:
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>
:
which is a linear list and, by the way, is a non-BBB specific tool.

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
Code:
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:
Code:
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 ...
 
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.
 
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 ...
 
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
 
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.
 
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:
Code:
                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:
Code:
# 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
Code:
dma-names = "tx", "rx";
. Now in dmesg I'm getting 3 more UART:
Code:
# 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.
 
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.
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.
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.
 
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:
Code:
# 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:
Code:
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:
Code:
# 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?
 
If you want to use DTS files, I believe you can find most of them by running
Code:
$ 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:
Code:
    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).
 
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:
Code:
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 :)
 
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:
Code:
# 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… :-(
 
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.
 
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:
# 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.
 
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):
Code:
... cape_universal=enable bone_capemgr.enable_partno=BB-LCD10:00A2,BB-SPIDEV0 ...
 
Back
Top