Extreme Pi Boot Optimization

Power is really one of the weaknesses of the rpi family (I'm quite excited for the new pico 2 for exactly this reason - it seems like they're finally making it easy to enter a relatively deep sleep without external hardware).

I built some cameras for an application like this using a Google Coral mini, whose camera is not nearly as good as the HQ cam, unfortunately, but it supports a built in suspend + wake from onboard RTC that is very easy to use and perfect for a periodic camera app - while still having enough oomph and 2GB of memory to handle a high resolution image. (You can physically hook an HQ camera up but the software pipeline doesn't exist to manage it on the coral AFAIK.)

The Rpi ecosystem is a lot more mature and (sorry, friends) I trust the future availability of rpi more than I trust Google to keep delivering the coral line, but it really underscored how helpful good power support in the hw was.

(Ironically, we ended up outsourcing the next version of these cameras to a firm that built them using an rpi and we just threw in a much larger battery to compensate. Which means I have a stack of 100 unopened coral dev minis + cameras looking for either good ideas or to sell to someone. Oops.)

You can still save quite a bit by bundling your application in an initramfs linked into the kernel, which obviates the needs for any filesystem mounts in simple cases.

In some cases, you can even replace something like BusyBox init with a simple bash script that does the bare minimum to boot your application. Mounting devtmpfs, proc, sysfs, etc. Dumping glibc is also worth exploring, if feasible.

Chroot is a good tool to test your initramfs and see if all the necessary application dependencies are present before bundling it into the kernel. If you can run it in a chroot, the kernel can run it during boot, and the development loop is much tighter.

Disabling kernel modules and enabling only the features needed linked into the kernel will save further space and boot time.

It would also be helpful to test zstd compression instead of gzip.

Two other good articles on decreasing Pi boot times are:

- https://www.furkantokac.com/rpi3-fast-boot-less-than-2-secon...

- http://himeshp.blogspot.com/2018/08/fast-boot-with-raspberry...

I used these two to make a digital photo frame with a Pi that boots very quickly to a browser in kiosk mode. If you have very minimal requirements, you can get some very impressive boot times.

The real tragedy is the proprietary bootcode.bin gpu code that is a blackbox and we don't have the source code for.

How horrible that a tinkering/hobbies project has to have these hidden secret blackboxes that can't be modified.

I like the article as a whole, but I'm unsure about this point:

> For example: Disabling CPU turbo just to save some current consumption is a bad choice, because the resulting extra time will use more energy than just getting the job done quickly and shutting off.

In one of my computer engineering classes, I learned that power consumption rises as the square of clock frequency - so doubling the clock will quadruple the power.

That seems like it'd imply that you'd actually have to measure the power difference to determine if the quadratic increase from the clock boost will outweigh the product of the constant power consumption with the additional time spent on the task.

Related - it'd be nice if the Pi's CPUs included granular power consumption information, either derivable from the datasheet, or as real-time values exposed in registers.

Impressive. But every time I read one of these pieces I remember when I recorded Plan 9 booting on a Pi Zero: https://taoofmac.com/space/blog/2020/09/02/1900#resurrecting (GIF is real time output).

IMHO boot times of Linux distros in general are rather sad, which is then significantly amplified on weak(er) hardware such as this. I've gone through similar efforts with the MQ-Pro SBC. One can also really feel this on laptops (except Macbooks I guess). Annoying.

My first instinct: can we use some other core? Do we really need Linux to take a photo and transfer it to the cloud?

I'm not a hw person so curious how to complete the task with minimum budget.

Interesting read. Thank you!

I wondered why a custom kernel came so late. If you want to optimize, wouldn't you start with LFS or some source-based distribution? Autonomous software updates don't seem to be a necessity anyway on such a device.

In addition, I wonder if it would be possible to optimize the EFI/BIOS on such a device. At least on my standard Arch Linux desktop, it takes a significant amount of boot time:

  $ systemd-analyze 
  Startup finished in 10.076s (firmware) + 1.339s (loader) + 1.569s (kernel) + 2.974s (initrd) + 3.894s (userspace) = 19.854s

3.5s is cool, but if the entire scenario was really connecting to WiFi and uploading an image every couple of minutes, an ESP32 would've been a much better choice for power consumption (unless the camera module you need for Pi has some specific features that none of the esp32-cam compatible cameras does)

Just stay booted and use a lower power microcontroller … 105mA … that’s not the right order of magnitude

Why did I always had impression that decompressing data is much faster than reading inflated data off disk? Like, if you need to read just 5MB and decompress it would take less time than just to read 10MB off a disk, for example, but this article kinda states the otherwise.

Ok decreasing the regulator voltage was a real surprise! I thought switching regulators would be far more efficient at higher voltages! (Less current = less heat)

I was thinking that Circle (https://github.com/rsta2/circle) might be faster to boot than a kernel, but it doesn't seem to support MIPI cameras.

Very impressive. I've toyed with using the Pi for an intelligent trail camera. Startup time is critical - a PIR sensor detects an animal passing and you want to be taking photos ASAP so every second counts.

Lowering the power usage is awesome too.

I wonder if booting the OpenBSD kernel would be faster. Although, the OpenBSD init system is notoriously slow.

Also I feel (but don't know for sure) most of the time before executing the user space program would be spent by systemd.

If you like Rasp Pi ecosystem you might want to try the Pi Pico W, it's similar in spirit to microcontrollers like ESP32 but allows you to use micropython and has a neat set of peripherals that work "out of the box": https://shop.pimoroni.com/products/raspberry-pi-pico-w?varia...

Supposedly on the Pi 5, the SoC could be put to sleep while RP1 remains active, and the RP1 has enough compute to handle like 4 or 8 pixels of data from an attached camera... I think RPi might be able to get much better suspend support with their new PMIC and RP1. But so far still waiting to see something handy like Wake on LAN support native in Pi OS.

It is such a shame the RPi Zero2 does not support "traditional" sleep modes like the ESP32 for example - which is why we have to optimize the Linux boot process. https://forums.raspberrypi.com/viewtopic.php?t=243719

Assuming it stays up for about 10-15s this is a saving over staying idle of around 85%, based on the idle burn rate from toms hardware. Not bad at all!

Is the Pi connected to the network with a static IP? Getting a fresh one from DHCP can, in this context, take quite a bit of time and energy.

Three seconds? A purpose built trail cam is considered slow if it takes 0.7 seconds to boot up and take a picture.

0.15 s is the going rate these days.

Ehm instead of spending like weeks on this why not use a hardware that is meant for such applications like an ESP32?

According to the back of my jar of mayonnaise there is 8400kJ stored in it, enough energy to power this rpi for ~62 days. This is probably a stupid question but just out of curiosity, why do people express electrical energy in Watts per second or Watts per hour instead of Joules. Unless school physics has deserted me completely 1 Ws = 1J no?

Why not just boot baremetal, something like rsta2/circle?

Was expecting to see different governors tested.

Is that not a thing on a pi?

Lovely project

You really should look into using the right hardware for the purpose instead. (Disclamer - I despise Raspberry and their overpriced closed devices, and also HN maniacally trying to use them for stuff they the wrong choice for)