Date: Fri, 19 Mar 2021 19:12:39 -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: <6051F8DD-2D31-4F4B-B2B7-E3DDEB52F0CF@yahoo.com> In-Reply-To: <20210320005302.GA40542@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-19, at 17:53, bob prohaska <fbsd at www.zefox.net> wrote: > 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 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6051F8DD-2D31-4F4B-B2B7-E3DDEB52F0CF>