GPIO directory structure appears different

General Discussion
1

The BeagleBne-coolbook.pdf on this site lists /sys/class/gpio as containing

export gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport

which is pretty much what I remember. My BBB same directory has:

chip0 chip2 export gpiochip512 gpiochip576 unexport
chip1 chip3 gpiochip544 gpiochip608

What are the functions of chipx and gpiochipxxx?

Why does echo 7 > export return “-bash: echo: write error: Invalid argument” instead of creating a gpio7 directory?

How do I now set and clear GPIO_7 or any other GPIO lines from the command line?

Where is updated documentation and tables that describes the new numbering structure?

dogtag is eagleBoard.org Debian Trixie Base Image 2025-12-08

uEnv.txt

Docs: Making sure you're not a bot!

uname_r=6.18.4-bone14
#uuid=
#dtb=

###U-Boot Overlays###
###Documentation: Making sure you're not a bot!
###Master Enable
enable_uboot_overlays=1

###Overide capes with eeprom
#uboot_overlay_addr0=.dtbo
#uboot_overlay_addr1=.dtbo
#uboot_overlay_addr2=.dtbo
#uboot_overlay_addr3=.dtbo

###Additional custom capes
#uboot_overlay_addr4=.dtbo
#uboot_overlay_addr5=.dtbo
#uboot_overlay_addr6=.dtbo
#uboot_overlay_addr7=.dtbo

###Custom Cape
#dtb_overlay=.dtbo

###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1

###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
#uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo

##cape Universal Enable
cape_universal=enable
enable_uboot_cape_universal=1

###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1

###U-Boot fdt tweaks… (60000 = 384KB)
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###

console=ttyS0,115200n8
cmdline=fsck.repair=yes earlycon coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100

#In the event of edid real failures, uncomment this next line:
#cmdline=fsck.repair=yes earlycon coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 video=HDMI-A-1:1024x768@60e

#Use an overlayfs on top of a read-only root filesystem:
#cmdline=fsck.repair=yes earlycon coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 overlayroot=tmpfs

##enable Generic eMMC Flasher:
#cmdline=init=/usr/sbin/init-beagle-flasher

Have a Blessed day!

Don

2

In the 6.x series the gpio hard coded values are gone, its now dynamicly allocated on boot up. If you have pins you want to use as outputs, use the gpio-led node in an overlay.

3

You might want to take a look at libgpiod. That’s the way to do it these days.

gpioinfo, et. al. are your new friends.

4

Man I just get used to something and it gets changed. There are lots of .dts files listed, what is a good one to start with for general GPIO, besides the obvious ones with another board name in it. And I assume you use that modified one to compile into a .dtbo which will be added to uEnv.txt corrent?

5

Here’s a good example: BeagleBoard-DeviceTrees/src/arm/overlays/BONE-LED-P8-37.dtso at v6.18.x · beagleboard/BeagleBoard-DeviceTrees · GitHub

You can turn on and off output of P8_37

Regards,

6

I forgot to say with your help I got it (the IO line in question) to work. I also notice there is a link to a pdf called Device Trees for Dummies. I am reading that now. I will also study your link.

Programming is relatively easy, circuit design is also OK but I spend a lot of time keeping up with changes. Thanks again.

Have a Blessed day!

Don

7

What px_yz pins are you looking at?

8

P9 pin 12 GPIO 60 for a test. Found it with gpioinfo and could set/clear it with gpioset. Any GPIO will do for a test. Now to do it in code after making if an output at bootup.

9

Join the club my friend. I agree with your sentiment; the pace is relentless.

10

If you don’t need to change the pin, but just want a known level,
you could consider implementing a gpio-hog in your device-tree.
That’ll set it very early as the kernel initializes and keep it reserved,
so that nothing else can mess with it.

If you need it set really really early, you could consider trying
your hand at a custom u-boot build…