From nobody Thu Dec 28 21:12:10 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 4T1Lmr3BqSz54dHy for ; Thu, 28 Dec 2023 21:12:12 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1Lmr1KPTz4cQR for ; Thu, 28 Dec 2023 21:12:12 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 3BSLCBwB022510; Thu, 28 Dec 2023 15:12:11 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1703797931; bh=dc8aAQMwvrzHAE4dgPUGFgYb55hn2GJdBbISXeOeoW8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=XN3ZISZhAofGX0NkW3GmxOCeaYiV/XjYWIK/myW0V5WxfYUQRR6hzvPC0nohrLbiQ gyH8RLBrCiXt/HVf1NgaFYlVgr1lYvGhhXh4WI+LcJa35I9zHCUNiB9h3N1emGEi/K F8BQHVAEc0+rriR7k6pHQKkxkkA3tun+3cs4/zqzAqgCw0RQuHguDJ9LsZ5kHOJQc7 6NiUikvn3Ur53a06J6yWSyDjzfcEcaisyEQa48v4saaLn06PvlIHH7xhGlgiXMn0wg nDYxgSJUNqSWiQPPCj8yqXp9CL0aN1ZG2fF0grIVwpqAZYf4NnhEbXM+ppH0Ulm9hC eaxx1qGUCRfsA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id JlR5BKvkjWXsVwAAs/W3XQ (envelope-from ); Thu, 28 Dec 2023 15:12:11 -0600 From: Mike Karels To: Mark Millard Cc: freebsd-arm Subject: Re: enabling powerd on RPi Date: Thu, 28 Dec 2023 15:12:10 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: In-Reply-To: <0E56E105-2A22-460E-9C58-24074922AA18@yahoo.com> References: <0E56E105-2A22-460E-9C58-24074922AA18@yahoo.com> 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 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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:16509, ipnet:3.16.0.0/14, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1Lmr1KPTz4cQR On 28 Dec 2023, at 14:22, Mark Millard wrote: > On Dec 28, 2023, at 11:11, Mike Karels 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