Re: enabling powerd on RPi
- In reply to: void : "Re: enabling powerd on RPi"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 08 Jan 2024 07:00:51 UTC
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: >> >>> 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