beaglebone gpio is not working

Hi all,

I am trying to use a gpio P9_23 (gpio 49) to light up an LED via sysfs and kernel module, and I used this link to bring up SD card

kernel: am33x-v5.10 (Longterm 5.10.x), kernel_version=5.10.153-bone69

Then once device boots up I do below commands

cd /sys/class/gpio/
echo 49 > export
cd gpio49
echo out > direction
echo 1 > value
echo 0 > value

Attached is pinmux map,

I tried released images and there it works,

I don’t understand why it doesn’t work with Debian: Getting Started with the BeagleBone Black - Linux Guides - Engineering and Component Solution Forum - TechForum │ Digi-Key link image.

Kindly help.

(P.S. edited for wrong gpio 65.)

What pinmux for P9_23 did you set?


Thanks for response,

Do we need to set pinmux other that the dtb file?

Also I have used univ dtb by using enable_uboot_cape_universal=1 in uEnv.txt to load universal dtb,


which shows pinmux on P9_23 as,

P9.23 17 fast rx down 7 gpio 1.17 lo >> sysfs (pinmux_P9_23_default_pin)

In working SD image it shows as,

P9.23 17 fast rx down 7 gpio 1.17 << lo P9_23 (pinmux_P9_23_default_pin)

Non working logs:
Bootlog and P9_23 pinmux node when using am335x-boneblack-uboot-univ.dtb

exporting gpio doesn’t work in this.

Working logs:
Bootlog with working dailybuild image, P9_23 am335x-boneblack-uboot-univ.dtb

exporting gpio work in this.


What should I do to do pinmuxing?


If you are using am335x styled beaglebone boards, use config-pin.

config-pin -l p9.23 

That will show you what is available for that specific pin. Then, to alter its state of muxing, use this command…

config-pin p9.23 gpio

There may be additional types of gpio for that pin or whatever pin(s) you use.


Did that too
took config-pin application,

used am335x-boneblack-uboot-univ.dtb , set direction to output then, echo 1 > value . LED on P9_23 doesn’t work still.

I am not sure what am I missing.

Hello @Mrigendra_Chaubey1 ,

Have you exported the GPIO, set it to out, and then set the value to 1 by using the command you showed, i.e. echo 1 > /sys/class/gpio/gpioN/value ?


P.S. gpioN where N is the value of the GPIO pin. For instance, GPIO_49 is P9_23 and it can be found here online: - bone101 .

Maybe try this idea:

echo 49 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio49/direction
echo 1 > /sys/class/gpio/gpio49/value

Also, please show what is listed in /sys/class/gpio/* by using the command ls -l.

So, if you have the export command in the /sys/class/gpio/ file, it should be that easy.

Oh…you may need a udev rule for using sysfs. Did you look online in the ideas for udev rules for the BeagleBone Black?

HI @silver2row

yes I first export then do

cd /sys/class/gpio/
echo 49 > export
cd gpio49
cat out > direction
echo 1 > value //led should light up
echo 0 > value //led should go off

export command is available inside /sys/class/gpio, with that only I was getting gpio49.

I don’t think its udev’s business to do anything with pinmuxing.

There is only one way to know absolutely is to read respective control registers of gpio49.


  1. Did you make your image?
  2. Are you using a specific image from
  3. If you are using an image from, please let me know the output of these commands:
    a. uname -a
    b. cat /etc/dogtag

I will try to duplicate this idea soon when you reply w/ the info. and questioning. I say that b/c some kernels and images are different.

By different, there could be specific GPIOs listed and available or other defaults made when booted.

The /etc/udev/rules.d/ directory should have some files in it to handle using sysfs on the command line w/out having to change file permissions to debian or whatever user you have currently. This way, the root account is not in control of the GPIO in question.


P.S. @Mrigendra_Chaubey1 , if you have a normal kernel and image, I can duplicate this error you are receiving. I turned on my board, booted it, and performed the commands I have listed.

I see you used cat out > direction instead of echo out > direction. Is this a fact or did you make a typo?

Hi @silver2row

Yes I made my image, rootfs using this link.


uname -a
Linux buildroot 5.10.153 #1 SMP PREEMPT Sun Jan 8 20:44:04 IST 2023 armv7l GNU/Linux

cat /etc/dogtag
cat: can’t open ‘/etc/dogtag’: No such file or directory

ls -l /etc/udev/rules.d/
ls: /etc/udev/rules.d/: No such file or directory

I also used this image for verifying gpio functionality,

root@beaglebone:~# uname -a
Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux

root@beaglebone:~# cat /etc/dogtag Debian Buster Console Image 2020-04-06

Yes I made a typo it should be,
echo out > direction


I saw you were using the from github. I will go there to search the ideas.


P.S. There is a newer than that one rendition of .dtbo files. GitHub - beagleboard/ Device Tree Overlays for boards handles up to kernel 5.4.x. Let me see about the more recent ideas:

1. # too old for kernel 5.10.x.

Also…I am not being of too much help so far. I understand. Frustrating. Trying to figure out this idea is not easy for me…

Have you tried other .dtb files yet? For instance, in the kernel and in u-boot, there are definitions already allocated towards the BBB and other boards from

dts « boot « arm « arch - kernel/git/torvalds/linux.git - Linux kernel source tree shows a bunch of am335x- files for use.

If you go to BeagleBoard-DeviceTrees/src/arm at v5.10.x-ti-unified · beagleboard/BeagleBoard-DeviceTrees · GitHub , there may be more ideas circulating for DTS and .dtb files.

You may need additional files for setting up specific instances for use.

  1. BeagleBoard-DeviceTrees/am335x-boneblack-uboot-univ.dts at v5.10.x-ti-unified · beagleboard/BeagleBoard-DeviceTrees · GitHub # is the file before compilation…
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
#include "am335x-bone-common-univ.dtsi"
#include "bbb-bone-buses.dtsi"

I did not keep up w/ the DTS files for a long time. Maybe someone else can pitch in a bit here?

At one point, /dev/gpio/ or /sys/class/gpio/gpio* changed into /dev/bone/. I think it is still that way w/ the newer images and kernels.

During that process, the process of changing things to handle the Cape Compatibility Layer and /bone/ files, there was a lot of work dedicated to making that idea relevant for the BBB boards and other am335x boards.

But, there is some background and ideas on what to look out for currently. I hope that helps a bit.

overlays are from here,

I have tried loading below dtbs in uboot,


still didn’t worked.

One thing is I have previously successfully bring up lcd overlay for 4 inch waveshare lcd so pinmux definetly works via overlay, so trying to create an overlay for this gpio.

lcd 4 inch overlay,

You have been helpful dude :smiley:.
Its 5.xx kernel so older methods may not work. I am confident I should be able to dig things up and post solution here, it may take some time though.

building full image with below link will take 3 to 4 hours of time.


Hello @Mrigendra_Chaubey1 ,

No issue. I am not quite sure how to go about handling GPIO in the kernel build. For instance, do you need CONFIG_GPIO_WHATEVER?

In the kernel build, depending on your kernel, there may be a need to make additional entries in the build process. If you are building the kernel, use / to type in during your picks and choices.

Then, type something like CONFIG_GPIO and hit enter. I am not sure exactly what may pop up but there are also other routes outside of menuconfig to handle the build options in the kernel.

Either way, I may find some time later to handle the GPIO/CONFIG look up in the kernel. I am sure it has to be documented somewhere. I just do not know where right now. My Documentation but I doubt it. It might be in another portion of the kernel. Who knows?

If you get bored, reply again. I will take time out soon to look over the kernel CONFIG_ options soon.


@Mrigendra_Chaubey1 ,

Hey sir, I think you may need the headers. Is that possible? Is it possible that these headers are not installed when building the CROSS_COMPILATION kernel and tools?

I was reading in the kernel docs. more. See here: Exporting kernel headers for use by userspace — The Linux Kernel documentation .

It may be a bit tricky but it is all an idea from me so far. I am not sure if this is indeed the issue.


P.S. Also…

The link above shows the many drivers, the GPIO drivers, that one can use to handle the CONFIG_GPIO_WHATEVER Kconfig options when building. Right now, I am not sure which exact GPIO one needs to build in the Kconfig/menuconfig options.

gpio-sysfs.c but I am sure there are more that are needed for the am335x. Be patient. I will keep researching. It is really too bad I do not know the answer offhand.

Ok so finally I am able to make my gpio working,

Not sure but from google searches /sys/class/gpio seems to be getting removed and descriptor based gpiolib is recommended. Check here and here,

Corresponding userspace commands given in libgpiod, so using below commands just to test,

gpioset gpiochip0 17=1
gpioset gpiochip0 17=0

Took reference from overlay of BB-W1-P9.12-00A0.dts and its respective driver w1-gpio.c

Now LED works as expected,

gpioinfo | grep -i P9_23
line 17: “P9_23” “gpio-learn” output active-high [used open-drain]

I’ll continue doing experiments to learn more about this new gpio library.

This answer is just suggestive,I can’t say sysfs gpio userspace is completely removed or stopped working altogether.

Doubts remaining,
Its a little strange to me that I have all the nodes for sysfs userspace and still echo 1 > value is not working, maybe I need to see what happened inside gpio-sysfs.c


1 Like