Raspberry Pi Zero 2 VMOD
Table of contents
Clocking problems require modding solutions1
Since my Raspberry Pi Zero 2 isn’t the jackpot of the official silicon lottery and it can’t go higher than 1,405 MHz, even with sub-zero temperatures (about -25 °C), I want to give the Zero 2 one last time to shine.
Bypassed VDD_CORE (Powering the RPi, Part 3)
The built-in overvoltage-feature for the processor (over_voltage) inside /boot/config.txt works from 0 (1.200 V) to 8 (1.400 V).
In order to get a higher clock speed, I needed more voltage.
Like in my last two articles (Powering the RPi, Part 1 and Part 2) about possible and working voltage-modifications, the RPi Zero 2 is no exception for hooking up an external power source to inject a voltage.
The schematics2 tell you, that C162 is a good spot to hook your external voltage. Unfortunatelly the PCB is not labeled, so I had to measure where to find the VDD_CORE.
For V_DDR you have to find C268.
The measured locations are shown in these pictures. Red for VDD_CORE and purple for V_DDR.
Setup
Before mouting my Prometeia to the modded board, I tested it with air-cooling. No hard overclocking just looking, if the RPi Zero 2 will survive an injected voltage.
Turns out, it will survive and I easily broke the 1,350 MHz barrier. With about 1.500 V (+100 mV) I overclocked the RPi to about 1.4 GHz and ended the air-cooling session.
I used an ElmorLabs AMPLE 20A Power Card3 as my external power source. It worked really well. Great piece of hardware.
Time to mount my Prometeia SSPC and look what this little Pi could take.
The journey ended at 1,495 MHz at about 1.525 mV and a really frosty RPi Zero 2.
This is not the final ending. I had to stop testing.
Results
With added +125 mV, I was able to gain an extra 90 MHz. Not impressive, but it’s some kind of progress.
Running under these circumstances, the setup was not stable. I could run some benchmarks, but there must be a round #2.
| Cooling | Clock_Speed | Clock_Change | VDD_CORE | Result | Result_Change |
|---|---|---|---|---|---|
| Air | 1,000 MHz | 100 % | 1.200 V | 2,270 pts. | 100 % |
| Air | 1,350 MHz | 135 % | 1.400 V | 2,619 pts. | 115 % |
| SSPC | 1,405 MHz | 141 % | 1.400 V | 2,670 pts. | 118 % |
| SSPC | 1,495 MHz | 150 % | 1.525 V | 2,756 pts. | 121 % |
Weird behavior
When I reached 1,450 MHz things got a little bit weird.
Any MHz higher than 1,450 ended in a lower frequency. The ARM-frequency was off, but PLLB was right. Changing arm_freq and rebooting didn’t help.
Normal behavior: The saved arm_freq (1,450 MHz) inside /boot/config.txt is identical as the current frequency the system is running with. PLLB shows a two times higher clock, which is normal, since it have a divider of 2.
Wierd behavior: I wanted 1,455 MHz, PLLB does show the right value of 2,910 MHz, but the read-out frequency is off. It shows 1,446,41 MHz.
Weird behavior: Same for 1,475 MHz. PLLB shows the right value (2,950 MHz) but 1,445.82 MHz are read-out. Nice to see, that this frequency is lower than the previous one.
Then I overclocked the RAM and the arm_freq was magically repaired. I have no idea why and if it’s causality or just correlation.
Maybe I’ll wait for a new firmware-release. If the behavior doesn’t change, I’ll file an issue and keep you updated.
Conclusion
I didn’t find a software limitation, probably there is one at 1,600 MHz, but therefore I have to gain an additional 105 MHz.
Maybe when I have a few more Zero 2s and find one which clocks better, we find a barrier.
For now, I know what to do. Bypassing VDD_CORE works, 1.5 GHz is near and V_DDR wasn’t touched at all.
I’ll keep you updated!