BalenaOS boot time

Product support
1

I’m seeing boot times of 1-2 min until containers start up on a Raspberry Pi 4. Some searching here suggests this is basically expected but definitely not great from a product POV. If the Pi boot time can’t be improved, has anyone found a way to hack Balena and the Pi to control hardware (show some LED animation, or play sound) outside of Docker to indicate to the user that something is happening? I thought of connecting a simple module to the power header pins but this doesn’t know how to stop after boot is done.

2

Hello and welcome to the forums! This is a great question and one I have thought about too. I think trying to “hack” the Pi to control hardware before boot up would be challenging, so an external hardware device would probably be easier. Keep in mind that GPIO 1 - 8 should be logic high upon power up and the others logic low. We could use that to our advantage by connecting a Pi Pico and some LEDs or such which is cheap enough but would require some programming.

A more passive solution would be to connect a buck converter that features an enable pin to the Pi. (like this one ) It could be powered from the Pi’s 5V pin, and the enable pin connected to a GPIO that defaults to high. Then connect an LED (or flashing LED) to the output of the buck converter and label it something like “wait”. After boot up, have your code switch the enable pin to low, which should turn off the buck converter and LED.

I’m interested to see if anyone else has a suggestion to share!

1 Like
3

Hi,

I think the tricky bit is the part where you say “outisde of Docker”.
Is there a specific reason you don’t want to solve this issue within your container?

Within your container, you are free to do whatever you want, and in my own application, I drive an external LED (using GPIO) to indicate when my application is running.

You could hack the HostOS, to drive a GPIO once the kernel is loaded.
This would mean either:

  • Building your own variant OS;
  • Mounting the root partition RW, and making some changes.

In both cases, updating the Host OS becomes problematic.

I wonder if there are any devicetree overlays that could be used for this; that would move the whole issue to the device configuration, which IS retained when updating devices.

1 Like
4

@TJvV the reason for trying to solve this “outside Docker” as I understand it is because it can take 1 - 2 minutes for a container to start on some devices. We were looking at solutions for that initial period where Docker/containers are inaccessible, yet we’d like to control a status LED or something similar without modifying the HostOS.