So it appears that the Pi Zero 2 W is now available.
When can we expect a release that supports this particular (and slightly different) hardware configuration?
I
Answering, in part, my own question I can see a pull request for initial support…
Yes,
it’s on the list. It depends on how fast our developer is receiving a device to test on. But initial support should be available on next release.
I literally just received my pi Zero 2 W and swapped the sd card from my old pi zero into it and it booted perfectly
Then i switched update branches to Zero in the config and did an update, upon reboot and logging back in via ssh it is correctly labelled as
─────────────────────────────────────────────────────
DietPi v7.8.-1 (zero) : 14:43 - Sat 10/30/21
─────────────────────────────────────────────────────
- Device model : RPi Zero 2 W (armv7l)
- CPU temp : 38'C : 100'F (Cool runnings)
- LAN IP : 192.168.1.10 (eth0)
curl: (6) Could not resolve host: dietpi.com
─────────────────────────────────────────────────────
The curl error is odd as network connected fine and redoing that command is success.
The temp shown there is with an overclock at 1300 and gpu 700 (1400 failed to boot but then im plugged into a usb socket on a multiplug outlet rather than a proper psu).
However should be noted to be fair only running adguard on it at the mo so overclock not really needed but, hell why not
But so far so good
─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | armv7l
Temperature | 33'C : 91'F (Cool runnings)
Governor | ondemand
Throttle up | 50% CPU usage
Current Freq Min Freq Max Freq
CPU0 | 1300 MHz 600 MHz 1300 MHz
CPU1 | 1300 MHz 600 MHz 1300 MHz
CPU2 | 1300 MHz 600 MHz 1300 MHz
CPU3 | 1300 MHz 600 MHz 1300 MHz
Nice, so we don’t need to wait for ours to add some more info and overclocking profiles 
.
You manually overclocked it to 1300 MHz, right? Interesting that this works since the default is 1000 MHz (according to docs) and the announcement only talks about 1200 MHz overclocking potential 
. I was already wondering as the RPi 3 SoC (used here) is known to achieve more. I suspect the temperature to raise very quickly, leading to thermal throttling, when doing a stress test with 1300 MHz, isn’t it?
Other things I would be interested in is the default clock rates:
vcgencmd measure_clock core # if variable, at load/max
vcgencmd get_config int # with sdram_freq and core_freq not set in config.txt
Watching both ETA Prime and Toms Hardware these devices will do 400mhz overclock with the correct psu and heatsink.
So i tried 400mhz but it failed to boot so adjusted to 200 then up 50 each time. So mine is stable at 1300mhz.
Yes had to manual overclock as there are no profiles yet in the dietpi config area so just added the flags at the bottom of config file for now
#Overclock 1300
arm_freq=1300
core_freq=525
over_voltage=6
gpu_freq=700
Should be noted i am not running any desktop env at all
If you give me the commands you want answering i will run them and post results, and as mentioned i have no need to OC and adguard is hardl;y going to touch idle speeds lol, i will run a bench a stress at 1300mhx with just heat sink and see what temp it reaches
Here is the dietpi stress test ran for 5 minutes as it peaked between 59 and 62 degress at 1.3ghz (no throttling) using just a cheap £1 PIHUT aluminimum heatsink
Btop activated in the last minute of the test
Great, so 1300 Mhz should be the highest profile for now then. Awesome that a fanless heatsink is sufficient.
I think I edited two commands inside my post above to check for default GPU core and RAM clocks. Would be great of you could paste their output here 
.
Sorry see results below with OC removed
Same commands with overclock removed
Higher number whilst startup bits n bobs are finishing then lower is idle
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=400000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=400000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=400000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=400000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=400000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=249999000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd get_config int
aphy_params_current=819
arm_freq=1000
arm_freq_min=600
audio_pwm_mode=514
config_hdmi_boost=5
core_freq=400
desired_osc_freq=0x331df0
disable_commandline_tags=2
disable_l2cache=1
disable_overscan=1
disable_splash=1
display_hdmi_rotate=-1
display_lcd_rotate=-1
dphy_params_current=547
dvfs=3
enable_tvout=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_depth=16
framebuffer_ignore_alpha=1
framebuffer_swap=1
gpu_freq=300
hdmi_blanking=1
ignore_lcd=1
init_uart_clock=0x2dc6c00
initial_turbo=20
over_voltage_avs=6250
pause_burst_frames=1
program_serial_random=1
sdram_freq=450
temp_limit=65
total_mem=512
hdmi_force_cec_address:0=65535
hdmi_force_cec_address:1=65535
hdmi_ignore_hotplug:0=1
hdmi_pixel_freq_limit:0=0x9a7ec80
I think the 1400 is achievable with a proper PSU, tomorrow i will dig out the psu i have somewhere and test my unit, i presume a fan based cooler would achieve more but is it worth it on a board a fraction of the size of a fan lol
Okay thanks. over_voltage=6 was required for this? Probably also 1400 MHz is reachable when leaving gpu_freq and core_freq untouched. Btw, gpu_freq adjusts a lot of individual GPU feature/decoder frequencies with lower defaults, which are likely not all required, core_freq, if set, overrides this for the core only, which affects L2 cache and RAM performance as well: https://github.com/raspberrypi/documentation/blob/develop/documentation/asciidoc/computers/config_txt/overclocking.adoc
Would be also interesting whether raising sdram_freq to e.g. 500 (450 is default) works fine. RAM speed generally should be an allrounder benefit, but I remember from other RPi models that those react sensitive to raising it.
I added overclocking profiles for RPi Zero 2 (and missing ones for RPi 400 in the same turn): https://github.com/MichaIng/DietPi/blob/zero/dietpi/dietpi-config#L3526-L3564
Those raise CPU and GPU core frequencies both, but leave the other GPU frequencies untouched. I was thinking whether we should create more targeted profiles, like a video/movie profile which raises especially the h264/HEVC frequencies, a gaming profile which does this for the 3D frequency instead and a camera profile which raises the image sensor frequency (not exactly sure about the effect of this), and all of them raising CPU and GPU core a little less?
Okay so just tested and will update when i find out which one
Removed GPU OC and removed Overvoltage and added in sdram-freq
Result is fail too boot at 1.3Ghz
So now i will do one at a time to see which one caused it
Update 1
So these settings wont boot
#Overclock 1300
arm_freq=1300
#core_freq=525
#over_voltage=6
#gpu_freq=700
sdram_freq=500
So removed sdram first and this also does not boot at all
#Overclock 1300
arm_freq=1300
#core_freq=525
#over_voltage=6
#gpu_freq=700
#sdram_freq=500
So put back overvoltage and sdram
#Overclock 1300
arm_freq=1300
#core_freq=525
over_voltage=6
#gpu_freq=700
sdram_freq=500
And she boots back up fine
So now tried the following settings
#Overclock 1350
arm_freq=1350
#core_freq=525
over_voltage=6
#gpu_freq=700
sdram_freq=500
And she boots back up with the following info
Temperature increased by 2 degrees to 35oC
root@DietPi:~# vcgencmd measure_volts core
volt=1.2000V at idle
When booting and working at 50%
root@DietPi:~# vcgencmd measure_volts core
volt=1.3563V
root@DietPi:~# vcgencmd measure_clock core
frequency(1)=250000000
root@DietPi:~# vcgencmd measure_volts core
volt=1.3563V
root@DietPi:~# vcgencmd get_config int
aphy_params_current=819
arm_freq=1350
arm_freq_min=600
audio_pwm_mode=514
config_hdmi_boost=5
core_freq=400
desired_osc_freq=0x331df0
disable_commandline_tags=2
disable_l2cache=1
disable_overscan=1
disable_splash=1
display_hdmi_rotate=-1
display_lcd_rotate=-1
dphy_params_current=1091
dvfs=3
enable_tvout=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_depth=16
framebuffer_ignore_alpha=1
framebuffer_swap=1
gpu_freq=300
hdmi_blanking=1
ignore_lcd=1
init_uart_clock=0x2dc6c00
initial_turbo=20
over_voltage=6
over_voltage_avs=6250
over_voltage_sdram_p=2
pause_burst_frames=1
program_serial_random=1
sdram_freq=500
sdram_schmoo=0x2000020
temp_limit=65
total_mem=512
hdmi_force_cec_address:0=65535
hdmi_force_cec_address:1=65535
hdmi_ignore_hotplug:0=1
hdmi_pixel_freq_limit:0=0x9a7ec80
For info setting at 1350MHZ is obviously not a stepping avaliable as it shows in coth CPU and BTOP as 1.4Ghz
So running aqt 1.4Ghz and setting off a 5 min stress test caused it to crash at approx 35secs (again could be y dodgy psu) temp only reached 54Degrees
so will now set back to 1.3G and see if it makes the 5 min stress test, if not will remove sdram setting and test again
Okay so setting back to 1.3ghz with these settings and running a 5minute stress test, it completed fine, was heatsoasked at 63oC but spent more time at 62oC no throttling at all
#Overclock 1300
arm_freq=1300
#core_freq=525
over_voltage=6
#gpu_freq=700
sdram_freq=500
And finally
I tried a more beefy PSU (the one i did all the tests is only 2.1amp and recommended is 2.5A)
Tried at 1.4Ghz with the same settings and again it crashed in less than 20secs, so obviously more a cpu issue than psu issue
Okay
Update, after about 2 hours the pi became unresponsive, which it did not do yesterday at all all day, so now removed the sdram flag to see how she runs now
And as a final final test -
I tried diff over voltage values
All with just 1.3ghz and no sdram flag applied
No Over Voltage - Failed too boot
OV = 2 - Failed to boot
OV = 4 - Booted fine and finished 5 minute stress test
Ah yes sorry, I didn’t mean to remove over_voltage but only reduce the value. Good to know that 4 is sufficient. For the highest profile I’ll use 5 then, to be sure. When we have some more system which prove to runs table with 4 on the highest profile, we may reduce it for lower power consumption > temps .
So sdram_freq=500 doesn’t run stable (at least when raising other clocks) at all it seems? Sad but a valuable result as well .
And 1.4 GHz doesn’t run stable, at least not on all individual boards, so we shouldn’t add that as a profile.
Ah and of course 1350 MHz does not work: The more recent firmware versions allow stepping in 100 MHz steps only. I need to adjust our profiles as well accordingly, haven’t had that in mind and with early Linux v5.4 based firmware and before the steps were different (means some profiles were invalidated in the meantime). Interesting that the system rounds up instead of being conservative and rounding down consequently 
.
Very valuable tests, many thanks for this!
No problems at all
Yeah so far it’s running like a champ at 1.3Ghz Overvolt set to 4, and has not crashed since i removed the sdram flag.
I know all boards are different but a starting point for when you have your own and aggregate the results
Great. I further tweaked the overclocking profiles now, removed the sub 100 MHz steps (which are not effective anymore) and added some energy saving profiles for other models, which now also reduce idle voltage, not only load voltage: https://github.com/MichaIng/DietPi/pull/4907
It’s great to see there’s news of the new Pi Zero 2 support incoming, as I’ve just ordered one!
I’m looking to do a fresh install on a new SD card for the new Zero 2, and was wondering which would be the most suitable version. As the new Zero 2 has the same SoC as the RPi3 (afaik), I was looking at the ArmV8 64bit Debian release. Would that work in the interim before official support is here? I’m looking for a purely headless install, running PiHole, TvHeadend, VPN, qBittorrent, and SAMBA.
I did think of just using the card in the original Zero, but that install has reliability issues regarding the SAMBA share failing and requiring a reboot occasionally.
Thanks for DietPi, it’s simply awesome.
Hi everybody, long time reader first time poster…
I did some testing yesterday. I did a fresh install with the v7 version, and everything works out of the box. (the v6 version also works btw)
The only thing was “Device model : RPi (Unknown) (armv7l)” . Then i switched to the zero branch, but it broke dietpi-config and dietpi-launcher, so i switched back for now. I can also confirm all the tests CassTG did… (1.3 is the max 
)
DietPi 7.8 will be released on 13th of November and will contain initial support for the Pi zero 2 W. You could use every image that is available for RPi devices