Date: Thu, 28 Dec 2023 16:56:54 -0800 From: Mark Millard <marklmi@yahoo.com> To: Mike Karels <mike@karels.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: enabling powerd on RPi Message-ID: <1DDBE6DE-2BEC-4061-939E-4C87C3E276B3@yahoo.com> In-Reply-To: <CA2D884B-9BC5-4DCC-8229-539B8DDC6F75@karels.net> References: <CA1990CD-EB0F-4053-A7A2-6E06CDED40DC@karels.net> <0E56E105-2A22-460E-9C58-24074922AA18@yahoo.com> <CA2D884B-9BC5-4DCC-8229-539B8DDC6F75@karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 28, 2023, at 13:12, Mike Karels <mike@karels.net> wrote: > On 28 Dec 2023, at 14:22, Mark Millard wrote: >=20 >> On Dec 28, 2023, at 11:11, Mike Karels <mike@karels.net> 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 >> 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: >>=20 >> = https://www.raspberrypi.com/documentation/computers/config_txt.html#overcl= ocking-options >> and its: >> "This table gives the default values for the options on various >> Raspberry Pi models, all frequencies are stated in MHz." >=20 > 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. Okay. Take my notes as just notices about potential points that may be run into by some folks. They are not objections to powerd use in the snapshots or in other default FreeBSD configurations, nor to any specific tradeoffs in the support. Some other background information is noted as well. >> 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.) >>=20 >> 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=3D400 . >> 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. >=20 > 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. I expect that the config.txt for each RPi* related snapshot starts out to be based on one of: # ls -Tlod /usr/ports/sysutils/rpi-firmware/files/* -rw-r--r-- 1 root wheel uarch 89 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config.txt -rw-r--r-- 1 root wheel uarch 177 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config_arm64.txt -rw-r--r-- 1 root wheel uarch 141 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config_rpi3.txt -rw-r--r-- 1 root wheel uarch 161 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config_rpi3_edk2.txt -rw-r--r-- 1 root wheel uarch 129 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config_rpi4.txt -rw-r--r-- 1 root wheel uarch 110 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config_rpi_0_w.txt sysutils/rpi-firmware/files/config.txt and sysutils/rpi-firmware/files/config_rpi_0_w.txt look to be for armv7 (32-bit) booting. I'll remind that there is only a GENERICSD snapshot for armv7, despite variations in RPi* firmware defaults for RPi2B's (no bluetooth cases) vs. RPi3B's (bluetooth present). But there is a: sysutils/u-boot-rpi3-32 that some folks could be using. A grep for sdram did not show any matches. If the RPi* firmware default is not used, it does look like notable model tracking would end up being involved. >> 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 . Typo fix: arm_boost=3D1 A grep for arm_boost did not show any matches, similarly for other forms of control. So RPi4B's would likely get 1500 and 600 as possibilities for powerd to use. >> Otherwise >> RPi4B's are documented to use 1500 as the default. >>=20 >> 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. A grep for arm_freq (and related) did not show any matches. So: = defaults. >>> 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? >>=20 >> 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. >>=20 >> 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. >=20 > 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? # grep -r disable-bt /usr/ports/sysutils/rpi-firmware/ | sort = /usr/ports/sysutils/rpi-firmware/files/config_arm64.txt:dtoverlay=3Ddisabl= e-bt = /usr/ports/sysutils/rpi-firmware/files/config_rpi3.txt:dtoverlay=3Ddisable= -bt = /usr/ports/sysutils/rpi-firmware/files/config_rpi4.txt:dtoverlay=3Ddisable= -bt = /usr/ports/sysutils/rpi-firmware/files/config_rpi_0_w.txt:dtoverlay=3Ddisa= ble-bt = /usr/ports/sysutils/rpi-firmware/pkg-plist:%%DATADIR%%/overlays/disable-bt= .dtbo These avoid the use of the mini-uart for the serial console. So, for FreeBSD, it would take explicit changes to end up with the mini-uart in use for those. Such is not true where the following happen to be used: /usr/ports/sysutils/rpi-firmware/files/config.txt /usr/ports/sysutils/rpi-firmware/files/config_rpi3_edk2.txt sysutils/rpi-firmware/files/config.txt is used for armv7 style snapshot booting. But the RPi2B v1.1 vs. RPi2B v1.2 used as armv7 vs. RPI3B used as armv7 has RPi* firmware default variations in this area (without bluetooth vs. with bluetooth). So, I expect there could be examples of mini-uart use where bluetooth exists for armv7 booting. >> I do not know what FreeBSD does about such things if it does >> not match such documentation. >>=20 >> There is: >>=20 >> = https://www.raspberrypi.com/documentation/computers/configuration.html#con= figuring-uarts >>=20 >> that says, in part, >>=20 >> 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 >>=20 >> 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. >=20 > In the current config.txt, arm_64bit=3D1 is in the [all] section. # grep -r arm_64bit /usr/ports/sysutils/rpi-firmware/ | sort /usr/ports/sysutils/rpi-firmware/files/config_arm64.txt:arm_64bit=3D1 /usr/ports/sysutils/rpi-firmware/files/config_rpi3.txt:arm_64bit=3D1 /usr/ports/sysutils/rpi-firmware/files/config_rpi3_edk2.txt:arm_64bit=3D1 /usr/ports/sysutils/rpi-firmware/files/config_rpi4.txt:arm_64bit=3D1 So: All the non-armv7 ones. sysutils/rpi-firmware/files/config_rpi[34].txt are no longer used by any modern enough snapshot build. sysutils/rpi-firmware/files/config_arm64.txt is used instead. sysutils/rpi-firmware/files/config_rpi3_edk2.txt is not used by any snapshot build. >>> 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 > Any objections? Anything else we should do by default? >=20 No objections by me, just notices about potential points that may be run into by some folks --or other background information. =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?1DDBE6DE-2BEC-4061-939E-4C87C3E276B3>