Overlays: BeagleBone AI-64 [PWM]

The first 3 PWM overlays’s for this spec : Beagleboard:BeagleBone cape interface spec - eLinux.org

Are now enabled, they will be built by default in ‘r55’ of our 5.10.x kernel…

You can manually update via:

debian@BeagleBone:~$ cd /opt/source/dtb-5.10-ti-arm64/
debian@BeagleBone:/opt/source/dtb-5.10-ti-arm64$ git pull
Already up to date.
debian@BeagleBone:/opt/source/dtb-5.10-ti-arm64$ make
  DTC     src/arm64/k3-j721e-sk-rpi-exp-header.dtb
  DTC     src/arm64/k3-j721e-sk.dtb
  DTC     src/arm64/k3-j721e-cpb-csi2-ov5640.dtb
<snip>
  DTC     src/arm64/overlays/BONE-PWM0.dtbo
  DTC     src/arm64/overlays/BONE-PWM1.dtbo
  DTC     src/arm64/overlays/BONE-PWM2.dtbo
debian@BeagleBone:/opt/source/dtb-5.10-ti-arm64$ sudo make install
# install Device Tree
mkdir -p /boot/dtbs/5.10.120-ti-arm64-r53.1/ti/
cp src/arm64/*.dtb /boot/dtbs/5.10.120-ti-arm64-r53.1/ti/
cp src/arm64/overlays/*.dtbo /boot/dtbs/5.10.120-ti-arm64-r53.1/ti/overlays/
cp /boot/dtbs/5.10.120-ti-arm64-r53.1/ti/k3-j721e-*.dtb /boot/firmware/
cp /boot/dtbs/5.10.120-ti-arm64-r53.1/ti/overlays/*.dtbo /boot/firmware/overlays
debian@BeagleBone:/opt/source/dtb-5.10-ti-arm64$ sudo reboot

Add Overlay to extlinux:

debian@BeagleBone:~$ cat /boot/firmware/extlinux/extlinux.conf 
label Linux microSD
    kernel /Image
    append console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 root=/dev/mmcblk1p2 ro rootfstype=ext4 rootwait net.ifnames=0
    fdtdir /
    fdtoverlays /overlays/BONE-PWM0.dtbo /overlays/BONE-PWM1.dtbo /overlays/BONE-PWM2.dtbo
    initrd /initrd.img

fdtoverlays command supports single or multiple overlays listed…

Verify:

debian@BeagleBone:~$ sudo beagle-version | grep UBOOT
UBOOT: Booted Device-Tree:[k3-j721e-beagleboneai64.dts]
UBOOT: Loaded Overlay:[BONE-PWM0.kernel]
UBOOT: Loaded Overlay:[BONE-PWM1.kernel]
UBOOT: Loaded Overlay:[BONE-PWM2.kernel]

There are two more pwm’s available on the header that don’t follow the /dev/bone/pwm/* spec consider them extra for the bb ai-64…

Two other BB AI-64 only pwm’s:

/overlays/BBAI64-P8_37-ehrpwm5_a.dtbo
/overlays/BBAI64-P9_25-ehrpwm4_b.dtbo

Regards,

2 Likes

Hello Sir,

@RobertCNelson , sir, Seth here.

Um…has it already been decided what pins are what on the BONE-PWM0 - BONE-PWM2.kernel .DTBOs?

I am asking. I tried /overlays/BBAI64-P9_25-ehrpwm4_b.dtbo. For whatever reason, I had a LED shatter. Good power or lack of mechanical accessible moves. Either way, I am trying BONE-PWM0 - 2.kernel now.

Seth

P.S. I looked for the Compatible layer spec. recently and could not find the exact pin muxing for the BONE-PWM0 - 2.kernel pins…

I will keep testing. Oh. I also noticed, if anyone wants to jump in here:

  1. I can echo 50000 > period and then echo 10000 > duty_cycle.
  2. Then, I can echo 1 > enable.

The issue remains, when I try to use say in pwmchip0 the pwm1, I get an error when trying to use the pwm0 section of the same pwmchip0.

Here is the error in case anyone cares to comment:

-bash: echo: write error: Invalid argument

That’s stated in the first url I posted above…

pwm0 and pwm1 have a shared clock, so if you enable one, then the other needs to be a variation of them other…

If you want a better response then post exactly what you typed instead of just the error message.

Regards,

1 Like

Hello @RobertCNelson ,

Sir, gotcha. I just saw the link to the specification. /dev/bone/pwm/* .

I was looking at /sys/class/pwm/ instead and looking at pwmchip* .

Seth

P.S. Off to try that miracle of functionality! Thank you for the tip.

To answer though…

cd /sys/class/pwmchip0
cd pwm1
echo 50000 > period
echo 10000 > duty_cycle
echo 1 > enable

This is what I tried so far. I will get w/ the program sooner or later. Thank you!

Hello Sir,

@RobertCNelson , me again…

UBOOT: Booted Device-Tree:[k3-j721e-beagleboneai64.dts]
UBOOT: Loaded Overlay:[BONE-PWM0.kernel]
UBOOT: Loaded Overlay:[BONE-PWM1.kernel]
UBOOT: Loaded Overlay:[BONE-PWM2.kernel]

That is what I have loaded via the command, sudo beagle-version | grep UBOOT, and in /dev/bone/* there is only uart.

Seth

P.S. Here is the uart connection…

ls -l 0

lrwxrwxrwx 1 root root 11 Mar 20 19:55 0 -> ../../ttyS2

Use this location, as they are symlinks set to the actual pin…

That by itself won’t show the error. The values you set in pwm0 are important.

‘period’ is shared by channel a and b, once you set period for a, it’s now fixed for b… only duty cycle can be changed for shared pwm

1 Like

Hello Sir,

@RobertCNelson , you are correct. I am sorry for only showing the first half of my actual commands.

cd /sys/class/pwmchip0
cd pwm1
echo 50000 > period
echo 10000 > duty_cycle
echo 1 > enable

echo 0 > enable
cd ../pwm0
echo 50000 > period
echo 10000 > duty_cycle
echo 1 > enable

That is how I came upon that error. I see what you typed recently about a and b channels.

Did I make a gaff or some huge mistake for the community who likes shared PWM channels?

Seth

P.S.

Sir, I cannot as my board set up only reveals the /dev/bone/uart/0 and not /dev/bone/pwm/* in that directory. I will keep trying to configure things correctly.

That’s right i explained in another forum, this would be fixed on the 1st…

So run:

sudo apt update
sudo apt install --only-upgrade bb-customizations
sudo systemctl enable bb-symlinks.service
sudo reboot

and /dev/bone/pwm/* will now show up…

debian@BeagleBone:~$ cat /boot/firmware/extlinux/extlinux.conf  | grep fdtoverlays
    fdtoverlays /overlays/BONE-PWM0.dtbo /overlays/BONE-PWM1.dtbo /overlays/BONE-PWM2.dtbo
debian@BeagleBone:~$ tree /dev/bone/pwm/
/dev/bone/pwm/
├── 0
│   ├── a -> /sys/class/pwm/pwmchip2/pwm0/
│   └── b -> /sys/class/pwm/pwmchip2/pwm1/
├── 1
│   ├── a -> /sys/class/pwm/pwmchip4/pwm0/
│   └── b -> /sys/class/pwm/pwmchip4/pwm1/
└── 2
    ├── a -> /sys/class/pwm/pwmchip0/pwm0/
    └── b -> /sys/class/pwm/pwmchip0/pwm1/

9 directories, 0 files
debian@BeagleBone:~$ cd /dev/bone/pwm/0/a/
debian@BeagleBone:/dev/bone/pwm/0/a$ echo 50000 > period 
debian@BeagleBone:/dev/bone/pwm/0/a$ echo 10000 > duty_cycle 
debian@BeagleBone:/dev/bone/pwm/0/a$ echo 1 > enable 
debian@BeagleBone:/dev/bone/pwm/0/a$ cd ../b/
debian@BeagleBone:/dev/bone/pwm/0/b$ cat period duty_cycle enable 
0
0
0
debian@BeagleBone:/dev/bone/pwm/0/b$ echo 50000 > period 
debian@BeagleBone:/dev/bone/pwm/0/b$ echo 10000 > duty_cycle 
debian@BeagleBone:/dev/bone/pwm/0/b$ cat period duty_cycle enable 
50000
10000
0
debian@BeagleBone:/dev/bone/pwm/0/b$ echo 1 > enable 
debian@BeagleBone:/dev/bone/pwm/0/b$ cat period duty_cycle enable 
50000
10000
1

Regards,

2 Likes

Hello Sir,

I am sorry. I got excited and did not see where you stated this would not be working until the first. I am one day early.

Seth

P.S. Explanation well received. Thank you, sir.

Hello Sir,

@RobertCNelson , thank you. The trick was w/ your knowledge and the lack thereof in mine.

Seth

P.S. /dev/bone/* now has pwm and uart.

Is there an updated process on how to do PWM for the BeagleBone AI-64? I believe I followed the steps and get the devices to appear under /dev/bone, and I can change the period, duty cycle, and enable. However, I cannot seem to get the output to change in the pins themselves. My current test is an LED. I would expect it to get brighter for higher duty cycle but I don’t see any changes (it’s off for most PWM pins I’ve tried).

Did you load the overlays?

sudo beagle-version

Regards

Is there a table or something somewhere in the documentation that tells which pins on the BBAI 64 expention headers are capable of PWM. Also I am looking for more info about the pins that that are connected to the Arm R5 and have PWM capability. I want to drive 6 servos

The R5 cores can access any of the pins. If you do a search with tag bbai64 and spreadsheet you should find a post by me with the header pins and the various pin mux alternatives

1 Like

@RobertCNelson I checked and they were loaded. My issue ended up being that I didn’t realize there were 4 extra pins on P9 before normal indexing starts, and it seems both a and b need to be enabled for a given pwmchip. Thank you so much for your help!

@Tron I believe the PWM table here (given earlier by @RobertCNelson) is correct: Beagleboard:BeagleBone cape interface spec - eLinux.org

1 Like