Where can I find the current processor frequency? Say for the Zero 3E and 3W? I am using the Debian XFCE B6 image for now.
I found…
# cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq
1416000
# cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq
408000
# cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
600000
Not sure what the following means…
# cat /sys/module/cpufreq/parameters/default_governor
ondemand
# cat /sys/module/cpufreq/parameters/off
0
cat /proc/cpuinfo
BogoMIPS is considered a ‘crude’ measure, not (as accurate) a point in time real time measurement. It is a function of the processor doing nothing, per wikipedia. However, I am sure BogoMIPS can be used for some use cases.
processor : 0
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
Where as…
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
As I understand it is an actual real time value of the processor speed under tasking. On a Pi deivce cpuinfo_cur_freq is considered a more accurate measure, as a point in time measurement. So I am asking if such is comparable on RADXA devices.
I have learned from experience, the RADXA devices can throw a curve ball know and them, when I try to leverage my deeper understanding of Pi devices to the RADXA devices. Different design, different results at times.
In reference to the governor setting ‘ondemand’… Per kernel.org…
“The CPUfreq governor “ondemand” sets the CPU frequency depending on the
current system load. Load estimation is triggered by the scheduler
through the update_util_data->func hook; when triggered, cpufreq checks
the CPU-usage statistics over the last period and the governor sets the
CPU accordingly. The CPU must have the capability to switch the
frequency very quickly.”
Where as if…
/sys/module/cpufreq/parameters/off
is set ‘1’ this disables the governor? Still looking for clarification on this.
It’s not very clear to me what you’re looking for. With the “ondemand” cpufreq governor, the CPU frequency can change multiple times per second depending on waking processes. Even when you type “cat /sys/…”, it can be sufficient if it starts on the same CPU as the one you’re monitoring to cause a change. The cpuinfo_cur_freq entry does indeed report the frequency that the cpufreq governor has configured the CPU to run at, at the moment you’re looking. For example if you’re playing a video it can make sense to look at this to figure what can be an optimal frequency for this.
If you want to force a different frequency, just change the governor (check the list in scaling_available_governors and set it in scaling_governor). The “performance” governor will maintain the CPU at the highest frequency, the “powersave” one will most often maintain it at the lowest one, the “userspace” one lets you set the frequency you want by setting it into scaling_setspeed for example.
Then if you want to verify what’s the real frequency the CPU is running at when configured to this or that frequency, you can use my mhz utility which will measure it. Eg:
$ taskset -c 0 ./mhz -c 5
2108.239
2108.398
2108.318
2108.160
2108.160
The sbc-bench utility also makes use of it to verify how accurate each of the cpufreq operation points is, and will indicate the deviation in percentage between the configured value and the measured one.
@willy, at this point, really just understanding the ins and outs of the governor. I found the policy the governor is set to, and how in can be changed, etc. The last question is what the ‘off’ parameter does? Which appear to be a way you could disable the governor, but I have yet to find any documentation on or about /sys/module/cpufreq/parameters/off so far.
Confirmation that the cpufreq was consistent across RADXA implementation, comparable to Pi devices, which I have extensive experience, I have, which was the original post question… as I dug deeper, I came across the governor control, which I have not as yet worked with or needed to.
I developed device monitoring software for the various SBCs I have deployed, and a few different variants of micro-controllers, and now I am developing comparable support for RADXA devices. As I can, I am trying to leverage what I already wrote for Pi devices to RADXA devices. Sometimes they are directly comparable, sometime of course, not.
Your suggestion of using ‘mhz’ is well noted, I can use it for example to validate my monitor software is working as expected. Thanks.
I saw your question about the “off” parameter, and never noticed that one before. There’s indeed no doc about it, and reading the driver itself yields no more doc except the fact that it’s used by function cpufreq_disabled() which returns it, indicating that it’s indeed used to turn off cpufreq. Thus it’s meant to be used on the kernel’s command line when cpufreq is built-in I guess, in order prevent it from starting. You could also load the module with “modprobe cpufreq off=1” which will do nothing (it will reject any setting and frequency changes).
Please note that I’m seeing you for the second time mention “RADXA implementation” and comparing it to “Pi devices”. But for this it has nothing to do with RADXA nor RPi, cpufreq is a standard feature. Some SoC vendors may implement specific drivers for their hardware, but beyond that, the rest is standard and will apply the transitions decided by the selected scaling governor.
@willy, Right, cpufreq is kernel scope if you will. I reference to Pi devices, versus RADXA is just the qualification that what I learned working with Pi devices, is also applicable RADXA devices, in the context of kernel feature set, or even the same OS distribution, for example, /proc/cpuinfo is comparable across any system running Liunx. The parallels (and literal differences) between RADXA and Pi devices, are of specific interest to me, since I am developing/enhancing my monitoring tool that I hope to be as portable as possible… in this case supporting Pi devices and adding support for RADXA devices.
One significant difference is RADXA (3E and 3W for example) has not qualified a revision code, comparable to what Pi devices have had since inception. I had to implement in my tool, a lookup table, using the serial number as a sort key, to return board revision information, this is static, which is unfortunate. Per RADXA, they have not implemented a programmatically accessible way to query for the actual board revision. Zero can be, if memory serves, 1.4, 1.5.1.51, 3E 1.2, 3W 1.12 for example. Is this significant at this time? For the original Zero it is (IMHO) since there are key differences, as I recall the wireless IC changed. Because I want to track such deltas I had to develop my own method.
I see, but then it’s a different topic. There’s a difference between comparing software and detecting hardware. There can be more differences between two Radxa devices (e.g. one Arm and one x86) than between an Arm-based Radxa and an RPi. That’s why I’m insisting that software-wise it’s not the brand that makes the difference but the software that’s running (though some brands just assemble plenty of untested stuff together and call that an image but that’s a different story).
Here what you describe is how to enumerate the hardware. In the x86 world, there’s a flash with the BIOS/UEFI/call-it-as-you-want that stores plenty of info, including board version and whatever can be interesting. In the SBC market, it’s really not that common (often it’s the SPI NOR that’s in charge for storing such info as part of the boot loader environment, and most often it’s not even initialized). Most often they relied on the fact that you flash an image dedicated to that specific model, and that was enough to return the info! Now instead, some SoC vendors provide alternatives to detect various info via external pins. For example Marvell uses “SatR” which are a few bits read at reset and reported to the boot loader. They’re sufficient to configure DRAM size/speed or a board model or revision for example. Rockchip seems to use SARADC pins by default to detect a number of settings from analog readings (boot device etc).
Each vendor will then resort to the mechanisms that are made available to them. On the RPi they’re probably using a few pins to configure the RAM size and the board type and revision. Maybe there’s a little bit of eeprom embedded into the SoC, I don’t know. But as you can see it’s not a vendor versus another one, rather an SoC technology or vendor providing easy ways to expose some info.
Right, you stated it, “or vendor providing easy ways to expose some info” that is key, at least for some of information I am trying to find on RADXA devices, comparable in some way to Pi devices, when I wrote my original tool.
Where things are consistent (at least from a programmatically accessible point), so much the better, kernel level, etc. Reminds me, how many years did it take DMI to become the standard it now is? Or IPMI even? Never mind SNMP. The world of SBCs is still quite dynamic, and the various RISC based units, very dynamic. But I digress.
It is vendor versus vendor, only in the sense… vendor A implements something, and vendor B may or may not implement something comparable. For example both Pi devices and RADXA do have a device ‘descriptor’ string, i.e. model string. Pi devices only implemented this recently compared to their initial device releases that had only the embedded ‘revision’ code value, what since 2012. The model string as I recall came about as an enhancement many suggested. RADXA pretty much from day one had this model string implemented… How it is implemented, as a programmer I don’t (usually) care. If it was/is from the kernel? Not unique to the hardware, I stand corrected, but it did take a while to appear in the Pi world.
Of course, once a given idea takes on value, it tends to be adopted by more and more vendors, as comparable feature. To provide marketing leverage, what have you. It simply becomes a ‘standard’ programmers can code to or leverage. As new vendors enter the market, they are expected, by programmers to continue said features, as general rule, this how many standards developed bottom up, versus being published as a standing RFC top down, vendors agreed to support. USB was qualified standard from day one, and adopted by many, a top down IMHO. But a ‘mouse’ was implemented at the hardware level many different ways, bottom up, across various vendors, for example, serial port mice, PS/2 mice, ADB mice (Apple), I even recall there was mice that used the parallel port! Even mouse design, varied, 1 button, 2 button, 3 button, track ball, the Xerox ‘piano’ mouse developed at XParc… not even ball based. Now, because of USB which came much later, you really cannot find any mouse that is not USB (or well BlueTooth) based at this point, nor do you find much variance in the mouse form factor now, and the ball replaced by optical sensor! Any other mouse implementation, for the most part, exists only as an element of retro-computing, a historical artifact if you will.
I marked this thread solution at the point where you qualified the ‘off’ feature, since that was the outstanding question, given I did find the frequency reporting I needed early on. But the discussion, I have enjoyed and thank you for your insights and perspective. I plan to support RADXA devices in comparable manor to the Pi devices I have for years, so I think I be in the forum often.
That reminds me… I wonder how we can get the kernel into the 6.6.x range, from 5.1.x where it is now (Debian XFCE image B6). LOL… A question for another day. Thanks again.
The difficulty to identify hardware revisions is not specific to vendors but to the SBC world where price matters a lot. Almost no vendor is willing to spend $0.50 to add an extra SPI NOR to store specific info, especially if that only serves to identify the board’s revision. So barring this option, what’s left is what’s easily available from the SoC, and that becomes clearly limited. I think you’ll rarely find such information from such devices in general. As I said, I don’t know where RPi stores that info (maybe inside the SoC itself) but that’s not something that can be generalized to all other devices, regardless of the vendor.
LOL… So either Pi devices found a really ‘cost’ effective way… or they just did it… and set an expectation, that others will be compared against.