Inadequate power supplies seem to be a prevailing challenge for both new (and old) Raspberry Pi users.
As the Pi's become more powerful they also require more power, so the power supply that worked with the Pi2, could result in under-voltage warnings on the Pi3.
Those with a display connected get an indication that something is up with the lightning symbol, and those that run headless see the power led turning off.
Unless one pays attention to those indicators, there is no way to tell when under-voltage happened except that 'vcgencmd get_throttled' can tell that it did happen at some point during this run.
I have wanted for some time to improve on this situation, by finding a way to log these events.
So I figured I should just allocate some time to this and see if it was possible to find a solution that could be included in Raspbian.
Since I mainly do kernel development, my first impulse was to do it in the kernel, especially since I wanted the event to be communicated across a reboot.
If an under-voltage event results in a kernel crash and the watchdog ends up resetting, it would be nice to know about that.
It turned out that the status register which is preserved across reboots is fully utilised, so one of the reasons for doing it in the kernel fell away.
Another thing is that there's currently no (easy) way to do this except by polling, so it might as well be done in userspace.
My current idea is to write a systemd service in python that polls get_throttled and reports the event to the kernel log. It will also write to a file which will be read on startup so we can write a message to the log that an under-voltage event happened during the previous run.
There are couple thing that needs to be decided regardless of logging implementation:
1. How often should we poll
This depends on the cost of doing polling vs. the precision we want. Does anyone know if the firmware itself polls to find out? If so it would be nice to know it's polling period.
2. What kind of events should we have
Since we have to poll, we loose precision. We can know two things: That an event has happened and whether or not it is happening right now.
When set, we report under-voltage and then report when it's over. Every time? I guess we need some threshold to avoid spamming the log.
16: under-voltage has occurred
Bit set but we haven't seen bit 0 set, report under-voltage event. Probably distinguish between one detected in the first poll on startup and one that happens between two polls.
3. Where to log
I assumed the kernel log for an event like this, but I don't know where people generally go looking if something strange/erroneous is happening.
Lightning bolt and vc4:
The firmware is able to put an icon on the display because it knows where the framebuffer is in memory (and it's layout) since it handles allocation on behalf of the fbdev driver. When using the vc4 driver, the firmware doesn't know where the buffer is, so it can't put up a symbol.
In time we will move to vc4, so at some point we need a new way to communicate under-voltage to the desktop.
It would be nice to get some feedback on this project to get a broader picture before trying an implementation.
Maybe some simple lightweight monitoring framework already exists that can be utilised for this purpose.