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

On Fri, Mar 19, 2021 at 01:52:35PM -0700, Mark Millard wrote:
> On 2021-Mar-19, at 12:50, bob prohaska <[email protected]> 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 <[email protected]>:
> >>> 
> >>> 
> >>> 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? 


> 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.

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. 

Thanks for writing!

bob prohaska

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"