From owner-freebsd-arm@freebsd.org Sat Mar 20 02:12:47 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D6D575B6567 for ; Sat, 20 Mar 2021 02:12:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F2PRf6KRmz4mTg for ; Sat, 20 Mar 2021 02:12:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1616206364; bh=/T4+9JnWRls18NdbhvH0v0PbPXwHQLdb/Mt2XBok5nv=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ebNkc6dk4bB0CaNgFWhqGvg/7fbzHzLVvj0Ha6ddP8Qp6RdDrRMdRtuwxojUmhfgeBpf5D1Ve0Kk6akqCjjF+J9uKvyCC0cYzD6LcnnppQgyIm8y7plTrdvV8eL4/kAn+HZh49S9yXUI0/hdiVqortXP1Awj92/ysou+FYPRMf/w56cSCqcEGkT4ij+YTe8KJpIUr7uYpfX8hxw9rPG3dZYF7kewryTQEUzyP8atUa9ILYvV4wvVpojabsuaV/6mFr6S0U+UKKU8yF/0EMOtej0zWjgVLMf74SD1LM6SYcgXeuJxB1BaZEEk8f+tCHAQIwqIdrjfjw3DXlIj7Do6BA== X-YMail-OSG: NmDoGRYVM1lCrz_AZckfrWBIpn0Sw6w9D7rmywBKSBGEvATSffUU2UuztUBz0a7 p9iTEc9cVxoWUUVJlJSIOQGdZnDyMrgx6SbuHSY5PiU0pX8ciX.RF1m4hj4jVFhcyUVqVPgasLvb iGLVsnIRsGdyzd6VRfaIrJ3DtZagT5_4r1x1JuyRQkvLBpBocn0eT.bQ3arM9oKukrN5pEN3y3AJ D9c17Z8.xPGYoVSvcOS8.sG1BKuHph0w8ON7zp9zp9nXXNJjgickAHpdcJlKJcclNqOnxKSUf278 8zERHNEQoJS8nnMoFdGzpUq.OxZ1J28NQbfF8ITYBPU6nu5eV61MvP8xQTvDdS0f1KDNT2QW2CTm KRak_GQeeySdla.FaeGNvMLukB45sBef4Bt7_zTMNcy9TLjF1iBnqRVPDcOCMejl4xeO3ojj0G25 VOYPoBf3YttqLWDNfLi4a2Y31DycgSu8H.ITSqidtDAmpnQcRvBtk4N7MJbzv0jPssSGLxXabFW_ ZG8tJbc.RGLWt0O23AdrJ4nWi73cgCG_h4BFwhpd14Z82MfPjCJ8JBbh1PUxPkjSRRv.uHY08RIl eHbOuNT8ivikaYDHnqla.5Q5vIlL9bs6JUTV6G0mIMPg3g3ga3f2PaUmcpYN64F5FO_VdfhGDg1I 3TygI5lWqwHu6YQ6H84gqD7CWQovSWVj.aXoLe3GTrYKt3LbyQBeS5PEns7zmPuSv4CWaBMW0uRa mJvB8WjtX18Zqu2iT0qr3cAOnk8qzweoVxbCcJZQ9NftrEclgnmqwlOGNfgpUvGc5zQObBOZvpdF Ir_kETMsab129ZjcTpog_KoPN5uuLZgsZrZJ0s.dp2NHAhRG1.8Z5s97HtMeWWUcqeytdCViLgZC 7F1xBD8qlBxLmb_Wi.leSPab5TE.uUj5oVqczyHBNZG8yYvz_TpM3hhbG6VwDcHrg1Cm5ZBq64iJ YLJBq0.FWfMmc95_.Cxy6JSkPo3CXCYfey0fCE66Zp7ONJtVp0uLnFSc2zpk5hugXpZiWKCI5_Jx TuRQ_b24NwvoRnT4WL0eGViXJT9L8cpPLAyC16QsjXjO7RF2ItU8bY1syVKQOE9lAhRPoxVhoRau fZNJvnL80D4g.Os1mwhhjfxK45QqWjME1U5jrvBaGgbLwnGfXqMJ0W1gHQg3Wf.sWJqYB6G0LKWv ud47Tk1WhFbOrU5M1TFxi.FKCj8_VakDerp6imXnyjPrrbo_Rg9sWzvTpaHtfY4YNEq0kwHaq.tO uUM6E9cxpBftB2Y6gh68_K5FUwpdt6XzwAZvXNhIMTALBvQNxLOfGsI0Qs9tCgu4Bk9JL4oi2Uh_ Irv1djM6KodF41nQ63gc4fJTxzxMb_UmoM9lRk4S4kAjhiy3fBxcWfIogjwz7dcU7N5Wnq9OUor3 yRLvhL5IKmjU.0T2Fg.ijTKaY3yiyvKVjJ7Szt64G4sYdzrC3rbodmXAopK62I.Oa_3Ju48PXhNV EB2GNOmwhv.Tydw8Q_0POaavs_m8YgSIIGVynWUemlNzBUcsHpAeYifNh3nsieBklRdn91oHdABl SD5.kbzprma_Gfv6MFVJtxPnE5ntIkPltkhv8vWRwhwfMF2J0LAV9WN333qrXlle.ad93Oz0ePkY kDfs50yCIuSKGfSsgZyGXOE1Apd1Ed2CyAOtJOqE3nJf_WsDY37AfeU4RbzVMRKZbV6N6X_ETZLt QHgVUtd.7g64tnMfoL1L0TRhBZ8.E0Pa9SsZS.HxJUF7VgrfoVdDbwTyGM0ugmt7NHe93hN4XU0G G60if5IcVuts_WVbET9yRqwf_5LF6dfYZ7qz3w8X9KWj2riJkQo6wmuSsekrNHXhkbo9gFt.ums9 kLOi5uxjXOEd5dSSA6MoMS5rcCbdUyGgKyXLS8Di7MDTdf3wmxYGLVcptHti0JDk.qDAgydR6EWa aK3CBckl8kXQyqX0MZs4yezR.fjCOx.o.YjtbdhoVsd7pzXMyuKcUpAv1z6IAg4YzhorXg82XNOm n4sd7YJcUlC64BZlMTU8kW1OJtWR0dJfXTbxT6Mcxx4kvgeNSyqPJ7lto3l4wxhF1lZxZTSNhH8Y dEoMHi1W9zXXrVbf84HAjQtVBO2geI_yhzmJF4IiQXmpMS1DGPwPubSNVNyu_fpNlUmpmHNUeYdB QHQzDNd51kpfS6dmiZo0Z3Wq0NOWnCeZH6BCR2i0IqLzwUgx0mSFvFqagk16kT_S_DRJ9KSJIJH8 eUv4dLMo8BJLvLiqGBFQEJgWWELvUSvyvS9Y6r8xqcPdSHpVWz0Pbz18b80SH2QN4AerjecudSEz Mh1IpKXFLQKw0w_R9u8JcCTG0fioPN3c8B06C25bjkMAA40SbKDJ1Vm4zVZIbdc9NVT1xsh69yOY vktAPPUvSOOSpeVKjLCzVfgiBVoaB9xWaPWtK6u.JY0WwSNDY4cl6IPuZLca6C8g0h3s7Td8JxWO 67E7RtO6DghBrVruyEo9yFzjJZjbyuyQisdk_WNwLiN81lpLNvSZCesz0W4aQOsZzUxH.s8nD6YK 5tIF6SH6N2ttjRAhoYxNG_uASACspkLZPebeF9zqsMaYdfhB8APefN_qEVn_P9bcnBQ.Sric324o 7Rx7eKvSRg17Jag-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 Mar 2021 02:12:44 +0000 Received: by kubenode545.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5e009c89d52d92c754718c4df4be1db4; Sat, 20 Mar 2021 02:12:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: RPI4 clock speeds and serial port ( temperatures idle and -j4 buildworld buildkernel ) From: Mark Millard In-Reply-To: <20210320005302.GA40542@www.zefox.net> Date: Fri, 19 Mar 2021 19:12:39 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <6051F8DD-2D31-4F4B-B2B7-E3DDEB52F0CF@yahoo.com> References: <20210318170053.GA26688@www.zefox.net> <9FFA0A51-C0B7-4121-95CA-B98669809007@yahoo.com> <81AC0353-258C-41C3-86B1-C133E33D97E3@yahoo.com> <20210319174359.GA38899@www.zefox.net> <20210319195019.GA39087@www.zefox.net> <20210320005302.GA40542@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4F2PRf6KRmz4mTg X-Spamd-Bar: - X-Spamd-Result: default: False [-1.64 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.86)[0.858]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 02:12:47 -0000 On 2021-Mar-19, at 17:53, bob prohaska wrote: > On Fri, Mar 19, 2021 at 01:52:35PM -0700, Mark Millard wrote: >> On 2021-Mar-19, at 12:50, bob prohaska wrote: >>=20 >>> On Fri, Mar 19, 2021 at 08:07:36PM +0100, Klaus K??chemann wrote: >>>>=20 >>>>=20 >>>>> Am 19.03.2021 um 18:43 schrieb bob prohaska : >>>>>=20 >>>>>=20 >>>>> So my figures (~17 hours) seem reasonable for a default clocking. >>>>> I thought maybe I'd done something wrong. >>>>=20 >>>>=20 >>>> 17 hours sounds too long, you can simply enable ???powerd??? in = rc.conf for automatically=20 >>>> scaling from idle 600 to max. 1500 (non overclocked). >>>> So, when you hit make -j4 xyz, you will see all cpus running @~100% = and=20 >>>> Powerd will then automatically set the clock speed to 1500 on all = 4.=20 >>>>=20 >>>=20 >>> I've enabled powerd and rebooted, console messages report that = powerd >>> started with no explicit errors. A -j4 buildworld is running now. >>>=20 >>> Should I expect to see powerd mess up the default mini-uart serial = console? >>> So far, it hasn't with top reporting less than 1% idle. That's = confusing.... >>=20 >> Avoid confusing the arm_freq with the core_freq (core is >> VPU, not arm). The two are independent (up to the RPi* >> firmware's dynamic frequency clocking logic anyway). >>=20 > [sigh] Easier said than done, I'm choking on the alphabet > soup... 8-) Is VPU the same as GPU?=20 As near as I can tell the VPU terminology exists because the hardware involved is not limited to graphics tasks and in fact is used such that it "coordinates all functional blocks" as one reference that I found puts it. There is more to the GPU than just the "core" and they refer to just the core as the "VPU" at times (presuming I've inferred correctly). Something like the hardware for "coordinate, vertex and pixel shaders" (the QPU) is distinct from the VPU. But both are considered part of the overall GPU. There is a lot of substructure overall to the GPU. To get a hint of the parts: The gpu_freq option is described in: = https://www.raspberrypi.org/documentation/configuration/config-txt/overclo= cking.md as: QUOTE (partial): core_freq: Sets core_freq, h264_freq, isp_freq, v3d_freq and hevc_freq together core_freq: Frequency of the GPU processor core [my note: So VPU] h264_freq: Frequency of the hardware video block isp_freq: Frequency of the image sensor pipeline block v3d_freq: Frequency of the 3D block hevc_freq: Frequency of the High Efficiency Video Codec block=20 END QUOTE but only core_freq matters for the mini UART issue. Note that there is no actual, single gpu frequency: just a bunch of frequencies for different blocks, that may or may not be set equal to each other. Note that arm_freq is not in the list for gpu_freq at all. The above excludes the arm hardware but the VPU starts first and initializes and starts the arm (and more), the arm does not start the VPU. >> I've already reported that the documentation indicates >> that the core_freq is not supposed to be changed on the >> RPi4's. (The use or not of 2 features controls the exact >> value that it must be and the firmware appearently >> already deals with tracking those: hdmi_enable_4kp60 and >> enable_tvout .) >>=20 >> https://www.raspberrypi.org/documentation/configuration/uart.md >>=20 >> reports that the mini UART is tied to the core_freq, not >> the arm_freq. >>=20 >> So on a RPi4B where hdmi_enable_4kp60 and enable_tvout are >> not changing, the core_freq assignment should also not be >> changing, no matter what arm_freq changes are being made. >>=20 >> That leaves core_freq_min for the RPi* firmware's dynamic >> frequency clocking. The default is 250 or 275, apparently >> depending on the status of hdmi_enable_4kp60, 275=3D550/2, >> when hdmi_enable_4kp60 is enabled, otherwise 250 is used >> (for the core_freq 500 and 360 cases). [The 360 >> (enable_tvout) case is not well documented for >> core_freq_min .] >>=20 >> It is not clear when the dynamic frequency clocking >> logic would adjust the actual core frequency but >> it appears that the official way to avoid messing >> up the mini UART is to assign: core_freq_min to >> match the value of the core_freq setting so that >> no other setting is available. >>=20 >> If the mini UART is working in your context and you >> have not disabled Bluetooth or redirected the UART >> Bluetooth is using, what I infer is that the RPi* >> firmware's dynamic frequency clocking happens to >> not be adjusting the live core_freq significantly >> in your context. >>=20 >=20 > Powerd does seem to affect the apparent speed of the Pi, > and seems to make it run a bit hotter, though I've not > paid enough attention to know by how much. Trying another > buildworld/kernel to get a sense of average speed. U-Boot has classically set the active arm frequency to 600 MHz independent of the config.txt figure and FreeBSD (loader and kernel) leaves it as-is unless a sysctl assignment was made or powerd or the like was in use (that in turn made the assignments). Note: To my knowledge, U-Boot and FreeBSD (loader and kernel) and powerd leave sdram_freq and sdram_freq_min alone: what is in the config.txt is what is used, where the VPU part of the GPU is adjusting it. =46rom what I've seen the VPU tends to keep it at the slower end of the frequency range. > By any chance, was powerd enabled by default in the distant > (year or so) past? Things seemed to slow down markedly after=20 > then. I always thought it was due to changes in clang.=20 Are you trying to compare non-RPi4 to RPi4? Or is this about just some other (non-RPi4) arm context? Certainly if one goes back in time the compiler and linker built in far less time, true of even early FreeBSD llvm vintages vs. later FreeBSD llvm vintages, as well as the old gcc toolchain. (I mostly saw this via old PowerMacs over the years, starting before FreeBSD officially supported a llvm toolchain for PowerPC like hardware.) I'm not aware of powerd being a default for any official FreeBSD configurations. But I've no clue if U-Boot might have left the ARM frequency alone at some time in the past, leaving config.txt in control of not just the maximum but the default as well. So far as I know FreeBSD's policy of leaving the U-Boot result alone is very old. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)