Release DE10 Nano Overclock Kernel BETA

[Coolbho3k]

Intro
I've found a way to overclock the MPU subsystem (the Cortex-A9 CPU cores) in the DE10 Nano, and I've written a kernel driver to help facilitate it. You can try it out here.

Why overclock the CPU?

• Overclocking should help with hybrid emulation efforts on the ao486 and Amiga cores

• Slightly reduce game loading times on some cores

• Will help with anything else CPU-bound - your imagination is the limit. I've heard of possible improvements to MIDI stuff

• Underclocking to 400 MHz saves an estimated 140 mW (measured on MiSTer main menu) and doesn't affect many core's performance

What will this NOT help with?
This driver adds the ability to overclock the MPU subsystem - the part of the Cyclone V SOC that runs Linux. It will not make any FPGA core run faster unless you are doing hybrid emulation.

Risks: READ BEFORE INSTALLING
This driver is in beta. I don't believe it should harm your DE10 Nano if you have good cooling, as all in all it's a very small increase in wattage and heat is manageable on other Cortex-A9 devices at these frequencies manufactured at a similar process node. These are very low power CPUs designed for phones. Increasing the input voltage is generally a riskier factor than frequency, and this driver never touches it - it's fixed at 1.1V on the DE10 Nano.

To be on the safe side, I'm going to say that ACTIVE COOLING or VERY GOOD passive cooling is REQUIRED. I've only tried this with active cooling.

Proceed at your own risk - as a GPLv2-licensed software, the kernel and driver come with NO WARRANTY.

Features

• Fully featured CPUfreq driver for DE10 Nano

• Initially: 1.2 GHz, 1 GHz overclock options; 400 MHz underclock option

• Control overclock with scripts from userspace

• Driver keeps CPU frequency at stock until a script is run

• 1200 MHz uses only approximately 160 mW more than stock on MiSTer main menu (results will vary depending on your setup)

• Optional dynamic frequency scaling based on system load*

*Currently, this will rarely keep the CPU below the max clock speed you set because the MiSTer process keeps one core at 100% load, so I haven't included scripts to configure this.

Installation
Step 1: Run overclock scripts
Copy all the scripts to the Scripts directory on your SD card: https://github.com/coolbho3k/MiSTer-Overclock-Scripts

By default, the system boots up just at the stock frequency and is locked at 800 MHz. Run one of the scripts to overclock or underclock. The changes are not persistent. Rebooting your DE10 Nano resets any of your settings.

• Run set_cpu_max_1200.sh to set max clock speed to 1.2 GHz (50% overclock)

• Run set_cpu_max_1000.sh to set max clock speed to 1.0 GHz (25% overclock)

• Run set_cpu_max_800.sh to set max clock speed to 800 MHz (stock)

• Run set_cpu_max_400.sh to set max clock speed to 400MHz (half speed)

If the system crashes, your Cyclone V is not stable at the specified frequency. Just power cycle the board to reboot.

Development
Incorporating into your kernel
Currently the changes are merged into the main MiSTer kernel.

This is my original development branch: https://github.com/coolbho3k/Linux-Kern ... /overclock

Further development
There may be a way to overclock the memory too. The memory chips on the DE10 Nano BOM are rated at DDR3-1066, while the DE10 Nano runs them at DDR3-800. I'm not sure if this will affect the FPGA side of things. If so, I'm also not sure if this would help alleviate the need for the SDRAM for some cores. It might be worth looking into.

Upstreaming to mainline Linux is a goal but will be a bigger challenge, as this driver is currently DE10 Nano-specific, and cannot be generalized to all Cyclone V SOC/Arria V SOC implementations without some more work. For example, it assumes that clock dividers have been set up in a certain way in u-boot and assumes and an input clock of 25 Mhz.

[Neocaron]

This is absolutely awesome! I brought the idea up a few months back and people were more than perplexed to say the least when I mentioned it. But with a 50% OC, it's a massive boost and it opens up a lot of possibilities for now and the future. And of course you need proper active cooling, but who doesn't have one this days. In this case it's just mandatory! This should help massively for hybrid cores and even for running things like Dosbox and many other!

Thank you for taking the time to do this! And I hope you'll look into the memory OC as well!

[jurkevicz]

I'll be testing this. I hope we can eventually make the overclock permanent.

[Coolbho3k]

I'll be testing this. I hope we can eventually make the overclock permanent.

It will be very easy to do that. You can run what the script runs every time the system boots. ie. just add the following line to /media/fat/linux/user-startup.sh

Code: Select all

# For 1.2 GHz
echo "1200000" > "/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq"

Other options are 1000000 for 1 GHz, 400000 for 400 MHz

I have made none of the "easy" options permanent for now so people can experiment with what frequencies are stable on their device.

[FoxbatStargazer]

Is the ARM chip part of the cyclone V itself? The thing we usually stick the heat sink on?

If so, is there some issue where the more complex cores might be more likely to run into stability problems alongside this overclock? Like ao486, neo-geo, or psx.

The ARM is chip is slow for MUNT and even fluidsynth has some problems, so AO486 is actually one of the major use cases for this overclock, so it would be ironic if it ends up conflicting.

[Coolbho3k]

Is the ARM chip part of the cyclone V itself? The thing we usually stick the heat sink on?

If so, is there some issue where the more complex cores might be more likely to run into stability problems alongside this overclock? Like ao486, neo-geo, or psx.

The ARM is chip is slow for MUNT and even fluidsynth has some problems, so AO486 is actually one of the major use cases for this overclock, so it would be ironic if it ends up conflicting.

Yup - it's part of the same chip.

For all the reasons you mentioned, this is why I've released this as beta - I've tested the Linux side pretty well, but I have not tried AO486 yet. I'm eager to run more benchmarks and eager to get ideas here for what to test. I expect this to help anywhere we're limited by the relatively weak HPS CPU.

As for this causing problems, from my tests, the power draw increase from overclocking even 50% is honestly pretty trivial. These ARM cores are already really low power, really mobile phone parts, even a 50% increase is not going to be adding a lot of heat to the system in absolute terms. Then again, there is no temperature sensor on the die, but we are adding well under half a watt total here, on a chip with decent cooling, so I'm not worried from a temperature standpoint.

Remember there is a higher speed grade of the Cyclone V with essentially the same silicon but faster binning - running at 925MHz - but being a commercial and not industrial part, with a much lower temperature rating - 85 °C instead of 100 °C! And the Arria V has a pretty similar HPS and has a bin running at 1.050 GHz. So 1 GHz is not really crazy at all and 1.2 GHz is not really that crazy IMO. You can choose 1 GHz if 1.2 GHz ends up being on unstable on your board.

Current draw of my whole DE10 Nano stack with a few USB devices, averaged over 1 minute, sitting on the MiSTer main menu:
1200 MHz (1.5x overclock): 1.254 A ~= 6.27 W
800 MHz (stock): 1.223 A ~= 6.12 W
400 MHz (2x underclock): 1.195 A ~= 5.98 W

I did have a test setup for total system power to confirm.

dmm.png (513.41 KiB) Viewed 57280 times

[Neocaron]

Is the ARM chip part of the cyclone V itself? The thing we usually stick the heat sink on?

If so, is there some issue where the more complex cores might be more likely to run into stability problems alongside this overclock? Like ao486, neo-geo, or psx.

The ARM is chip is slow for MUNT and even fluidsynth has some problems, so AO486 is actually one of the major use cases for this overclock, so it would be ironic if it ends up conflicting.

Tried with a few cores, including AO486, PSX and the Dosbox emulator and no problem so far regarding stability with the 50% OC. And for emulation, Dosbox got a massive boost in performance basically the same as the OC, 50%!!!. Also everything felt very snappy in the mounting process for the PSX, but maybe it's just placebo, because it was fast before. Nevertheless it's amazing stuff really!

[amstan]

This is cool!

What's your heatsink situation like? It would be nice to use it as inspiration for improving my cooling setup too.

*Currently, this will rarely keep the CPU below the max clock speed you set because the MiSTer process keeps one core at 100% load, so I haven't included scripts to configure this.

This worries me a little bit. In past machines I've worked on this is sometimes where things go unstable (not necessarly because of the higher speed, just the act of switching frequencies). While Main_MiSTer probably does keep the cpu busy and in the fastest frequency, i could imagine the super rare case where it might not. In such cases you might have extremely hard to reproduce crashes.

I would either disable the frequency shifting (the userspace governor might do that), or test the switching really thoroughly. I've used a bash loop in the past that would change scaling_setspeed randomly while something else running that would verify stability (superpi perhaps? forgot the program).

[Coolbho3k]

This is cool!

What's your heatsink situation like? It would be nice to use it as inspiration for improving my cooling setup too.

*Currently, this will rarely keep the CPU below the max clock speed you set because the MiSTer process keeps one core at 100% load, so I haven't included scripts to configure this.

This worries me a little bit. In past machines I've worked on this is sometimes where things go unstable (not necessarly because of the higher speed, just the act of switching frequencies). While Main_MiSTer probably does keep the cpu busy and in the fastest frequency, i could imagine the super rare case where it might not. In such cases you might have extremely hard to reproduce crashes.

I would either disable the frequency shifting (the userspace governor might do that), or test the switching really thoroughly. I've used a bash loop in the past that would change scaling_setspeed randomly while something else running that would verify stability (superpi perhaps? forgot the program).

Not a problem just yet! Right now the default `scaling_governor` is `performance` on boot, which keeps frequency always at `scaling_max_freq`, which is set to 800 MHz by the driver.

I've run a few hours of a Python script just writing 400 MHz and 1200 MHz to `scaling_max_freq` (tens of thousands of transitions) and didn't run into a crash.

If I set the speed to 266 MHz (not in the driver) and then scale it up to 1200 MHz, I get crashes. Not sure why.

[ToothbrushThreepwood]

Has anybody tried MUNT at 50% OC?
As someone who has gone from mt32pi first on a Pi3 to a PiZero2 now, I’d love to come full circle and have it emulated onboard.

[Thedad]

Has anybody tried MUNT at 50% OC?
As someone who has gone from mt32pi first on a Pi3 to a PiZero2 now, I’d love to come full circle and have it emulated onboard.

I'm feeling exactly the same. I'd love to simplify the MiSTer setup which removes the extra hardware for mt32pi.

I'm gonna have a look at this, but I reckon the results will be subjective.

[Neocaron]

Everything is still stable for me after hours of testing different cores with 50% oc. Still looking awesome so far! Played a bunch of games in Dos with the Ao486 and no instability to report on my side.

[jurkevicz]

Same Here. I left overnight PSX running Quake II and Temps are Stable.

[Bas]

The FPGA doesn't heat the chip more if you overclock it. Hit the CPU to 100% on both cores and leave that running overnight, that'll show effects if there are any to be expected. Run AO486 with a midi soundtrack over the embedded MUNT for instance, that actually taxes the CPU.

[KremlingKuthroat19]

Very cool development! Just curious about the possibilities. Does this mean that some cores that were impossible may be more realistic (a.k.a. N64; which I know is a longshot due to it requiring too much memory, but maybe a hybrid approach is possible with this), or is it more likely that it'll just be a performance boost for existing and new cores?

[FoxbatStargazer]

I've been playing around with local MIDI on Atari ST, Amiga, and even A0486. With the 50% overclock MUNT is far more usable, although I'm still hearing minor timing errors here and there, so it doesn't quite replace an MT-32 pi. You can also try turning down the quality with "MUNT_OPTIONS = -n -l 1" in midilink.ini (disable reverb and lower analog quality 1 notch), though I'm not sure performance appreciably improved.

A pretty good stress test is the soundtrack for the first forest area in Lands of Lore: Throne of Chaos on PC, the jumble of notes there can even mess fluidsynth up at default clocks, let alone MT-32. Without overclock the buffer would be so overwhelmed that it just crawls or stops, this doesn't happen at 50% overclock so its more than playable and enjoyable. But I think there is still something to be gained from a dedicated Pi to perfect the timing, at least for MT-32. (Fluidsynth sounds about perfect with the overclock now, and is a good comparison point for evaluating timing.)

Should note I also have the 1ms USB polling adjustment, I don't know if that consumes substantial CPU cycles.

[Neocaron]

I've been playing around with local MIDI on Atari ST, Amiga, and even A0486. With the 50% overclock MUNT is far more usable, although I'm still hearing minor timing errors here and there, so it doesn't quite replace an MT-32 pi. You can also try turning down the quality with "MUNT_OPTIONS = -n -l 1" in midilink.ini (disable reverb and lower analog quality 1 notch), though I'm not sure performance appreciably improved.

A pretty good stress test is the soundtrack for the first forest area in Lands of Lore: Throne of Chaos on PC, the jumble of notes there can even mess fluidsynth up at default clocks, let alone MT-32. Without overclock the buffer would be so overwhelmed that it just crawls or stops, this doesn't happen at 50% overclock so its more than playable and enjoyable. But I think there is still something to be gained from a dedicated Pi to perfect the timing, at least for MT-32. (Fluidsynth sounds about perfect with the overclock now, and is a good comparison point for evaluating timing.)

Should note I also have the 1ms USB polling adjustment, I don't know if that consumes substantial CPU cycles.

I'm gonna get greedy now, but could 1.25 or 1.3 be enough to iron out the imperfections? Do you consider it usable as it is for most?
Last time I tried Munt it was absolutely unsuable. And finally do you think pushing the memory speed of the DDR3 would help as well for this?

Regarding how this OC could be use for future cores, the minimig result are already mindblowing with close to 100% gain in sysinfo ! viewtopic.php?f=4&t=2397&start=630

Technically as it is, with 50% oc you could probably run an n64 emulator on the arm chip with 10fps.
So depending on how the hybrid approach evolves it might be possible to split up the rendering, and I'm sure the memory overclock to 1033mhz would definitely helps! I never stop to be amazed by the Mister devs, so never say never!

[Coolbho3k]

I've been playing around with local MIDI on Atari ST, Amiga, and even A0486. With the 50% overclock MUNT is far more usable, although I'm still hearing minor timing errors here and there, so it doesn't quite replace an MT-32 pi. You can also try turning down the quality with "MUNT_OPTIONS = -n -l 1" in midilink.ini (disable reverb and lower analog quality 1 notch), though I'm not sure performance appreciably improved.

A pretty good stress test is the soundtrack for the first forest area in Lands of Lore: Throne of Chaos on PC, the jumble of notes there can even mess fluidsynth up at default clocks, let alone MT-32. Without overclock the buffer would be so overwhelmed that it just crawls or stops, this doesn't happen at 50% overclock so its more than playable and enjoyable. But I think there is still something to be gained from a dedicated Pi to perfect the timing, at least for MT-32. (Fluidsynth sounds about perfect with the overclock now, and is a good comparison point for evaluating timing.)

Should note I also have the 1ms USB polling adjustment, I don't know if that consumes substantial CPU cycles.

I'm gonna get greedy now, but could 1.25 or 1.3 be enough to iron out the imperfections? Do you consider it usable as it is for most?
Last time I tried Munt it was absolutely unsuable. And finally do you think pushing the memory speed of the DDR3 would help as well for this?

Regarding how this OC could be use for future cores, the minimig result are already mindblowing with close to 100% gain in sysinfo ! viewtopic.php?f=4&t=2397&start=630

Technically as it is, with 50% oc you could probably run an n64 emulator on the arm chip with 10fps.
So depending on how the hybrid approach evolves it might be possible to split up the rendering, and I'm sure the memory overclock to 1033mhz would definitely helps! I never stop to be amazed by the Mister devs, so never say never!

1.3 GHz is borderline and requires a slight 8% overclock or underclock on some other clocks including the cache fabric. I'd lean toward overclocking those at that stage.

1.4 GHz and 1.6 GHz crash my board instantly. Could still offer those as options for others to test if they are more lucky with the silicon lottery.

Currently stability testing 1.3 GHz on my board. If it looks good I will post an update. Using the same methadology as above, I'm getting a power draw of 1.268 A = 6.34 W

[Neocaron]

1.3 GHz is borderline and requires a slight 8% overclock or underclock on some other clocks including the cache fabric. I'd lean toward overclocking those at that stage.

1.4 GHz and 1.6 GHz crash my board instantly. Could still offer those as options for others to test if they are more lucky with the silicon lottery.

Currently stability testing 1.3 GHz on my board. If it looks good I will post an update.

ok good to know, I feel 1.3 would definitely make Munt viable!

[Coolbho3k]

1.3 GHz is borderline and requires a slight 8% overclock or underclock on some other clocks including the cache fabric. I'd lean toward overclocking those at that stage.

1.4 GHz and 1.6 GHz crash my board instantly. Could still offer those as options for others to test if they are more lucky with the silicon lottery.

Currently stability testing 1.3 GHz on my board. If it looks good I will post an update.

ok good to know, I feel 1.3 would definitely make Munt viable!

Ah damn, I got a crash after a while at 1.3 GHz on the MiSTer main menu.

Can still include it in the kernel for folks to try, but at this level it's definitely on the borderline.

[Neocaron]

1.3 GHz is borderline and requires a slight 8% overclock or underclock on some other clocks including the cache fabric. I'd lean toward overclocking those at that stage.

1.4 GHz and 1.6 GHz crash my board instantly. Could still offer those as options for others to test if they are more lucky with the silicon lottery.

Currently stability testing 1.3 GHz on my board. If it looks good I will post an update.

ok good to know, I feel 1.3 would definitely make Munt viable!

Ah damn, I got a crash after a while at 1.3 GHz on the MiSTer main menu.

Can still include it in the kernel for folks to try, but at this level it's definitely on the borderline.

Could you try + 50mhz at 1.25ghz?

No matter what, we need an OC floor that works across the board for it to be used in some capacities for core development.
Thanks for testing anyway!

[FoxbatStargazer]

I would describe MUNT as "viable" at 1.2, all the notes are there and it sounds good, but the timing is just ever so slightly off in places. I've never used a MT32-pi so for all I know they have the same issues, but I do know musically what the timing should be and can hear that perfect timing using fluidsynth and general midi. (at least with the midilink_updater sc-55 soundfont)

MUNT_OPTIONS = -l # controls the quality of low-pass filters. The default is 2, it seems that 1 or 0 ever so slightly improves the note timings, but the difference is so slight that I'm not sure. It's not quite perfect in lands of lore either way. Reverb doesn't seem to affect performance that I can tell, so that's just up to preference (add -n to shut it off)

[aberu]

I like the idea of the underclock for a sleep mode potentially, that would be nice.

I don't think I'm a fan of the overclocking simply because those of us who help users with problems might get a few more issues as a result of this. It's still worth investigating these possibilities though... But long-term stability of processors is affected by heat, if you overclock you do generate more heat. More watts = more heat. Like OP said, have a good cooling solution if you risk doing this.

For anyone thinking MT32-Pi will be running on this, it would have to be a severely neutered version of it, because the MiSTer is already using 1 of the two cores 100% of the time, it's nowhere near a Raspberry Pi 3A+'s specs in that shape. Maybe some trimmed down version of it.

@Bas The FPGA can get hotter as a result of the ARM getting hotter and vice versa, they share the same thermal interface to the outside world. Metastability of FPGA cores is dependent upon heat, if you get too hot, it can lead to stability issues. If you compile the cores and run timing analysis it will tell you what temperatures each of the results are correlated to.

I'd personally suggest not going any higher than 1.2GHz. If you give that option to people it may ruin a few people's boards unnecessarily who don't read the disclaimer.

[Neocaron]

I like the idea of the underclock for a sleep mode potentially, that would be nice.

I don't think I'm a fan of the overclocking simply because those of us who help users with problems might get a few more issues as a result of this. It's still worth investigating these possibilities though... But long-term stability of processors is affected by heat, if you overclock you do generate more heat. More watts = more heat. Like OP said, have a good cooling solution if you risk doing this.

For anyone thinking MT32-Pi will be running on this, it would have to be a severely neutered version of it, because the MiSTer is already using 1 of the two cores 100% of the time, it's nowhere near a Raspberry Pi 3A+'s specs in that shape. Maybe some trimmed down version of it.

@Bas The FPGA can get hotter as a result of the ARM getting hotter and vice versa, they share the same thermal interface to the outside world. Metastability of FPGA cores is dependent upon heat, if you get too hot, it can lead to stability issues. If you compile the cores and run timing analysis it will tell you what temperatures each of the results are correlated to.

I'd personally suggest not going any higher than 1.2GHz. If you give that option to people it may ruin a few people's boards unnecessarily who don't read the disclaimer.

I think the stable ceiling for most Misters outthere has to be define for sure. So far it seems to be 1.2ghz, but we need more testing from more people. Regarding the heat, I really wouldn't worry. I couldn't see any noticeable difference in the temps with this 50% OC which makes sense since the power usage is barely higher. Of course anything else should be treated as experimental with lots of warnings.

And I'm confused but if Munt works well on the Arm, you don't need MT32 do you? Both are pretty close right? You can still have it but it wouldn't mandatory for midi then. Just an option.

[aberu]

MT32-Pi is a baremetal emulator running essentially at the kernel level (https://github.com/dwhinham/mt32-pi/blo ... kernel.cpp). It's very different than MUNT. It would need to be modified significantly.

[Neocaron]

MT32-Pi is a baremetal emulator running essentially at the kernel level (https://github.com/dwhinham/mt32-pi/blo ... kernel.cpp). It's very different than MUNT. It would need to be modified significantly.

Yeah I looked it up a bit, and they do differ quite a lot, that's why I changed my message.
But It can still get you somewhere nice compare to no midi at all. ^^

[FoxbatStargazer]

I mean, 1.2 is working pretty well for me. The De-10 nano was not designed around heatsink+active cooling yet here we are. Nor was it designed to go above 1080p on the scaler...

MT-32 pi is surely the better experience, but MUNT is at least passable at 1.2 and needs no extra hardware. Especially important right now when pis have shot through the roof in cost.

[Neocaron]

I've created a new sd card and did an update all, which is pretty intensive on the arm chip, but still no issue to report so far at 1.2ghz.
I thought it went significantly faster than usual though.

[FoxbatStargazer]

I should probably head over into a MUNT thread at this point but, on closer comparison with the MUNT built into SCUMMVM on PC, I can't really hear much difference in terms of timing between that and 1.2 Mister on the Space Quest III and Monkey Island II intros. I think these are just a tad sloppy whether that's MUNT's fault or the original programmers, it is not because the Mister ARM @ 1.2 is falling behind. It's just that one Lands of Lore forest track where I can hear a clear difference between PC MUNT and the Mister, where it's not quite keeping up. But that seems to be more of an edge case than the standard. There's good odds your average person would happy enough with MUNT here and only the purists need to go beyond for an mt-32 pi. (Then again, you're kind of already in the purist sphere picking FPGA over software emulation....)

[Neocaron]

I'd say the Mister project is about doing things differently. It's not just about the FPGA part of things, it's also about the community behind the box pushing the boundaries and exploring new avenues that wouldn't be possible on any other platform. With a Pi you pretty much know what you are getting out of the box, but with the DE-10 it feels like every year brings more unexpected discovery. Of course the accuracy part is important, but that's not the only reason I like my Mister. ^^