From nobody Fri Dec 29 00:56:54 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1RmP20cRz554Wr for ; Fri, 29 Dec 2023 00:57:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1RmN6SlQz3WN8 for ; Fri, 29 Dec 2023 00:57:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703811426; bh=kz+JdHn/wGsv6u7fwN8r+fz9sZYQsJOXbSuNhgXlHKw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gpUhR5+qGREWKlZTd2+bLc3pFdNBr2qAnot5c5TZRDOLEGuTQj98sqQNzogWXsxt994hDerkf8OOCuFIydSCVdSwaGc5yRO9Ac75iBETWIKeFitqhvqkwaZ/6SweHEAiYdSRuIKXfa7WzUuPTN/xdDbMBird18Wn3ZqDpDI9f4aylwEbXuPJMim3L33lwpfe8gSIM5ZY4hk6w/xPiSv0WGARbzgLrJCIacax/2grzBGwUfMZQoYG0BU3CfjOzeoJTa/3XhyGeg0uClqqiMIFM1I2bGggfRNGVxDqcD2O4OAO5hDLk58JfI0kgKl5bdyBBeXpzu7IfkkiZfOedmodXg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703811426; bh=MfYBfY8kJDSrqxEdntr96YhfSOoeDsGpe0QKZwFGLeY=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UHtF06FsgsNEN3Bm1R5vlHJ1OKrOvnD35lDs1fizUk0TIY7xexKWgNL7gJq/NrxdfphV8wRly5HtU7VZ3WsZGmkndhcXPBmyShCZSvRHpSi6OG7YEOOng1RZnmzIsybUitMSoBB3P21ItV9y+SWFxS4lJ9JvtnjNQOMQHywdrCK5cQmiDUgLRNIqCGqlQdPqCR/FVZI9UyR4wxouW2bCE2L9yn8/MpWS6J6soKTZ5dDrGHxzzxr9NIrK3WjlXqRaj8mG2HKAZOrapIqxe8epB3Vz0BYh42KyUlgLWKurj+gZt0UMF8OECmm9WyCX8O/QEz17imtB1vacr1IYiLBmVg== X-YMail-OSG: XL.2qLoVM1lZP5yguk5zqXMEYXp45.HAZVlM21o4iJ3_xo2DngwPM4kTS7vXRPb r9upD0XoQc25fCOSQJUqE.VQ0DzwwfbF0LrKp5Jgz1NDxn6cMz.mf5tNT0Gi3nxKc71FbJqPBPrT Gu6aA8bPK6Im91AVDFAnKvYyDZ0gRDHqjsznbhQsViPppkqQssNS8PAk6ejxqBIH5yIKUmhYEqyZ 9OKHKPOfbfZLGPgxryp9ZAtpxfZR1gmIT379TY3vJHUn.0RlL1Kkyb47NyX3gSWR.iPP1brCn_ak jnw3UYRgkx0YYjHOaysZoPDYsr5x458hHwS8P.DdwvxrTQ4gEniwPFWeQU8kAfm4pRJoFrFRhxjM 63cO1CMDx6M0ucLG0WE.IOxVnCzjqL3qW6mSTTP5ToOXTeWjta_IXSX0L0MA1Wvny1155UN8KWWp 5nFR.TkPf3UCSh9WMLXZINCityM4v6YmR8V9tD3JXzXPBbE1XaIxpkSggl3Fk0lLTqe6jIC5M_wB kMNqIPtLukr4SKOdQiHYhmwINg24PbZQA97NODoCe6GQSxdrQI4KIq6EGy2In885bi2wR7O2i1Dw ax.Ya3vlin5gAh3PmVn2vbXabQiL3aWyk_xjxvFbkTy.BGCWFoDh3.6LU6suBg.qqKXf.Cgy5IIt 8XaFXnpxU3HVz5eljTYpvvFy3vVHqNAMIGLsL6Me7rpmaOpoT9iSdzUzFWLEHOKCrJSzoiwkuxcD zeHR9yu8L5DiRwHrbbFCHaYlzLsiwq7eDqXZ_2fQ7olGgML2JxGedUjwKRtvstJBzaqx8vlOVvBe 1sB.GyMyOsH4EjpfFlo8e0nvWr2BemDnlzGOpBElMuuVB30_mvRNJJNCiDdXdvKCzTEx0aH0TOgj nMLQ0nYPr3nA.3Dozd6CysXk8bdlKj3Tu1bAzd_PwZ.zxUNXyBjYGHEAhaoSw9V95LcNLcrI59TI GPdXTsfgPnfN9CpUp68qqrgAaBIAbIvcbLLgSmHtKRDxN1kRQ9UF_xY0a4cIh9.nKDdqVjKY11vP yvtx4KkuB4yYvtR0X22UIU6EI2YVqGOkco9aKXUqrmgthb.ltunIn9Zau2LpRctc8EOtCskYxDSJ 9QAMBPyA0mRqrzUhWHC4KRt2MB797RchKDrR2L2V_OR.jGtCBLl7WdDXashBa1QAi5C_7P2MUBjV JcUVWkzRq6nN2VIwIhJEJVZm9W1h3adF0CRT_zLmh0EAh5MvkvZpM5pvO4fR.7CbV_3duWuIkdmS Gd1bmfq7q2rRslL1CyHhZ4GkWzSmg_KcFsxGVZnm3gy975dC6MAElJfcpMrEP7NeZvDxmfuJMyY_ MLcqbBvq4pA6FeBp6.xg8yOTrfAkrFFM7OOg6ixlA4_Tkp86WboCaKDWPxgRz16K3cMOIhxYLV5W Jm04EfQe2d.gVlhbDvIcxmMKN11iB3ISR4cX9vPAN.kokEoFxdBNhVzTg3oXpUwIXcmYk9iljrBl VpLQMjA.HK1zPP.fHcR9uGm88IfjMsggC1jIr7lD3Jz20SGvO7JIzAayFTZM5BfhyLnIA2q_kcAG lABdUiz13EqpE89.jczYbCgksG_Go4gLoF6ZA6xG8INg1_45kOQdlGjb6IQXbZVE0t_t.KIWjjwU I70z43yzO_r9Mc78J_cvFApD9mK_FrrQPLdjJk3S6J4KdCjL2E7Yv3mPUGwy77iE.cH8GMzPN9Id Urjm.39NiiKGBfodIBAFSq8G1TZDJVXT3magC0ozoMxAWBr35xdstvBbUHHiTv5ZCIkzzTRv7_Wl lPq9rPBCu9zcOT6rQQHYF6G9D6WhUTyZ6WnRDFqAh6SNFmDjk2xU8kkOKgi0jvUjvuK5CjBaljZ. IoL65NvgqiOYBr1z.xXDg.ktEHY1QTDyN6_0urnJSiD1BhLXPR1eAlI.K._zu.420JzL1tUvj0om 4oloUXQzRU57eeBNpBZmVcntjE3qsPVMHLK1ySth2g9Ph3W408m2ZRIDnL1H1QyZ1E0X2_ii5pTO 49PAQDK_bau8EZK8ke0_JBit24VgJQflNfUdujxprEAKUp_6vQoOH68PGS_GUvuMvKNRKQC3ahCY Zjybclb8q.TkfBcFeCyB_ih3ecSxwNfzWwPo8.23MGIUSS2eJfRkuTPuJLEBIek1MYeIfAgddR74 v7DRdqPZbxB448sgsFfoVjfQaF5ovNBrjwNSF9XEdGVWFTkO2uCNKa8YxxKfAfdH2TdPz9SpJbS6 PSSgcnuoQ3hac6RR9fE2Vt1gsM0dCx5Ny8tozDvEaRmpAJmxz55p1YaojQoEnJval0rzBseqX5ZK 07g-- X-Sonic-MF: X-Sonic-ID: 7de136a8-bc0e-4d10-bbf4-72e1a4ff0fc0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Dec 2023 00:57:06 +0000 Received: by hermes--production-gq1-6949d6d8f9-nsbdm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 35c6ac20d646e10761616f4c1e26be00; Fri, 29 Dec 2023 00:57:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: enabling powerd on RPi From: Mark Millard In-Reply-To: Date: Thu, 28 Dec 2023 16:56:54 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <1DDBE6DE-2BEC-4061-939E-4C87C3E276B3@yahoo.com> References: <0E56E105-2A22-460E-9C58-24074922AA18@yahoo.com> To: Mike Karels X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1RmN6SlQz3WN8 On Dec 28, 2023, at 13:12, Mike Karels wrote: > On 28 Dec 2023, at 14:22, Mark Millard wrote: >=20 >> On Dec 28, 2023, at 11: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 >> 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