Since I wasn’t happy about the old piStats, I’ve forked it and done a partial rewrite adding support for Pi4/5 and PMIC plus a few other things.
Useful to check stability and the OC, nothing to install.
You can download the latest release here.
This is the repo:
Cheers
thx for sharing.
Tested so far only on the Pi5.
I have (should) as well; Pi 1, Pi2, Pi Zero, Pi 4.
If you have another Pi that I miss let me know if you find issues.
There’s a typo in the array for the PMIC voltage so it’s displaying twice the VDDQ.
Easy to fix.
Neat…thanks!!!
Tested and approved on RPi 4 
Thanks!
If you still have it connected, could you please post an output of:
vcgencmd pmic_read_adc
root@RPi4:~# vcgencmd pmic_read_adc
error=1 error_msg="Command not registered"
Use 'vcgencmd commands' to get a list of commands
commands="
commands,
set_logging,
bootloader_config,
bootloader_version,
cache_flush,
codec_enabled,
get_mem,
get_rsts,
measure_clock,
measure_temp,
measure_volts,
get_hvs_asserts,
get_config,
get_throttled,
pmicrd,
pmicwr,
read_ring_osc,
version,
otp_dump,
set_vll_dir,
set_backlight,
get_lcd_info,
arbiter,
test_result,
get_camera,
enable_clock,
scaling_kernel,
scaling_sharpness,
hdmi_ntsc_freqs,
hdmi_adjust_clock,
hdmi_status_show,
hvs_update_fields,
pwm_speedup,
force_audio,
hdmi_stream_channels,
hdmi_channel_map,
display_power,
memtest,
dispmanx_list,
schmoo,
render_bar,
disk_notify,
inuse_notify,
sus_suspend,
sus_status,
sus_is_enabled,
sus_stop_test_thread,
egl_platform_switch,
mem_validate,
mem_oom,
mem_reloc_stats,
hdmi_cvt,
hdmi_timings,
readmr,
vcos,
ap_output_control,
ap_output_post_processing,
pm_set_policy,
pm_get_status,
pm_show_stats,
pm_start_logging,
pm_stop_logging,
vctest_memmap,
vctest_start,
vctest_stop,
vctest_set,
vctest_get"
Released a couple of fixes, you can download the latest release on GitHub as usual
v1.13
v1.12
My 2 cents about the clocks of the Pi 5, give it a try if you like.
What you should add to config.txt always:
isp_freq=910
sdram_freq_min=4267
arm_freq_min=600
And the overclock:
over_voltage_delta=22000
arm_freq=3000
v3d_freq=910
Anything else specified will make things worse or just the same.
isp_freq: This is bizarre but I need it on the dietPi image to get full bandwidth on network I/O, not with the Pi OS image. Anyway it doesn’t hurt specifying it, it’s the default clock
sdram_freq_min: Supposedly this is doing nothing. Maybe, I can’t check it myself. It’s mandatory otherwise if you lower the arm cores minimum clock below 1500 MHz, it’ll become unstable. You MUST NOT set sdram_freq and you MUST shutdown and unplug for 10 seconds the power supply (otherwise the Pi 5 will keep doing weird stuff)
arm_freq_min: Don’t go below 600. Works best and has a slightly better power consumption.
over_voltage_delta: use only the delta and not the other options, adjust it accordingly to the quality of you silicon. My other Pi 5 needs only 18000 (18 mV) for the same
arm_freq: It should be easy to get it to 3 GHz stable with these settings. You can set anything but it’s probably better a multiplier of the min clock, 2700 is a good candidate in the middle
v3d_freq: This should be at 910 MHz but it’s “factory overclocked” to 960. Probably not an issue at the standard clocks but quite a pain point for OC, my worst silicon Pi 5 needs it a 910 the other one doesn’t care. Set it at 910 if you want to be on the safe side.
v1.14
I think it’s almost complete, if you have something else to suggest let me know otherwise will probably consider it done
For completion:
isp_freq etc. should all default to 910, hence setting them explicitly to 910 should not make any difference. If it does, this would indicate a firmware or kernel bug. It makes sense to verify that carefully whether this really makes a difference.sdram_freq_min should not have any effect on RPi 4 and 5, same as sdram_freq. If it does, it again would be a bug. So similarly, it makes sense to carefully test this, and rule out coincidences or other interfering factors.Where did you get this information from?
I have no idea about why isp_freq would need to be set at 910 on the dietpi image.
It’s really bizarre, it’s same the same on both Pi 5 and for both of them is not needed on Pi OS.
About sdram_freq_min can only guess but it’s more plausible.
If really does something… I trust my testing of course but someone else should verify it as well.
Problem is that to verify it you need to have a lot of patience using the standard clocks or have a really 100% safe overclocking.
I suspect there are very few running a stable 3 GHz OC.
I’ll write a guide to OC, hopefully it’ll help.
The 910 MHz is documented here:
Similarly the sdram_freq_min=4267 at the bottom.
Yeah makes sense 1 or 2 verify it, and then we should report it do RPi devs. I’ll do so over the weekend.
Just overclocked my Pi5 with above settings in config.txt
5 minute benchmark yielded a stable system with max 71C.
Would setting the arm_freq_min=1500 as per the chart mean more power usage / stability?
mannix - what setting did you change to get kern: 3000/3000 MHz?
For the kernel use the -q option.
Yes the min frequency at 1500 means more power usage in idle and higher temperatures.
But it’s the safe option of course.
Up to you to take the risk.
If you want to check the OC, install phoronix test suite and run the build-nodejs benchmark.
For me, I even need to use 1700, otherwise I have a lot of I/O errors ending with r/o file system. But I need to say, I’m using RaspiKey eMMC module instead of SD card.
Wow, I didn’t expect it to be needed higher than the default in any case.
A you using standard clocks otherwise or it’s an OC?
Nope just default. The only change I did was the to remove initial turbo.
Will need to retest with a regular SD.
Well it’s an interesting scenario.
Could you try with the default 1500 and isp_freq=910 plus sdram_freq_min=4267 if it makes a difference?
But of course it could pose a risk to the installation so it’s understandable if you can’t 
it’s a demo system
But nope, still ending with r/o fs
Feb 10 10:22:52 DietPi5 kernel: mmc0: running CQE recovery
Feb 10 10:22:52 DietPi5 kernel: mmc0: running CQE recovery
Feb 10 10:22:52 DietPi5 kernel: mmc0: running CQE recovery
Feb 10 10:22:52 DietPi5 kernel: I/O error, dev mmcblk0, sector 788552 op 0x1:(WRITE) flags 0x800 phys_seg 18 prio class 2
Feb 10 10:22:52 DietPi5 kernel: Aborting journal on device mmcblk0p2-8.
I thought the base 1500 MHz would be safe for everything…
Does it work adding a small delta offset like over_voltage_delta=4000?