Date: Thu, 28 Dec 2023 15:12:10 -0600 From: Mike Karels <mike@karels.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: enabling powerd on RPi Message-ID: <CA2D884B-9BC5-4DCC-8229-539B8DDC6F75@karels.net> In-Reply-To: <0E56E105-2A22-460E-9C58-24074922AA18@yahoo.com> References: <CA1990CD-EB0F-4053-A7A2-6E06CDED40DC@karels.net> <0E56E105-2A22-460E-9C58-24074922AA18@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 Dec 2023, at 14:22, Mark Millard wrote: > On Dec 28, 2023, at 11:11, Mike Karels <mike@karels.net> wrote: > >> I am looking at enabling powerd by default on the Raspberry Pi 4 and m= aybe >> 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= =2E 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 L= inux. > > If performance comparison to linux is a driving issue, seeing what > linux does about sdram_freq and sdram_freq_min may be relevant. This > may be in whole, or in part, based on the RPi* firmware version the: > > https://www.raspberrypi.com/documentation/computers/config_txt.html#ove= rclocking-options > and its: > "This table gives the default values for the options on various > Raspberry Pi models, all frequencies are stated in MHz." I'm not looking to optimize everything to improve comparison with Linux; people can optimize their own systems based on things like cooling. I just want to get the low-hanging fruit here, with safe defaults. Running at 600 MHz all the time is totally suboptimal. People who want to tweak will always find more improvements. > content has varied as firmware releases have been made. But I've not > always found that the two match for FreeBSD. This might be because > they mixed firmware and linux defaults without being explicit, > something I've run into before. (I'll note that the history of the > documented defaults is available via giuthub, even if somewhat messy > as they restructured the documentation over time.) > > For the RPi4B's and Pi 400's the modern tables indicate > sdram_freq_min=3D3200 is the default. It used to be sdram_freq_min=3D40= 0 . > Recent testing of stable/14 snapshots with RPI4B's has shown the 400 > figure is in use. Only the RPi4B's, Pi 400's, and Pi5 show non-400 > defaults in the modern table. It doesn't sound like there is a single, universal change to be made to optimize sdram in config.txt or rc.conf. I think the most we could do is to add notes as comments, but many people probably never look at config.txt. > Another such example is that RPi4B Rev 1.4+ is documented to have > arm_freq=3D1800 by default if arm_boot=3D1 in config.txt . Otherwise > RPi4B's are documented to use 1500 as the default. > > But FreeBSD does not end up with the documented figures: ending up > matching the default arm_freq_min=3D600 instead of (all but Pi0/W, > Pi1, and Pi 5 are documhted to have the 600). My guess is that > FreeBSD makes its own assignments. Note that the default > arm_freq_min is model dependent if Pi0/W, Pi 1, or [someday] Pi 5 > are to be covered. > >> The simplest action is to enable powerd by default on the arm64-aarch6= 4-RPI >> images. This would affect RPi 4 and variants, also RPI 3* and later R= Pi 2. >> I enabled powerd on an RPi 3B+, and it seems to have no issues; it see= ms >> to work. Does anyone know of a disadvantage of enabling powerd on RPI= >> images for all targets? > > Serial port configurations that attempt to use the mini-uart have > problems with core_freq changes changing the serial console > frequency in use. (mini-uart used for bluetooth instead has such > issues too.) Which UART is used by default varies by model, the > bluetooth capable families (so, e.g., not Pi2) having the > mini-uart for the serial port and full UART for bluetooth. (I'm > not clear on the v1.1 vs. v1.2 for the RPi2B's.) core_freq and > core_freq_min also vary by model. > > There is a core_freq_min. core_freq and core_freq_min defaults > are documented as model specific. hdmi_enable_4kp60 use > changes the default for core_freq and core_freq_min as well. > There is enable_uart=3D1 to force the core clock to be fixed > for seerial use, which frequency is dependent on force_turbo=3D1 > vs. not. It sounds like using the mini-uart will require config changes in any case. I'd also be surprised if many (any?) FreeBSD users are using the mini-uart at all. Anyone know? > I do not know what FreeBSD does about such things if it does > not match such documentation. > > There is: > > https://www.raspberrypi.com/documentation/computers/configuration.html#= configuring-uarts > > that says, in part, > > QUOTE > In order to use the mini UART, you need to configure the > Raspberry Pi to use a fixed VPU core clock frequency > END QUOTE > > I'll also note that arm_64bit=3D1 is the default for the RPi4B's, > Pi 400, CM4, and CM4S these days, but not for the rest that are > 64=3Dbit capable (ignoring RPi5's, which do not have the parameter). > I do not know what FreeBSD does about such things if it does > not match such documentation. In the current config.txt, arm_64bit=3D1 is in the [all] section. >> The alternative would be to configure at the first >> boot, although I'm not positive of a definitive way to identify the RP= i >> 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 snapsho= ts >> for 15-current, and we can see what happens. Any objections? Anything else we should do by default? Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA2D884B-9BC5-4DCC-8229-539B8DDC6F75>