Date: Sun, 7 Jan 2024 23:00:51 -0800 From: Mark Millard <marklmi@yahoo.com> To: void <void@f-m.fm> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: enabling powerd on RPi Message-ID: <FF4A9245-4BD1-454C-BBD4-7D9C483EA10E@yahoo.com> In-Reply-To: <ZZre0H_cM6Q_l8yD@int21h> References: <CA1990CD-EB0F-4053-A7A2-6E06CDED40DC@karels.net> <136EA428-CC30-4CF4-BE65-30B0CC8656AF@karels.net> <ZZre0H_cM6Q_l8yD@int21h>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 7, 2024, at 09:26, void <void@f-m.fm> wrote: > On Thu, Jan 04, 2024 at 07:53:12AM -0600, Mike Karels wrote: >> On 28 Dec 2023, at 13:11, Mike Karels wrote: >>=20 >>> 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=3D256836. 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. >>>=20 >>> 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. >>>=20 >>> If no one objects, I will make changes to enable powerd on RPI = snapshots >>> for 15-current, and we can see what happens. >>=20 >> 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. >=20 > 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 >=20 > hdmi_safe=3D0 > armstub=3Darmstub8-gic.bin > gpu_mem=3D16 > over_voltage=3D6 > arm_freq=3D2147 > gpu_freq=3D750 > force_turbo=3D1 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=3Dcpu@0 compat=3Darm,cortex-a72 = dev.cpu.0.%location: dev.cpu.0.%driver: cpu > dev.cpu.0.%desc: Open Firmware CPU >=20 > 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. >=20 > 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' =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FF4A9245-4BD1-454C-BBD4-7D9C483EA10E>