I’m trying to set all GPIOs to output high at boot using the official firmware line in /boot/firmware/config.txt:
gpio=0-27=op,dh
I’m running DietPi 6.12.47+rpt-rpi-v6. According to the Raspberry Pi documentation , this configuration is valid.
Observations:
Some GPIOs keep the wrong value:
GPIO 0 and GPIO 2 remain at 0
GPIO 1, GPIO 4, and GPIO 5 remain in input
Is this expected behavior on DietPi? Any way to make this line reliably set all GPIOs to output high at boot?
This configuration works correctly on an older Raspbian installation I have (kernel 4.19.118+), where all GPIOs are properly set to output high at boot.
On the ancient 4.x kernel it was possible, but with newer kernel and firmware stack the pins 0 and 1 are reserved for hat/board detection, see: datasheets.raspberrypi.com/hat/hat-plus-specification.pdf
Pins 2 and 3 are default I²C pins.
Pins 4 and 5 are probably also reserved by some device tree.
This is not a DietPi version. It’s the official RPI kernel 6.12.47. We don’t have own kernel build as we use the official RPI kernel for RPI SBC’s. Current DietPi version is 9.17
This is an extrem old RPI kernel used in Debian 10 Buster, you would need to compare this wir current RPI OS systems (Debian Bookworm or Trixie)
Unfortunately, this didn’t change the behavior — the same GPIOs (0, 1, 2, 4, 5) still remain in their previous states after boot.
At this point, I’d like to confirm whether the firmware is actually parsing and applying the gpio=0-27=op,dh directive.
Is there any way to verify this, e.g. through a firmware or boot log that would show GPIO initialization or overlay processing?
Thanks for the clarification, and my apologies for the confusion about the version earlier.
I’m indeed running DietPi v9.17 (Bookworm) on the official Raspberry Pi kernel 6.12.47+rpt-rpi-v6 (Raspberry Pi 1).
As a test, I manually configured each GPIO using WiringPi, setting them to output mode and writing a high value — and in that case, it works correctly.
So it seems the pins themselves are fine, but the gpio=0-27=op,dh directive isn’t being applied as expected during boot.
I’ll also run the same configuration on a recent Raspberry Pi OS (Bookworm) installation to confirm whether the behavior is identical there.
Thanks again for your clarification and help tracking this down.
As I already wrote:
Pins 0 and 1 are reserved internally for ID EEPROM (hat detection), it may worked with older firmware like you used with you 4.x kernel. Also possible that some overlays changed in the meanhwile.
Pins 2 and 3 are probably mapped from a device tree
pins 4 and 5 are mapped from internal functions like PWM, Wifi or other kernel drivers
You can also check which overlays are active on your system with:
The firmware prioritizes overlays and kernel drivers over your settings from config.txt, that’s why they are not applied.
If you need the pins at boot in the desired state, you need to change your device tree overlay.
If it is okay for you to change the state of the pins after boot, you can use pinctrl, it should be installed by default I guess. If not you can install it with: apt install raspi-utils-core .
You can of course automate this, so it’s applied after every boot automatically. For example with a systemd service or with a simple script in your crontab.