How to handle dts overlay's for beglebone black

Hello,
At work an electrical engineer wants to use the beaglebone black. He uses a dts overlay. I pointed him to FreeBSD and he likes the idea using that. My question is: How do I handle the overlay in FreeBSD. If I am correct the overlay handling is not the same as in Linux.
Do I have to insert the overlay somewhere (pinmux@800 section ?) inside the am335x-boneblack.dts file? Can someone point me to documentation about it or explain how to do it?
I am using FreeBSD 12.0-CURRENT r319859

This is the ovelay:
Code:
/dts-v1/;
/plugin/;

/{
    compatible = "ti,beaglebone", "ti,beaglebone-black";
    part_number = "BB_ITS";
    version = "00A0";
   
    exclusive-use =
        "P9.23",        /* A0 */
        "P9.14",        /* A1 */
        "P9.15",        /* A2 */
        "P9.16",        /* A3 */
        "P9.17",        /* SPI0_CS */
        "P9.18",        /* SPI0_DI */
        "P9.21",        /* SPI0_DO */
        "P9.22",        /* SPI0_CLK */
        "P9.13",       
        "P9.24",       
        "P9.26";       
       
    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            bb_its: pinmux_bb_its {
                pinctrl-single,pins = <
                  0x074 0x27
                  0x048 0x27
                  0x040 0x27
                  0x04c 0x27
                  0x15c 0x27 /* pin nummer tabel Beaglebone Black P9 Header, 0x17 : 00 = fast, 0 = output, 1 = pullup, 0 = pullup enabled, 111 = mode 7 (GPIO) */
                  0x158 0x27
                  0x154 0x27
                  0x150 0x27   
                  0x044 0x27   
                  0x184 0x27   
                  0x180 0x27   
                  >;
            };
        };
    };

    fragment@1 {
        target = <&ocp>;
        __overlay__ {
            bb_its_pinmux {
                compatible = "bone-pinmux-helper";
                status = "okay";
                pinctrl-names = "default";
                pinctrl-0 = <&bb_its>;
            };
        };
    };
   
    fragment@2{
    target = <&pruss>;
    __overlay__ {
      status = "okay";
    };
  };
};
 
I don't have personal experience with DTS, but you may find following useful
This commit introduces handler for "fdt_overlays" variable that can be
defined either as a loader env variable or U-Boot env variable.
fdt_overlays is comma-separated list of .dtbo files located in
/boot/dtb/ directory along with base .dtb. ubldr loads files and
applies them one-by-one to base .dtb and then passes result blob to
the kernel.

Taken from this commit, should be in tree now.
 
I noticed a entry for pruss at the bottom of the overlay. I don't think that is needed. If you checkout dmesg it shows pruss started on FreeBSD 11.1

I am interested in the outcome of reserving pins like that.(exclusive use)

So let us know how it works out.
 
Thanks for the answers. I am using the method described in https://obsigna.net/?p=660 now.
I let you know if we succeed using the beaglebone with FreeBSD, but it will take some time.
The pruss are not default available with FreeBSD 12.0 - CURRENT version I am using now. See Thread 61334
I will investigate if 11.1 is a better option for me.
 
Do you have any special reason to use release 12 ? if not stay with stable, that is 11.1 ! Expecially if you are building an end consumer product, not something to be hacked each week.
 
After some investigation I find out we don't need the overlay at all. We could give the pins the behaviour we want with gpio functions (gpioctl, libgpio).
There is no special reason to use 12-current for us. I still have to find out if FreeBSD 11.1 works also for us.
 
It all depends on what you want to do.
If you want simply to turn a digital output pin on and off, then it will be not much difficult.
If you want to do more complext stuff, you will see, it is a real challenge.

Just in case, here is a reference to the DTO thing, I found it a few hours ago:
https://wiki.freebsd.org/FlattenedDeviceTree

Also, looking around I found that the "magic" command you intend to use to
configure pins is called fdt_pinctrl, they are writing its ducomentation in these
days, I saw it here:
https://reviews.freebsd.org/D14235#change-d4VygLcc8c3I

I can't help you much, I had a good control of the BBB in Debian Linux, I moved to FreeBSD only recently.
 
I had a heck of a time getting a RTC working on BBB. I tried to make the official BB-RTC-00A0.dts work with no luck.
Went back to my Raspberrry Pi dts and changed the compatible="" line to beaglebone settings and it all worked fine.

The DS1307 driver would make tda0 and tda1(Provides Video out) go AWOL so I ditched that and moved to DS3231.
(I was going to use DS1307 on my BBB)

So moral of the story is Linux needs explicit pinouts for RTC to work whereas FreeBSD does not.
Pinmuxing might be needed to draw out some of the other "pin modes". Most pins on the BBB have 5-8 mux modes.

Once I figure out what pins are needed I will do a write-up.
I used 3.3V,ground, i2c sda and sdl and one GPIO line. GPIO line might not be needed.

Same story on ADC controller on FreeBSD. The controller is enabled but the pins and channels need assigning.

Enabling PWM on FeeeBSD 11 was just a matter of setting the status from disabled to okay.
Linux requires more from the overlay.
 
The DS1307 driver would make tda0 and tda1(Provides Video out) go AWOL so I ditched that and moved to DS3231.
(I was going to use DS1307 on my BBB)

So moral of the story is Linux needs explicit pinouts for RTC to work whereas FreeBSD does not.
Pinmuxing might be needed to draw out some of the other "pin modes". Most pins on the BBB have 5-8 mux modes.

Once I figure out what pins are needed I will do a write-up.
I used 3.3V,ground, i2c sda and sdl and one GPIO line. GPIO line might not be needed.

I used successfully a DS3231 [ HALJIA DS3231 ] in Linux Debian (a recent release), I write you here a summary from my notes. I still had no time to try in FreeBSD.

-----------------------
Wiring:
1] (device +) ⇒ Pin P9-3 # questo da tensione di 3.3V
2] (device -) ⇒ Pin P9-1 # GND
3] (device D) ⇒ Pin P9-20
4] (device C) ⇒ Pin P9-19

Code:
# find addres of RTC device    => 0x68
root@bbb> i2cdetect -y -r 2
# read seconds register
root@bbb> i2cget -y 2 0x68 0x00
# set minutes register to "6"
root@bbb> i2cset -y 2 0x68 0x01 0x06

# --- now with a driver ----
# enable driver for the RTC
root@bbb> echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-2/new_device
# read RTC device time
root@bbb> hwclock -r -f /dev/rtc1
# set RTC device time with system time
root@bbb> hwclock -s -f /dev/rtc1

------------------------
 
FreeBSD 11.1 seems to work for me out of the box. The pruss are also available.
Once I realized I can do all I need with libgio calls I didn't try very hard to get the original overlay to work on FreeBSD.
 
FreeBSD 11.1 seems to work for me out of the box. The pruss are also available.
Once I realized I can do all I need with libgio calls I didn't try very hard to get the original overlay to work on FreeBSD.

Great, lucky you !

But in man gpio I don't see any reference to ADC, PWM, and interrupts.
So, using that yuo are limited to "big-banging". You will discover soon that even detecting a
simple "button push" loop-reading a gpio pin state is not reliable nor efficient. You would need
use PRU [complex] ... ok, maybe you know all of this stuff already;)

I don't have machines available to do tests, for now I can only read man pages.
I wish I could have some fun with the BBB:)
 
FreeBSD 11.1 seems to work for me out of the box. The pruss are also available.
Please post anything regarding using the pruss. From what I undrstand you actually have to compile the software to run on the pruss arch. So I am guessing you would have to compile the pruss "app" with cross compiling in mind?
I guess you would compile inside a chroot and maybe just setenv & set target=pru ?
So pruss is just the subsystem for the 2 pru's then why isn't there PRUSS0 and PRUSS1 ?
 
But in [BGCOLOR=#dee3e7] man gpio[/BGCOLOR] I don't see any reference to ADC, PWM, and interrupts.
Well the manual is brief. Use the code comments...ADC works and PWM works. Interrupts maybe not. I do see this on my BBB when booting:
Code:
aintc0: <TI AINTC Interrupt Controller> mem 0x48200000-0x48200fff on simplebus0
aintc0: Revision 5.0
 
Nicola, maybe I should have add the words "for now" in my previous post. I think you understand the overlay better than I do at the moment. To be more clear of the purpose of all this: my task not the hardware, my colleague handles that and is able to program the pru's in assembly for some real time constraint task without interferance of the operating system. My task is the (user land) program to communicate over the network and with the pru's.
 
Well the manual is brief. Use the code comments...ADC works and PWM works. Interrupts maybe not. I do see this on my BBB when booting:
Code:
aintc0: <TI AINTC Interrupt Controller> mem 0x48200000-0x48200fff on simplebus0
aintc0: Revision 5.0
Nicola, maybe I should have add the words "for now" in my previous post ....
ok, no problem. Your plan is fine, PRU have a bank of mem shared with main sistem, so, ok what you intend to do is "doable" AFAIK :)
Let us know how your progresses !
 
Well the manual is brief. Use the code comments...ADC works and PWM works. Interrupts maybe not. I do see this on my BBB when booting:
Code:
aintc0: <TI AINTC Interrupt Controller> mem 0x48200000-0x48200fff on simplebus0
aintc0: Revision 5.0
Well the manual is brief. Use the code comments...
Code:
aintc0: <TI AINTC Interrupt Controller> mem 0x48200000-0x48200fff on simplebus0
aintc0: Revision 5.0
i still have not reached that level;) ... i saw from yuor other posts interesting material on PWM, i am collecting all info i can.
 
obsigna the link to your blog is gone, could you refresh it please ?
I am struggling with PWM in FreeBSD.11.X
Just recently, I switched my BLog from WordPress to another system, and I didn't simply copy over all the posts, but I redact everything before publishing again. Unfortunately, the procedure in the article on how to enable the ADC device on the BBB by the way of overlays did not work anymore with recent 12-CURRENT's, and I was reluctant to publish it before I resolved the problem. It turned out that there were command line arguments missing when compiling the overlays, namely -b0 and -@ are essential to get overlays working. Now here is my new and corrected BLog article:

Enable the ADC and PRU devices of the Beaglebone Black on FreeBSD 12-CURRENT
 
Back
Top