Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Jan 2024 17:26:40 +0000
From:      void <void@f-m.fm>
To:        freebsd-arm@freebsd.org
Subject:   Re: enabling powerd on RPi
Message-ID:  <ZZre0H_cM6Q_l8yD@int21h>
In-Reply-To: <136EA428-CC30-4CF4-BE65-30B0CC8656AF@karels.net>
References:  <CA1990CD-EB0F-4053-A7A2-6E06CDED40DC@karels.net> <136EA428-CC30-4CF4-BE65-30B0CC8656AF@karels.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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 may=
be
>> others.  There is a bug from 2021 on the subject which has gotten some r=
ecent
>> discussion, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256836. =
 Also,
>> problems come up from time to time about performance problems because pe=
ople
>> don't know to enable powerd.  It makes FreeBSD look much slower than Lin=
ux.
>>
>> 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 fi=
rst
>> 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.=20
It would be particularly useful in a battery-powered context.

I used to use powerd a lot, but it's not needed for my own uses right now,=
=20
so it's disabled and i overclock by firstly having really efficient cooling=
=20
and then setting config.txt like this

hdmi_safe=3D0
armstub=3Darmstub8-gic.bin
gpu_mem=3D16
over_voltage=3D6
arm_freq=3D2147
gpu_freq=3D750
force_turbo=3D1

# 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=3Dcpu@0 compat=3Darm,cortex-a72=20
dev.cpu.0.%location:=20
dev.cpu.0.%driver: cpu
dev.cpu.0.%desc: Open Firmware CPU

My context here is permanently connected to the recommended PSU, headless w=
ith 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 ov=
erclock
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 conn=
ected to a rpi2b+
running 12.2-RELEASE which is used as a "console server". There is no conso=
le scrambling.
Console is invoked on the rpi2b+ with 'cu -l cuaU1 -s 115200'

=7F
--=20



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZZre0H_cM6Q_l8yD>