RPI4 clock speeds and serial port ( temperatures idle and -j4 buildworld buildkernel )

Sat Mar 20 02:12:47 UTC 2021

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 at www.zefox.net> wrote:
>> 
>>> On Fri, Mar 19, 2021 at 08:07:36PM +0100, Klaus K??chemann wrote:
>>>> 
>>>> 
>>>>> Am 19.03.2021 um 18:43 schrieb bob prohaska <fbsd at www.zefox.net>:
>>>>> 
>>>>> 
>>>>> So my figures (~17 hours) seem reasonable for a default clocking.
>>>>> I thought maybe I'd done something wrong.
>>>> 
>>>> 
>>>> 17 hours sounds too long, you can simply enable ???powerd??? in rc.conf for automatically 
>>>> scaling from idle 600 to max. 1500 (non overclocked).
>>>> So, when you hit make -j4 xyz, you will see all cpus running @~100% and 
>>>> Powerd will then automatically set the clock speed  to 1500 on all 4. 
>>>> 
>>> 
>>> I've enabled powerd and rebooted, console messages report that powerd
>>> started with no explicit errors. A -j4 buildworld is running now.
>>> 
>>> 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....
>> 
>> 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).
>> 
> [sigh] Easier said than done, I'm choking on the alphabet
> soup... 8-) Is VPU the same as GPU? 

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/overclocking.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 
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 .)
>> 
>> https://www.raspberrypi.org/documentation/configuration/uart.md
>> 
>> reports that the mini UART is tied to the core_freq, not
>> the arm_freq.
>> 
>> 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.
>> 
>> 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=550/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 .]
>> 
>> 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.
>> 
>> 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.
>> 
> 
> 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. From 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 
> then. I always thought it was due to changes in clang. 

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.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)