Bug 256836 - powerd: Enable by default on Raspberry Pi images
Summary: powerd: Enable by default on Raspberry Pi images
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 13.0-RELEASE
Hardware: arm64 Any
: --- Affects Many People
Assignee: freebsd-arm (Nobody)
Keywords: feature, needs-patch, performance
Depends on:
Reported: 2021-06-25 19:18 UTC by Vincent Milum Jr
Modified: 2021-09-26 22:47 UTC (History)
1 user (show)

See Also:
koobs: mfc-stable13?
koobs: mfc-stable12?


Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Milum Jr 2021-06-25 19:18:17 UTC
During a normal installer process, the installer asks if a number of services should be enabled by default. On the Raspberry Pi pre-built image, this is a pre-installed system where these configuration options are never presented.

By default, the Raspberry Pi 4 is locked to only 600 MHz unless powerd is running.

There is currently no obvious way to know that the performance of this board is being limited without digging into sysctl. This could lead users to assume that "FreeBSD is unoptimized and slow" compared to other OSes.

Right now, the only note I'm aware of about this particular issue is at the very bottom of a Wiki page. This isn't a good end-user experience to have to hunt down this information, especially if they don't even know what to look for to begin with.


Because of these, I believe that powerd should be enabled by default in the Raspberry Pi specific images that are generated.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2021-06-26 01:54:53 UTC
@Reporter Can this change proposal be interpreted as 'installer: Show service screen to ARM and/or RPi build/image users ' as in, is this relevent, useful or valuable to users for services beyond powerd either at present or in the future?
Comment 2 Vincent Milum Jr 2021-06-26 02:48:52 UTC
It might be nice to show part of the installer process during "first boot"

In regards to powerd specifically though, the Raspberry Pi 4 is severally limited in compute power without it running, since it defaults to ~1/3rd its rated clock speed. This has a significant end-user impact.

But yeah, right now, no "installer" is displayed at all for the Raspberry Pi, since it is a pre-built image. If we could at least get some sort of message on boot, or an interactive menu on first-boot, that would at least be a start (plus allowing for other service configurations too)
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2021-06-26 02:55:27 UTC
(In reply to Vincent Milum Jr from comment #2)

Thanks Vincent. Could you please create a separate issue for 'installer: Enable service configuration on <relevent arch/build scription>" and See Also: this issue

Can/should this be addressed in supported stable/* branches, and/or enabled for next patch levels of existing releases?
Comment 4 Daniel Engberg freebsd_committer 2021-06-28 22:41:44 UTC
As much as I understand the intention I think we should try to keep all platforms and/or arches as consistent as possible. Similar topic has been up for discussion regarding kernel configuration between aarch64 and amd64 primarily.
Comment 5 Vincent Milum Jr 2021-06-29 00:44:50 UTC
This wouldn't be a kernel config change though. This is a single-line addition to the rc.conf specific to the Raspberry Pi pre-built image, which also has other Raspberry Pi specific customizations (like u-boot).

Normally I'd agree to keep everything as close to the same as possible, but in the case of the Raspberry Pi image specifically, the hardware is severely limited in performance without this. That's not a good experience for end-users trying out FreeBSD for the first time (a common use case for the Raspberry Pi).

We're used to x86 systems that default to a high-power state unless powerd is enabled. Raspberry Pi is acting in the opposite fashion, defaulting to a lower-power state. If we want things to be consistent, then enabling powerd seems more like a requirement then to bring the system more in-line with x86 default expectations.