From owner-freebsd-arm@freebsd.org Sat Mar 20 05:34:17 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 F339557326A for ; Sat, 20 Mar 2021 05:34:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (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 4F2Tw90PSqz3DrF for ; Sat, 20 Mar 2021 05:34:16 +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=1616218454; bh=MZwG9LZKy5lOIkqd2YVN22aaYpghrJSzrLgG7l3F57F=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gPM+DkmOyL2X2LVdHwvY36G0CqD5G6nDY2gHL/SN2ArxBwuKsHqjL2rn+qsFUQHMegW5tkTgg84ynNHHULbwHAWo3WVkAAfwko4YSsCSn5njau+EUhrL0FUxbTbHLXnfI2+qRkLBt7QyV/bvWgBHy+kSHDO9Rhli5uOzyY8MaU85yu9FJ2NLcmqGHYU6h94YaWsbOTRAi8Fj1cPFXm1g2Csii6l2+XdADf/14krWhERw4EPZZrEN87+paozBGCdIUW5HHVxJi4ggIq8aCjzoVE4jxxVNFYezH0hRRDD0YEmy8UkRM41ToacMCeGseaKo64TmEyHLu9BDF6i5g6ralg== X-YMail-OSG: kcW8uuIVM1kFw3mASxBiPlffa11qOjK2H5Vvr4Oa3Q7KHXz0SzLEkoutDLYXvfI DX3b.BV1T4jum4Mi0_eQu5qPyfkBItmecoQZf0GWuVq4cYTam.tiSISSGHAp4To91n3a5hKD861T pw_PxR9h9UpnRVmdkPdlnTr8a53oVkks8qyRfOC7P5p5ZT.NQO56ewNRcjY8nNiZxxvRrXL7gr8r bT19unkWbh.lroL750ar1k0KOsLcVHZ.fqQ_fMHHH_2EuimSUEhjNUaBpBXVipg7iSFMfifZmhPB Ue0L347GDoX59uX_UeudQfV.PmZhnUByPA7knWXGrBgAzodXxawC5BUHLKyVJgDDf_vqLrJGj05x rF55.2YdOAawnqHokQpDWFct635KzS8n8awMe7cxtMUoTOij.AH8gvGKhj.e6MJVZd84Np4ufG.M 1ql8bqG4hUeu0qsJIgp8uDw1mc_.w2vSarl.eKoBPQoUeDmcuv3m4WEAPheJQw34rlIzH_fv_BvE iHsGJrGW6S7A.nfWhMWWcyxr4sQ1whCn52fNnbqoTJWPDPYkB3KoPkRGV7UzUKWoRK.s_59TlWpJ yFAhuEP6C_Ft9CNwobWAaEeF.n1t5S2HmtJTjQzvYzefIulrbHDB7NoGLE9MAv4DDhmmvpIeaePn voRc6Kcu562wr07kw.hIcNivblGMpFEJSgDanLnT9xvWN9FyLje1Zctul02S8aqbS.wuBd7eh91B Ou3Rt3UCrwKukydOTiKgkSvFATiP0pOUiZkbOLbsru74heSJPE7oIISju6DceIuWP7c8vk3ES4al dvZYzq5leY599HMj8nZ58h89IDgjA2vzbWSQjTDb7za.5cjOC3scGKZJBN9AFdWpQzR6RZTFQYc7 KZa70BUfKZ8FtvYB7HwNfyLrfTglP8N4hFb2TNw9XIt8WKR_L28slYWUTGTeW1rBNy04ItFsktPn oqBNBtnJknODZBlxn9cEyBPiF9nGi0kmIE3tSe0ovkl7BcL.by.nHVwZKqUYPKAX7uY0WoNtzfu4 4W6dB7kFhMmzfRF554S_0m5ndNV.0.L2PHLqnp4LwVwbZUjbnS4c7MmWZGPcXLTld5vE5NQvEzCv 6Rl00W2yJ7_wVRMrUiQh9QMvYBOg_Nv4e3B0T2On36XVrf4sN0RMzADrnrw1Ia_3nBree6_ZTqW0 ltlWk2.6yb2agXWfVnrCDP9rcgfg8H5m.TzmdvLUEPwpidvc8Az1ffM6q2ot2tKq.x6uy1Ugrh2R aFkklEeauMjR1KJLGQzVG1mBl0JmW7R2lGStovkNjfhzQ3l5zTp6FPdf9yJiT0TjunOPEf2a2_Mb Yckx_qd6qw_NTpchl3tnkcMGMHqTyOlAAL2FBhH8Dl4eDLKNP6kO0675P81PFV27lYeMFzOtAV6K 1H8W5MBZYWHHw_piMSCbNpbw569iKrqpL6Ok13VkS7y71o8jg0dL7yhLD2DICGG8bbRwjbLG.G6R xJ98l0P79HnFysYXYBPYt4pagZjB19iqf3HZTokVv.UJYY50_4APtp_JWlPzYcyt_oXKrOP__6SE d5imYHXcuV5yUncj339JlFHms7R4Pd3VYYHCKCGbW.pxu3cIF7s.aSURKJuy7fOTEVq3RQizbyad Xs1hF.MS1i4oaaV9OoPHyY9lFyl010dWPE3EpG4.JuKkUvnw1h8XZ.0_gMPcSAtf39Tm8FQIL.Pe C0M4FYcwVZZjzDEr.AHolW2QAUZ0seB4ovC6.jfuTRamrEfZxmSyAtOFXEkwxGyldiOucNME1.YG CQ8lROqAs2TxW1CRQ9m735VVDxb_0bZFYpQorTEFL531OXYLfB5.cM8I94sEEKVKtDWcfIlX3ZBe nKTyALUQ7EyinFgK7LCDPwXXNgJakU4nn8mibeY6IuDIn7AnS9QFHlR5Cvw6tpNKo38cWoYe3gO7 DiIUFTRZecKupVqv0j832USgli5ua0XL4CLVtl1vIRX1IzD9Y42eMkrI7l1wcuvnfFMI7WUL8Z1U jm6NzAFxocMi4uDa1Kt_2PWno5vuNlyAJF4WHG2JO_lJCjCGMcgJtGIwdyXYm9wsZIYoh2JW.j8h 5JqlqckJdYjZ4o1X_bAnBIklI8A65CUwD__F.6aF4ttoIl204dIVMwb8Rdi3rxw7FR1ffbWgeT44 4E7vVblMwc6iCpsOl.4trDjW4kBME.Q9N71UXGmn.EuwXtnaRkhbeGzsqCLYsqXGgt_Kw91sbW9b dQmOmuWKNeNsI.9QKMRWYxvazW2Njd0JoI2FBtZwKU6GlhdriaOpPu6Bo7unrBIsGUmoQ_ewy8I9 Hv7AnHwA2q11j6ZXl4gyYts8z.0zbgWhY90H5SqKrRv5pH7ys5c519PO.O5iN8Gdg8UfV_3brqez J6ooVKwYkNp_4lGlA7Frq88WAxCNr6bhfnAgcDuNE.CT2Qt2G5.Jm1ZpKd4uOSjUqOqS8k.lNxiw P_9tv2fz5w68z_j5HJjNYSw6fqlZByxkznjxVQ59T9b0.CCsFS.X4pCEYEAiRpx9G4HGJTpj0D8Z 18AZ.hbTreJNmkHgTiA3tTvUQib1Y9iGUALy8bTbQ_I_7vAfTZdwKPxLVgOrWX7qtJA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 Mar 2021 05:34:14 +0000 Received: by smtp408.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 38cc8eba051b780c4d2d63c1f15cafce; Sat, 20 Mar 2021 05:34:09 +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: <6051F8DD-2D31-4F4B-B2B7-E3DDEB52F0CF@yahoo.com> Date: Fri, 19 Mar 2021 22:34:07 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <95B90C86-A0B8-45E7-89D4-D7C3CA7167AA@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> <6051F8DD-2D31-4F4B-B2B7-E3DDEB52F0CF@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4F2Tw90PSqz3DrF X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.45 / 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]; NEURAL_HAM_SHORT(-0.95)[-0.949]; 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.65.206: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_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206: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 05:34:18 -0000 On 2021-Mar-19, at 19:12, Mark Millard wrote: > On 2021-Mar-19, at 17:53, bob prohaska wrote: >=20 >> 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 I should have mentioned that the "V" is probably from Broadcom's VideoCore Microarchitecture naming. VPU is likely not generic industry terminology. VideoCore has "an array of graphics processing units". About 10 or so VideoCore based SoC models do-not/did-not have an arm processor present. > 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). >=20 > 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. >=20 > To get a hint of the parts: The gpu_freq option is described > in: >=20 > = https://www.raspberrypi.org/documentation/configuration/config-txt/overclo= cking.md >=20 > as: >=20 > QUOTE (partial): > core_freq: > Sets core_freq, h264_freq, isp_freq, v3d_freq and hevc_freq together >=20 > 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 >=20 > 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. >=20 > Note that arm_freq is not in the list for gpu_freq at all. >=20 > 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. >=20 >>> 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. >=20 > 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). >=20 > 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. >=20 >> 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 >=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.) >=20 > 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)