UserCTL.xyz

Adding a power button and status LEDs to you Raspberry Pi

Fri, 24 Jun 2022 12:00:00 +0000

Following the release of my MP-1 Rack collection, I wanted to share some more details about how I added a power button, a power status LED, and an activity LED to my Raspberry Pi module.

Finding the right configuration was not as easy as it seems, and as I wasn’t able to find a single source where both a power button and some status LED were added together, I ended up testing quite a lot of different setup. The ultimate goal being to be able to handle as much as possible without using important buses, having to solder extra pins or requiring any software on the Pi itself.

Adding a power button

Adding a power button to my Raspberry Pi was relatively straight forward once I understood how the gpio-shutdown overlay worked and which pin to use to restart the Pi once it was powered off.

The important part here is to know that, starting with the Raspberry Pi 1 B+, you can restart a powered off board by bridging the GPIO3 pin (Pin 5) to Ground. By knowing that, we can also configure the gpio-shutdown overlay to use this same pin to cleanly shut down a Raspberry Pi when it’s on.

So, in order to add a power button to my Pi, I connected a momentary push button between those two pins as follows:

Then update the /boot/config.txt file to include the following:

dtoverlay=gpio-shutdown,gpio_pin=3,debounce=1000

This configures the gpio-shutdown overlay to use the GPIO3 pin for shutdown with a debounce value of 1000 ms (1 second) meaning that the button needs to be pressed for at least 1s before the Pi starts its shutdown procedure. This parameter is pretty useful to prevent accidental triggering.

The only issue with using this setup to handle power management is that the GPIO3 pin is also used by the I²C bus as the SCL Pin thus requiring I²C to be disabled. If this bus is required, a more complex setup might be possible but has not been investigated here.

Note

Using gpio-shutdown to power off a Raspberry Pi does not completely cut power to it, it only puts it in a halted state (similar to what happens when running poweroff or halt on it). It will still consume a negligible amount of power.

Adding a power status LED

Things started to get a little harder once I tried to add a power status LED. A lot of different setup have been documented on the internet such as wiring it to the UART TXD pin, but I felt like using the UART bus this way wasn’t a clean solution.

Another issue I found was most of the setup were using pins that are pulled up to 3.3V when the Pi is powered off (pin 1 to 8 are pulled up by default, requiring a pull-down resistor to be used properly). This can be a nice side effect if you wish to have a dimmed LED when the Raspberry Pi is powered off, but this wasn’t what I was looking for.

In the end I decided to use the GPIO17 pin (Pin 11) with the GPIO control directives available in config.txt to drive it high on boot. As this pin is not pulled-up by default, the LED will be completely off when the Pi is off.

Using a 3 mm 2.2V 20mA red LED with a 3.3 kΩ resistor (to reduce its brightness), I installed it between GPIO17 and Ground as follows:

Then updated the /boot/config.txt file to add the following directive with instruct the system to drive the GPIO17 pin high on boot:

gpio=17=op,dh

This setup can be adapted to any other GPIO pin available on the board with the caveat about pulled-up pins previously described. A pretty neat setup I tested “abusing” this caveat was to use the GPIO2 pin using gpio=2=op,dh to have a dimly lit LED when the Pi is off and a brighter LED when it’s on.

Adding an activity LED

Finally, it was time to add an external activity LED, this was pretty easy once I stumbled upon the act-led overlay. This overlay is easy to configure as it only really requires a GPIO pin but can be customized using the act_led_trigger parameter to choose which event should trigger it.

The choice of the GPIO pin to use had to follow the same logic as for the power status LED, but I really couldn’t use a pulled-up pin here as I didn’t want it to light up at all if nothing happened on the Pi. In the end I decided to use the GPIO27 pin (Pin 13) as it was near a ground pin, close to GPIO17 and not pulled-up by default.

Here I used a 3 mm 2.2V 20mA yellow LED with a 4.7 kΩ resistor (still to limit its brightness) wired between GPIO27 and Ground:

Finally, updating the /boot/config.txt one last time to add act-led overlay configuration:

dtparam=act_led_trigger=mmc0
dtoverlay=act-led,activelow=off,gpio=27

Here I set the act_led_trigger to mmc0 which will make the LED react to filesystem usage on the SD card of the Pi. This could be set to any of the other triggers available from the following list:

none No trigger
kbd-scrolllock Keyboard scroll lock
kbd-numlock Keyboard num lock
kbd-capslock Keyboard caps lock
kbd-kanalock Keyboard kana lock
kbd-shiftlock Keyboard shift
kbd-altgrlock Keyboard altgr
kbd-ctrllock Keyboard ctrl
kbd-altlock Keyboard alt
kbd-shiftllock Keyboard left shift
kbd-shiftrlock Keyboard right shift
kbd-ctrlllock Keyboard left ctrl
kbd-ctrlrlock Keyboard right ctrl
timer Flash at 1 second intervals
oneshot Flash only once
heartbeat Flash like a heartbeat (1-0-1-00000)
backlight Always on
gpio Flash when a certain GPIO is high???
cpu0 Flash on cpu0 usage
cpu1 Flash on cpu1 usage
cpu2 Flash on cpu2 usage
cpu3 Flash on cpu3 usage
default-on Always on
[input] Default state
panic Flash on kernel panic
mmc0 Flash on mmc0 (primary SD Card interface) activity
mmc1 Flash on mmc1 (secondary SD Card interface) activity
rfkill0 Flash on wifi activity
rfkill1 Flash on bluetooth activity

Thanks to Ameer on the Raspberry Pi Stack Exchange forum for creating this list.

Final setup

In the end, if we put everything together we can achieve quite a nice setup without requiring any extra software on your Raspberry Pi that handles:

a power button to shut down and reboot your Raspberry Pi
a power status LED lighting up when the system if on
an activity LED reacting to file system

The final wiring diagram should look like this:

And the /boot/config.txt file should have the following lines at the end:

# Power button
dtoverlay=gpio-shutdown,gpio_pin=3,debounce=1000

# Power status LED
gpio=17=op,dh

# Activity LED
dtparam=act_led_trigger=mmc0
dtoverlay=act-led,activelow=off,gpio=27

Paired with the MP-1 Rack Raspberry Pi module, this setup allowed me to achieve my goal of having a rack mounted solution with power controls and feedback for my Pis. And I hope it helped you too if you were looking for something similar

References

Building the MP-1 Rack collection: a modular racking system

Mon, 20 Jun 2022 21:00:00 +0000

After receiving my long awaited ZimaBoards, I was looking for a solution to install them in my 19" rack easily before starting building my Kubernetes cluster.

I’ve seen in the past some modular racking setup for the Raspberry Pi such as the Pi Blade McPiFace from Stephen Harrison, the RackPi 3D model by Daniel Reinke or the Raspberry Pi Rack covers made by Daniel Mostosi that I really liked. The common denominator between all of them being the use of the DAP Audio MP-1 modular rack frame as a base.

I decided to take inspiration from those existing modules and build my own modules for the MP-1 frame to achieve the perfect modular rack I wanted that could house my 4 ZimaBoards, a Raspberry Pi and some keystone jacks. This started by ordering the frame and some official blanks for reference.

The DAP Audio MP-1 Modular Frame

While waiting for my order to arrive, I started looking around for some dimensions to start designing each mount. There isn’t much data available on the internet and the main resources for dimensions was the previously mentioned 3D models.

Once I received my order, I took the time to measure everything before installing the frame to help others build their custom modules in the future.

The frame is a 2U 19" rack panel made from 2 mm bent sheet metal consisting of two 9 mm wide rails and a 441 mm × 70.3 mm center opening. Each rail has ten 3 mm untapped screw holes, though the panel is delivered with the required self-taping screws required to attach your modules. Those dimensions provide space for ten 44.1 mm × 88.3 mm segments, which was confirmed by their blank module measurements.

Here is a drawing of the dimensions I was able to measure from the frame itself and from the official one and two segments blank face plates available on the Music Store website.

The MP-1 Rack collection

Now that I had my base, it was time to build the modules to fill in the frame with my small computers. I ended up building a collection of four modules to fit everything I needed:

a ZimaBoard mount that can accommodate up to two 2.5" hard drives
a Raspberry Pi mount with a power button and front facing HDMI port
a keystone module in two size to house either 2 or 6 jacks
a blank module to fill in empty spaces

ZimaBoard module

I started by first building the ZimaBoard mount, the requirement here was to create a simple but effective way to mount it with spaces for two 2.5" 9.5 mm drives. I first looked at integrating an existing hot-swap solution such as the Icy Dock flexiDOCK MB522SP-B in my model, sadly, those 3.5" modules are too large to fit in the 2 segments space I wanted this module to take (so I can fit 4 of them on one frame).

In the end, adding some simple rails under the mount was the solution I went with, it does not provide any hot-swap capabilities but works extremely well with the official SATA Y Cable.

Raspberry Pi module

I then went on to create my own Raspberry Pi module, as said in the introduction existing solutions already exists, but none had both space of a front-facing HDMI port and some LEDs / buttons. This started with just a simple mount and cutouts, I decided to use heat-set insert as a mounting solution here to strengthen the connection between the Pi and the module.

Following that, I added both a space for a 6 mm × 6 mm momentary switch and two 3 mm LEDs that I have configured as a gpio-shutdown trigger, a simple power LED, and an HDD activity led (more details is available on this model Printables page).

Finally, I added a keystone jack mount, so I can use one of those slim FPV HDMI cables and an HDMI keystone to add a front facing HDMI port (as those cables are also available as mini-HDMI to HDMI, this solution can also be adapted for the Raspberry Pi 4).

I decided to publish multiple variants of this specific model module as I understand that not everybody wants some shiny LEDs or spent the necessary cash to add the front-facing HDMI port. I’ve also added a screw-in version of each variant if you do not want to use any heat-set insert to mount your Pi.

Extra modules

Now that I have a keystone jack footprint, I decided to add two modules to the collection that just allows you to attach some keystone to your frame: a small one segment module that can house 2 jacks and a two segments module for 6 jacks. This ended up being quite a handy way to cleanly connect my router to my rack without having an exposed long cable.

I also added one segment and two segments blank modules to the collection to provide an easy way to plug your empty slots if you haven’t bought the official ones with your frame or to use as a base when creating your own modules.

Download the collection

You can find all those models with their Fusion 360 source files in the MP-1 Rack collection on Printables as well as a standalone version of the ZimaBoard mount to use a simple desk stand.

I really hope this collection will help others create their perfect mounting solutions for their small single board computer and inspire more people in building modules for the MP-1 frame!

Announcing BerryOS: a lightweight OS for your Raspberry Pi

Mon, 30 May 2022 22:00:00 +0000

After a couple of weeks working on it, I am proud to finally be releasing the first version of BerryOS to the public!

What is BerryOS?

BerryOS is a lightweight operating system for your Raspberry Pi based on the official Raspberry Pi OS Lite bootstrapped directly from its sources. It is available in two variant: BerryOS/armhf and BerryOS/arm64 for 32 & 64-bit ARM compatible hardware.

When building it, my goal was to create a lightweight version of Raspberry Pi OS Lite than can be configured headlessly at first boot using cloud-init. Other images including cloud-init already exists such as the Ubuntu Server RPi release or the now defunct HypriotOS, though most of them includes extra software or are not based on Debian itself.

In order to keep the same level of compatibility with 3rd party software and hardware, I decided to bootstrap it directly from the Raspberry Pi OS sources (Raspbian GNU/Linux and Debian GNU/Linux for its armhf and arm64 version respectively) with some tweaks to the list of pre-installed package and default configuration.

In the end, BerryOS turned out to be nearly 40% lighter than Raspberry Pi OS Lite, had fewer processes running by default while being completely configurable using cloud-init.

Here is a comparison table between the first BerryOS release (BerryOS Bullseye 2022.05.30) and the latest Raspberry Pi OS Lite release (Raspberry Pi OS Bullseye 2022.04.04) running on a Raspberry Pi 3 B:

Stat	BerryOS/armhf	RaspiOS/armhf	BerryOS/arm64	RaspiOS/arm64
RAM usage	37M	57M	52M	72M
Running processes	12	18	12	20
Disk usage	807.1M	1.3G	611.7M	1.3G
Pre-installed packages	312	530	285	521
Download size	201M	297M	153M	271M
Image size	1312M	1924M	1112M	1908M

The methodology for these results can be found in the Benchmark section of the BerryOS README file.

Where to get it?

BerryOS is completely open-source and licensed under the ISC License. Its source code is hosted on GitHub at github.com/0rax/BerryOS.

From there, you can download all current and previous version of each variant or checkout its documentation (which is still a work in progress) where you will also find some example configuration files to get you started.

If you decide to give it a go and find any issues with it, do not hesitate to report them on GitHub, so they can be fixed as soon as possible.

How to use it?

Grab your closest Raspberry Pi and your SD card of choice, head to the latest release page and download the variant you need.

BerryOS/armhf should be compatible with ALL Raspberry Pi models.
BerryOS/arm64 should be compatible with the Raspberry Pi 3B, 3B+, 4 & 400, Compute Module 3, 3+ & 4 as well as the Raspberry Pi Zero 2 W.

Fire up you favorite tool and flash your newly acquired image to your SD card. Any flashing tools should work, such as the official Raspberry Pi Imager, balenaEtcher, Hypriot’s flash tool or even dd on any *NIX like system.

Note

Hypriot’s flash tool can be used pretty efficiently with BerryOS as it allows you to specify extra configuration file to copy to your SD card after flashing directly from the command line.

For example to flash BerryOS with a custom user-data and config.txt file you already have on disk, you can just run:
flash --userdata user-data.yaml --bootconf config.txt ~/Downloads/berryos-arm64-bullseye-20220527.img.xz

Once successfully flashed, unplug and re-plug your SD card from your computer (to force remounting it) and open the drive named boot. You should be able to open the user-data file with your favorite text editor from there.

user-data is the configuration file that will be used by cloud-init to configure your system on its first boot. We have set it up to use the Cloud Config format as it makes configuring a system really simple, though other format are also available.

This is a really important file when setting up a BerryOS system, as this is where you will set up how to access your system.

Note

By default, BerryOS does not enable password based SSH access to the default user to follow the decision made by the Raspberry Pi Foundation in April 2022 to disable it on Raspberry Pi OS Bullseye going forward (source).

I would suggest going through the whole file (also available on GitHub) and read the comments to understand what you are able to configure using it. You can also have more extensive explanation of the configuration capabilities in the project documentation.

Here we will just update the default user (pi) password and enable SSH password authentication and set the system hostname. To do so, append the following lines to the user-data file:

hostname: berryos.userctl.xyz  # Set system hostname
manage_etc_hosts: true # Update /etc/hosts with the new hostname

password: berryos  # Set default user password
chpasswd: { expire: false } # Do not expire password after first login
ssh_pwauth: true # Enable SSH password authentication for default user

The password field can either be a plaintext password or a hashed version of it. On *NIX system, a password can be hashed using the openssl passwd -6 command. The file would end up looking like:

password: $6$kEE0sV/2tz/jWBtQ$tRpM0XqKhl3xEroj837u6VCQadIoSL......nSY48unRmtsZv0
chpasswd: { expire: false } # Do not expire password after first login
ssh_pwauth: true # Enable SSH password authentication

If you wish to assign a static IP to your Raspberry Pi, you should also edit the network-config file. For example, to assign the 192.168.1.128 IP to your Pi with a /24 netmask (equivalent to 255.255.255.0) and 192.168.1.1 as gateway, you should update the file to look like this.

version: 2
ethernets:
 eth0:
 dhcp4: false
 addresses:
 - 192.168.1.128/24
 routes:
 - to: 0.0.0.0/0
 via: 192.168.1.1

Save your modifications, un-mount your SD card and insert it in your Raspberry Pi. Connect you Ethernet cable and power supply, and after some time you should be able to access it using ssh pi@$ip.

As avahi-daemon IS NOT installed by default, you will not be able to use the Pi hostname to connect to it. If you haven’t given it a static IP, you will need to find it another way. The easiest solution is to plug a screen to it as BerryOS prints the system IPs on each TTY by default (you might need to switch to TTY2 to get a clean reading by using Alt + Right). Another solution is to check your router’s DHCP assignation table.

Note

If you require Wi-Fi connectivity, you should check out the Network Configuration guide in the BerryOS Wiki to set it up properly.

Congratulation, you can now enjoy BerryOS to its full extent!

The future of BerryOS

BerryOS is the operating system I with I had for quite some years now, thus I intend to support and keep it up to date with mainstream Raspberry Pi OS for the foreseeable future.

Having a lightweight alternative to the default operating system for your Raspberry Pi is the real goal here, something than can be used by anyone that just want to tinker a bit more with their hardware and have more control over its software. I do not want to create a complete new ecosystem but keep it as close and compatible with RaspiOS as possible without adding unnecessary software or removing capabilities.

The clear next step for the project now is to expand its documentation and add more example of how cloud-init can be used. Those Cloud Config files are great to share setups with each other and having great resources built around this possibility should be what we aspire to.

If this is something that you find interesting, come check it out, or even get involved with the project on GitHub.