Date: Fri, 19 Mar 2021 22:34:07 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPI4 clock speeds and serial port ( temperatures idle and -j4 buildworld buildkernel ) Message-ID: <95B90C86-A0B8-45E7-89D4-D7C3CA7167AA@yahoo.com> In-Reply-To: <6051F8DD-2D31-4F4B-B2B7-E3DDEB52F0CF@yahoo.com> References: <20210318170053.GA26688@www.zefox.net> <9FFA0A51-C0B7-4121-95CA-B98669809007@yahoo.com> <E4CF6642-CB70-4495-A865-05469953561C@yahoo.com> <EA6BE351-98F5-4446-BA4D-948F04EDFD3B@yahoo.com> <81AC0353-258C-41C3-86B1-C133E33D97E3@yahoo.com> <20210319174359.GA38899@www.zefox.net> <FA5A110A-4E7A-4381-BBE5-9B3022CA9008@googlemail.com> <20210319195019.GA39087@www.zefox.net> <FDBC2E89-8473-4C3A-B12E-78821949FDDB@yahoo.com> <20210320005302.GA40542@www.zefox.net> <6051F8DD-2D31-4F4B-B2B7-E3DDEB52F0CF@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-19, at 19:12, Mark Millard <marklmi at yahoo.com> wrote: > On 2021-Mar-19, at 17:53, bob prohaska <fbsd at www.zefox.net> wrote: >=20 >> On Fri, Mar 19, 2021 at 01:52:35PM -0700, Mark Millard wrote: >>> On 2021-Mar-19, at 12:50, bob prohaska <fbsd@www.zefox.net> 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 <fbsd@www.zefox.net>: >>>>>>=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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?95B90C86-A0B8-45E7-89D4-D7C3CA7167AA>