I wanted to experiment with the character device API for GPIO, so I installed gpiod
on my RPi 3B+/bullseye. I hit a snag with my first command:
$ sudo apt-get install gpiod
# ...
$ gpioinfo
gpiochip0 - 54 lines:
line 0: unnamed unused input active-high
line 1: unnamed unused input active-high
line 2: unnamed unused input active-high
line 3: unnamed unused input active-high
...
line 52: unnamed unused input active-high
line 53: unnamed unused input active-high
gpiochip1 - 8 lines:
line 0: unnamed unused output active-high
line 1: unnamed unused output active-high
line 2: unnamed "led1" output active-low [used]
line 3: unnamed unused output active-high
line 4: unnamed unused input active-high
line 5: unnamed "cam1_regulator" output active-high [used]
line 6: unnamed unused output active-high
line 7: unnamed unused input active-high
Every line being listed as unnamed
didn't look like a promising start. On my RPi 4B however, all the lines had pin names
. Some research turned up a discussion on GitHub explaining the cause for this: no updates had been made for older RPi models.
A link was given to a source for the RPi 3B+ dts file, and it was suggested that anyone interested in pin names for an unsupported model was welcome to update the dts
file & recompile it with a kernel that would read it properly. This sounded like a fair amount of work for a lazy man, and I wondered if it might be easier to add the pin names with a device tree overlay? I decided to try:
I've been curious about the device tree for a while, but my only experience with it has been limited to adding an occasional overlay specification to /boot/config.txt
. Some overlays have piqued my curiosity, and motivated me - briefly - to learn more, but after looking at the overlay source code, that motivation melted - the code struck me as impenetrably arcane. And getting smacked down on the RPi forum didn't help either. But sometimes, disparaging remarks are motivational, and finally - trial and error yielded a result that seems to get the job done - an overlay that adds pin names to the RPi 3b+ :
The following suggests that this overlay seems to work! Copy the source file to your RPi 3B+, and follow these steps to compile, add and test it:
$ dtc -@ -Hepapr -I dts -O dtb -o 3BPpin_nm.dtbo 3BP_pin_name_overlayRev1.dts
$ sudo cp 3BPpin_nm.dtbo /boot/overlays
# Add the following line to `boot/config.txt`:
dtoverlay=3BPpin_nm
#
$ sudo reboot
... # following the reboot:
$ gpioinfo
gpiochip0 - 54 lines:
line 0: "ID_SDA" unused input active-high
line 1: "ID_SCL" unused input active-high
line 2: "SDA1" unused input active-high
line 3: "SCL1" unused input active-high
...
line 52: "SD_DATA2_R" unused input active-high
line 53: "SD_DATA3_R" unused input active-high
gpiochip1 - 8 lines:
line 0: "BT_ON" unused output active-high
line 1: "WL_ON" unused output active-high
line 2: "PWR_LED_R" "led1" output active-low [used]
line 3: "LAN_RUN" unused output active-high
line 4: "NC" unused input active-high
line 5: "CAM_GPIO0" "cam1_regulator" output active-high [used]
line 6: "CAM_GPIO1" unused output active-high
line 7: "NC" unused input active-high
If you encounter any issues adapting this to your model of RPi, make a comment in the Issues section here. I may or may not be able to help, but promise you won't get a smackdown!
Nothing particularly useful for others here, but I added this for my benefit since the device tree
coding, syntax and resources are not very well documented in the RPi documentation (IMHO).
From an end-to-end review of the Device Tree forum, some items that attracted my attention:
-
Note: The
dtoverlay
command allows overlays to be applied at runtime (some more successfully than others). And using the -h option is useful for reading helpful details from/boot/overlays/README.
REF -
Related to above: Dynamic device tree LED
-
How to handle more than one device - e.g. multiple i2c devices on single bus?
-
how to trigger an action when input signal is detected - fuzzy, but potentially useful
-
GPIO set high/low with dtoverlays - In summary, overlays can't set GPIO pin state at boot, but dtb can!
-
PWM without root access - not re DT, but some info for PWM usage
-
phandle problems with machine driver - note diff in "target" & "target-path";
target = <&i2c1>;
-
Device Tree Overlays Using New libgpiod API? - see links for libgpiod tools & code
-
Adding Device Tree to EEPROM config file. - how to put your overlays into EEPROM (Pi4 only)
-
Two drivers using same gpio pin - follow-up on this... sounds useful
-
What is the KEY_POWER event in DT? - I still don't know
-
Re: RPi4 Ethernet LED control - a dtparam to turn off Ethernet LEDs
-
Cant turn off Power LED on Rasp Pi 4 Model B - oh yes, you can!
-
Debugging device tree with yocto - some debugging intellegence
-
Re: Set default state of GPIO to High on boot using Device Tree. - evolution of the
gpio-led
overlay -
The so-called
runtime overlay mechanism
: what is it? seeman dtoverlay
-
Understanding the behaviour of device tree compatible - in summary,
compatible
is meaningless -
ethernet phandle in overlay - however, the
phandle
is important -
Re: Supported RTCs in Device Tree - how-to: loading & unloading kernel modules
-
DS3234 RTC Device Tree overlay - worthy of study - add RTC for SPI i/f
-
Where are the source for the firmware/overlays .dtbo files - Pretty well hidden!
-
Multiple dtoverlay=gpio-shutdown line in config.txt - gpio-shutdown is just a special case of gpio-key
-
gpio-fsm - a finite state machine overlay - How about that? A FSM that uses virtual GPIOs in an overlay
-
gpio-poweroff and active-delay-ms - New options for the gpio-poweroff overlay
-
A question about flags - "overlays don't support addressing bits or boolean arithmetic"
-
how to use dtoverlay to load a different driver - but now,
compatible
is not meaningless... ?! -
Overlay source files that match the dtbo files included with distribution - find source files for overlays