Release DE10 Nano Overclock Kernel BETA

[Kamil]

It's pretty crazy not even 1000 MHz works stable for you. That's not really a bump over stock. Seems like there's a lot of variation.

If you have a multimeter handy I'd ask you to measure the 1.1 V rail on your board.

It will probably be necessary for Mister to break down. I wouldn't like that.

[KnightNZ]

I added the kernel and my MiSTer wouldn't even boot afterwards, that's before I've even had a chance to try and run the scripts, is there some other gotcha?

[Coolbho3k]

I added the kernel and my MiSTer wouldn't even boot afterwards, that's before I've even had a chance to try and run the scripts, is there some other gotcha?

Hmm... It really should not refuse to boot at all even if the higher frequencies are unstable. The kernel should boot at stock frequency and stay there.

If you have your mini USB cable I'd ask you to provide a log over UART.

[KnightNZ]

I added the kernel and my MiSTer wouldn't even boot afterwards, that's before I've even had a chance to try and run the scripts, is there some other gotcha?

Hmm... It really should not refuse to boot at all even if the higher frequencies are unstable. The kernel should boot at stock frequency and stay there.

If you have your mini USB cable I'd ask you to provide a log over UART.

Edit:
Looks like something got messed up somewhere, I redownloaded the kernel, re-copied it and now it's working. No idea why it would've made any difference but it's now running happily at 1Ghz. Sorry for the mistake.

[Coolbho3k]

I added the kernel and my MiSTer wouldn't even boot afterwards, that's before I've even had a chance to try and run the scripts, is there some other gotcha?

Hmm... It really should not refuse to boot at all even if the higher frequencies are unstable. The kernel should boot at stock frequency and stay there.

If you have your mini USB cable I'd ask you to provide a log over UART.

Edit:
Looks like something got messed up somewhere, I redownloaded the kernel, re-copied it and now it's working. No idea why it would've made any difference but it's now running happily at 1Ghz. Sorry for the mistake.

Yeah my theory is it just might not have copied over correctly the first time.

[Choquer0]

I need help, I misunderstood something or I'm not doing it right I have replaced the zImage_dtb in the linux folder. I run the 1200 Script and nothing changes, I test the ao486 core and it doesn't matter if I put 1200 or 400, everything runs the same. Is there anything I need to do apart from adding the scripts and the zImage_dtb file?

Thank you.

[Bas]

The core itself won't run any different. Overclock affects the ARM CPU running the housekeeping. You should be able to notice a difference when you're using the onboard MUNT emulator for the MT32 MIDI synth combined with AO486.

[jurkevicz]

I've been using it since day 1 and Loved it. Loads Games Much Faster.

[Neocaron]

I've been using it since day 1 and Loved it. Loads Games Much Faster.

Absolutely! I've been running at 1.2 for what now, 4 months 5? I don't even remember XD
Not a single hiccup to report!

You will get a speed boost if you try the hybrid minimig core I would imagine right? Dosbox will for sure give you a massive boost as well. Basically anything relying on the arm will get a massive performance boost at 1.2ghz for almost no change to temps.
This need to be included in the main as an option already, I feel it's stable enough to have its place there as an option with a nice little warning before changing the value.

[FoxbatStargazer]

I'd settle for just making the kernel part of main and it's up to you to source the scripts to change it. Gets annoying when every update overrides it.

[Coolbho3k]

I think there's been quite some testing already. I'll put up a PR and see if Sorg would take it.

[vanfanel]

I think there's been quite some testing already. I'll put up a PR and see if Sorg would take it.

I really hope so... overclocking and underclocking are great features, and I believe they are standard features in any ARM system, so it's only bringing good things!

[vanfanel]

Did something come out of this? With summer heat, it would be VERY good to have a way to underclock the ARM and keep the MiSTer cooler...

[Mills]

I tested the 400 MHz script because my board gets very hot, (and it's incredibly hot where I live). It looks like the script works, but I did not notice any change in temperature, still gets very hot. On the other hand, there were no issues using the cores.

[vanfanel]

I tested the 400 MHz script because my board gets very hot, (and it's incredibly hot where I live). It looks like the script works, but I did not notice any change in temperature, still gets very hot. On the other hand, there were no issues using the cores.

Supposedly some kernel changes need to be merged so this really work. I guess you are using the stock MiSTer kernel so it does not work as intended because of that.

So @coolbho3k, did you send a pull request for this to be merged?
MiSTer gets really hot here, too!

[Neocaron]

If you have a fan, you're good, I live in Malaga (Spain) and the 30°+ currently is not problem at all even at 1.2ghz. This need to be merge. It's an amazing addition that will be vey fruitful in the future for many thing including hybrid emulation. I hope we get the same thing for memory! We just need a message saying in caps when activating it " DO NOT USE IF YOUR MISTER DOESN'T HAVE ACTIVE COOLING "

[Mills]

If you have a fan, you're good, I live in Malaga (Spain) and the 30°+ currently is not problem at all even at 1.2ghz. This need to be merge. It's an amazing addition that will be vey fruitful in the future for many thing including hybrid emulation. I hope we get the same thing for memory! We just need a message saying in caps " DO NOT USE IF YOUR MISTER DOESN'T HAVE ACTIVE COOLING "

I live in Madrid, a lot of days we have 38 / 40 ºC. A little fan keeps the de10 board at a very comfortable temperature, but sometimes I'd like to use it with no fan, or maybe try a portable mister or something.

I'll wait till they merge this into the official linux.

[grizzly]

I hope we get the same thing for memory!

Do you mean the DDR3 memory on the ARM side or the SDRAM we have to add?
If you mean SDRAM then why?
Because each core sets its own SDRAM speed ,which is why some jotega core did (or are) mess up some SDRAM sticks.

[FPGA64]

I think this should never be put into the main Linux. It will lead to issues where people have overclocked their systems and then report issues on the main system.

[Neocaron]

I think this should never be put into the main Linux. It will lead to issues where people have overclocked their systems and then report issues on the main system.

It's part of the feature set of any arm processor, we do it to the limit with most Pi, hell the Pi 0 requires an OC to be used as a MT32. So I don't really agree with this statement, You won't kill the board by running an arm chip at 1.2ghz anyway. Heat concern are valid, but I wouldn't advise anyone to use his Mister with no fan anyway. I think we should just have a popup saying you need a fan to raise the frequency and it should be more than enough warning.

I hope we get the same thing for memory!

Do you mean the DDR3 memory on the ARM side or the SDRAM we have to add?
If you mean SDRAM then why?
Because each core sets its own SDRAM speed ,which is why some jotega core did (or are) mess up some SDRAM sticks.

And regarding the ram, I was talking about the DDR3 which could lead to interesting things as well.
Coolbho3k was looking into it a little while back

[FoxbatStargazer]

Again I wouldn't provide any official scripts to change the clock speed. Just put the ability to change in the kernel. Then it's up to users if they want to run the scripts or commands to actually change it.

[FPGA64]

I think this should never be put into the main Linux. It will lead to issues where people have overclocked their systems and then report issues on the main system.

It's part of the feature set of any arm processor, we do it to the limit with most Pi, hell the Pi 0 requires an OC to be used as a MT32. So I don't really agree with this statement, You won't kill the board by running an arm chip at 1.2ghz anyway. Heat concern are valid, but I wouldn't advise anyone to use his Mister with no fan anyway. I think we should just have a popup saying you need a fan to raise the frequency and it should be more than enough warning.

I hope we get the same thing for memory!

Do you mean the DDR3 memory on the ARM side or the SDRAM we have to add?
If you mean SDRAM then why?
Because each core sets its own SDRAM speed ,which is why some jotega core did (or are) mess up some SDRAM sticks.

And regarding the ram, I was talking about the DDR3 which could lead to interesting things as well.
Coolbho3k was looking into it a little while back

Most Pi's are cheap disposable items. A DE 10 is not. while I am happy to destroy a PI I would not want to risk a DE10.

Even if it does no damage to the ARM chip its altering a base parameter of the system and will alter timings. Since the Arm chip handles sending data to the FPGA cores any changes may have unexpected effects.

[vanfanel]

First, to my spanish comrades around here, I use my MiSTer without any kind of fan. It has been like this since 2018, and it didn't fry or anything, it works like the first day. I HATE fans, I can't stand the stupid noise that tells me: "this is a badly designed computer, like a PC, it's boring, noisy and prone to get full of dust and fail eventually because of that". No computers in my house (and there are quite a lot of them for different tasks) have a fan. MiSTer doesn't need a fan to work, and undercloking will keep it a bit cooler.
Best computers I had in my life (ZX Spectrum, Atari 800 and Commodore Amiga 500) didn't need a fan at all.

I totally agree with @FoxbatStargazer: No script should be provided at all. This could be done via kernel parameters or something like that so only experienced GNU/Linux users can do it. I can see the problem with the typical braindead user that overclocks something and comes here reporting non-existing issues, and that has to be avoided.

[thisisamigaspeaking]

Most Pi's are cheap disposable items. A DE 10 is not. while I am happy to destroy a PI I would not want to risk a DE10.

Even if it does no damage to the ARM chip its altering a base parameter of the system and will alter timings. Since the Arm chip handles sending data to the FPGA cores any changes may have unexpected effects.

Pis aren't that much less expensive than DE10s right now. Of course admittedly their intended MSRP is significantly lower.

The Raspberry Pi Foundation is a huge enterprise and works closely with Broadcom. I don't think they would include a feature that they feel would cause them support nightmares or a lot of bricked devices.

I can understand not wanting to deal with support issues related to this, but why not allow the user to make that choice? Right now the situation with every update clobbering the kernel is going to stifle experimentation with this. I don't have a strong view on it, just think it would be nice to have it available stock.

[FPGA64]

Most Pi's are cheap disposable items. A DE 10 is not. while I am happy to destroy a PI I would not want to risk a DE10.

Even if it does no damage to the ARM chip its altering a base parameter of the system and will alter timings. Since the Arm chip handles sending data to the FPGA cores any changes may have unexpected effects.

Pis aren't that much less expensive than DE10s right now. Of course admittedly their intended MSRP is significantly lower.

The Raspberry Pi Foundation is a huge enterprise and works closely with Broadcom. I don't think they would include a feature that they feel would cause them support nightmares or a lot of bricked devices.

I can understand not wanting to deal with support issues related to this, but why not allow the user to make that choice? Right now the situation with every update clobbering the kernel is going to stifle experimentation with this. I don't have a strong view on it, just think it would be nice to have it available stock.

But we arent talking about overclocking Pi's we are talking about the much much more expensive De10. Personally I wont risk overclocking a DE10 to make it perform slightly better at running arm based games. If I wanted to run an Arm based Game I would happily use a PI and overclock it.

[vanfanel]

@FPGA64: I am mainly interested on the underclocking part, so the SOC gets cooler, and this also allows underclocking.

[wizzo]

This has been working great for me at 1.2ghz after a recompile to fix the modprobe path being incorrect. Very happy with the result, munt is running at a totally acceptable quality now. I'm keen to try out ScummVM too (though probably not with munt). I can't see this ever being accepted into the official kernel but I'm happy to be proven wrong

[wizzo]

I ended up doing a little test measuring temperatures at different speeds. The reported temperatures are meaningless given all the variables, but I wanted to see the relative temperature difference. We all seem to agree 800mhz (stock) with a fan and heatsink is safe, right?

• I have an aluminium heatsink and a noctua fan. I ran the test without a case.

• I attached a temperature sensor to the base of the heatsink with a thermal pad, then the sensor connected back to the nano's i2c bus through the RTC board.

• I had an ambient temperature of around 21C.

• I ran through the following a couple times at each speed: menu idle, NES Gradius II, PSX Crash Warped, AO486 Monkey Island 2 with munt running, AO486 Ultima 7 with munt running (Kitrinx mentioned this game was particularly demanding and sensitive to timing issues)

• At each step I left it running long enough for the temperature to stabilise.

Unless someone really wants me to, I won't write out the whole table here. It turned out to be very predictable and linear. The summary is:

• The highest temperature I recorded was 31.4C which is AO486 and munt running at 1.2ghz. The game running didn't seem to matter.

• Lowest temperature was 28.8C for NES running at 400mhz.

• The difference between 800mhz and 1.2ghz across the board is around 0.5C.

• The difference between 400mhz and 800mhz was around 0.3C.

• munt started running well at 1ghz and I had trouble telling the difference between that and 1.2ghz (someone else probably can tell)

• The temperature difference is so small that I had trouble with ambient temperature affecting the result too much.

• I noticed 2 possible glitches in Ultima but they also occurred at 800mhz. Noticed no glitches otherwise, but this probably needs a lot more testing.

So that's that. Personally I'm satisfied that the overclock is safe. It's hard to say what the internal temperature of the chip is, or how it's affected by passive cooling and no heatsink... but it's like a 3% temperature difference with my setup. Putting my case back on was like 5x worse for temperature than overclocking to 1.2ghz

[thisisamigaspeaking]

• munt started running well at 1ghz and I had trouble telling the difference between that and 1.2ghz (someone else probably can tell)

How does munt at 1 GHz / 1.2 GHz compare to an MT32-Pi if you know? I already have one so it's moot for me, but it would be good to know.

[wizzo]

• munt started running well at 1ghz and I had trouble telling the difference between that and 1.2ghz (someone else probably can tell)

How does munt at 1 GHz / 1.2 GHz compare to an MT32-Pi if you know? I already have one so it's moot for me, but it would be good to know.

I can't do a direct comparison because I don't have my mt32-pi anymore but I can tell munt is not quite as smooth sometimes. Specifically on the MI2 theme there's a couple points where it seems to play a little slower than it should (when it gets very busy with instruments) but it picks up again pretty quickly. No skipping anymore though. Besides that I really can't tell the difference between them.