Re: enabling powerd on RPi

On Jan 7, 2024, at 09:26, void <[email protected]> wrote:

> On Thu, Jan 04, 2024 at 07:53:12AM -0600, Mike Karels wrote:
>> On 28 Dec 2023, at 13:11, Mike Karels wrote:
>> 
>>> I am looking at enabling powerd by default on the Raspberry Pi 4 and maybe
>>> others.  There is a bug from 2021 on the subject which has gotten some recent
>>> discussion, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256836.  Also,
>>> problems come up from time to time about performance problems because people
>>> don't know to enable powerd.  It makes FreeBSD look much slower than Linux.
>>> 
>>> The simplest action is to enable powerd by default on the arm64-aarch64-RPI
>>> images.  This would affect RPi 4 and variants, also RPI 3* and later RPi 2.
>>> I enabled powerd on an RPi 3B+, and it seems to have no issues; it seems
>>> to work.  Does anyone know of a disadvantage of enabling powerd on RPI
>>> images for all targets?  The alternative would be to configure at the first
>>> boot, although I'm not positive of a definitive way to identify the RPi
>>> variants.  Maybe just looking for a dev.cpu.0.freq sysctl node would
>>> suffice.
>>> 
>>> If no one objects, I will make changes to enable powerd on RPI snapshots
>>> for 15-current, and we can see what happens.
>> 
>> My change to enable powerd for all 64-bit Raspberry Pi systems using the
>> arm64-aarch64-RPI image is in https://reviews.freebsd.org/D43296.  There is
>> also a review that splits RPi4 from RPi3 (etc); it is
>> https://reviews.freebsd.org/D43141.  Comments welcome.
> 
> I think powerd by default would be advantageous in most use cases. It would be particularly useful in a battery-powered context.

Yep. But it may be worth a note mentioning the subject area
with the issue once it is isolated: avoiding unnecessary
surprises that are messy to track down to a specific type of
context.

> I used to use powerd a lot, but it's not needed for my own uses right now, so it's disabled and i overclock by firstly having really efficient cooling and then setting config.txt like this
> 
> hdmi_safe=0
> armstub=armstub8-gic.bin
> gpu_mem=16
> over_voltage=6
> arm_freq=2147
> gpu_freq=750
> force_turbo=1

I do somewhat similarly for RPi4B's but use 2000, not 2147:
2000 works reliably on all the RPi4B's I've access to, Rev
1.1, 1.4, and 1.5 examples involved. 2147 or 2100 does not
work on all of them. I also use a power supply that has a
little more curremnt margin than the official ones and that
contributed to my being able to use 2000 uniformly, given
what I plug into the USB3 port as types of boot media.

I also control the memory speed to be fixed at the fastest,
no matter if the RPi* firmware vintage in use does so
automatically or not. Various vintages definitely do not.

> # sysctl dev.cpu.0
> dev.cpu.0.temperature: 51.0C
> dev.cpu.0.freq_levels: 2147/-1
> dev.cpu.0.freq: 2147
> dev.cpu.0.%parent: cpulist0
> dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a72 dev.cpu.0.%location: dev.cpu.0.%driver: cpu
> dev.cpu.0.%desc: Open Firmware CPU
> 
> My context here is permanently connected to the recommended PSU, headless with serial console
> and UPS, and it needs to be responsive, which it is with this overclock.
> If I were to use powerd in this context, it would never realise the full overclock
> and shows dev.cpu.0.freq_levels: 2100/600.
> 
> Connected to it is a usb<>ttl serial cable on the rpi4's pins which is connected to a rpi2b+
> running 12.2-RELEASE which is used as a "console server". There is no console scrambling.
> Console is invoked on the rpi2b+ with 'cu -l cuaU1 -s 115200'


===
Mark Millard
marklmi at yahoo.com