MiSTer FPGA Forum

It doesn't have anything to do with overclocking.

What I think the problem might be is that the kernel that has overclocking support has wifi and bluetooth statically compiled in. This is not the same as the Mister base Linux kernel.

The overclockable kernel done the same way, but with wifi and bluetooth as loadable modules instead, might well fix this commenter's problem. If they gave us dmesg output, that might make things clearer.

Sorry guys, been neglecting my duty here.

Released a new binary zImage_dtb with latest MiSTer kernel changes merged in:
https://github.com/coolbho3k/Linux-Kern ... tag/v1.0.1

Wifi and Bluetooth are working for me with no other changes.

My branch is also updated with these changes so folks can of course continue to build against it.

I made a PR on the main MiSTer kernel: https://github.com/MiSTer-devel/Linux-K ... er/pull/34

Not sure if it will be accepted though, no hard feelings either way, as I understand the pros/cons of having the feature in main. If Sorg doesn't love it, I'll try to keep things up to date here, the MiSTer kernel doesn't change that often and this patch is very very easy to merge into anything.

thisisamigaspeaking wrote: ↑Sun Jul 31, 2022 11:55 pm

ToothbrushThreepwood wrote: ↑Sun Jul 31, 2022 8:41 pm

FPGA64 wrote: ↑Sun Jul 31, 2022 12:18 pm Its still unproven. The arm cores have no thermal throttle. Its a very dangerous thing to put into main and should be left as a user replace option.

The de10 nano uses a particularly heat-tolerant SoC, specced to run safely at up to 125 degrees C, so any conceivable temperature increase is harmless to the hardware - the worst thing that could happen would be timing issues in the most complex cores (mainly ao486).

Bring this thing to main (IMO) - the improvement to onboard munt/fluidsynth alone outweighs the potential cons.

Looked for myself, checks out here.

"TJ Operating junction temperature –55 125 °C"

So there is no on die sensor on the Cyclone V series? I haven't been able to search up much information on this topic.

Isn't the rated speed of the ARM cores 925MHz rather than 800? And I assume they meant that to be without any additional cooling at all?

it's 925 MHz for the higher consumer -C6 bin of the chip, although that version actually has a lower temp range, so...

And, it's merged into main! Thanks everyone who tested and Sorg. There should be no need to install my built kernel once the kernel is next updated; in the meantime, the zImage_dtb link will be in the OP!

I think this is a mistake. If the DE10 Arm is damaged takes out a very expensive board.

FPGA64 wrote: ↑Mon Oct 24, 2022 9:34 am I think this is a mistake. If the DE10 Arm is damaged takes out a very expensive board.

We’ve gone over this already. You can damage you DE10 in a million different ways, but this is not one of them.

Coolbho3k wrote: ↑Mon Oct 24, 2022 3:23 am And, it's merged into main! Thanks everyone who tested and Sorg. There should be no need to install my built kernel once the kernel is next updated; in the meantime, the zImage_dtb link will be in the OP!

Congratulations! That must feel good after all you efforts. I'm looking forward to trying it.

Coolbho3k wrote: ↑Mon Oct 24, 2022 3:23 am And, it's merged into main! Thanks everyone who tested and Sorg. There should be no need to install my built kernel once the kernel is next updated; in the meantime, the zImage_dtb link will be in the OP!

OMG!
I never expected this! So happy to see! It's awesome.
This is going to be a game changer for many things in the future I'm sure!

Neocaron wrote: ↑Mon Oct 24, 2022 12:20 pm

Coolbho3k wrote: ↑Mon Oct 24, 2022 3:23 am And, it's merged into main! Thanks everyone who tested and Sorg. There should be no need to install my built kernel once the kernel is next updated; in the meantime, the zImage_dtb link will be in the OP!

OMG!
I never expected this! So happy to see! It's awesome.
This is going to be a game changer for many things in the future I'm sure!

Yes instability, damaged DE10's and all the fun that incurs

Tested for 6 months on a dedicated build with no problem at all. Some people did extensive testing which showed no temp change, barely any voltage changes. Your mindset is annoying and not substanciated by anything. I don't get it. Glad to see that most people don't think the way you do on the dev side. Otherwise the Mister platform would have never evolved as much as it did.

My mindset is not to introduce something that has very little benefit. The Mister is an FPGA platform. The ARM exists to serve it not to turn the device into a poor copy of a PI.

Until its proven to do harm, it should be a heavily restricted function.

I dont expect my views to be taken as god like pronouncements. Its how I feel. I wont risk a very expensive hard to obtain device to run some triviality on the arm side

@FPGA64 Then don't. It's off by default, you'll never notice it. The rest of us QUITE appreciate it. (And if you ever DO decide to try it, you'll find that it peps up the UI *quite* noticably, but if you don't, we get it...you don't need to continue to share the doom and gloom with the dozens that use it as a daily driver, thanks.)

rhester72 wrote: ↑Mon Oct 24, 2022 2:35 pm @FPGA64 Then don't. It's off by default, you'll never notice it. The rest of us QUITE appreciate it. (And if you ever DO decide to try it, you'll find that it peps up the UI *quite* noticably, but if you don't, we get it...you don't need to continue to share the doom and gloom with the dozens that use it as a daily driver, thanks.)

Pretty much that. It's a safe feature as it is. If you feel it's not because of some gut feeling, you don't have to use it. But the info gathered for the past 6 months shows that it's safe, and will dramatically increase performance in many many way and open more cool doors for the future of the Mister.
First one being a 99% fully fonctional mt32 on the arm. And when you see how much any piece of hardware cost right now, this is already awesome.

Neocaron wrote: ↑Mon Oct 24, 2022 3:08 pm ....
First one being a 99% fully fonctional mt32 on the arm. And when you see how much any piece of hardware cost right now, this is already awesome.

Could you elaborate on that point? Thanks.

jca wrote: ↑Mon Oct 24, 2022 3:14 pm

Neocaron wrote: ↑Mon Oct 24, 2022 3:08 pm ....
First one being a 99% fully fonctional mt32 on the arm. And when you see how much any piece of hardware cost right now, this is already awesome.

Could you elaborate on that point? Thanks.

Yes, Munt which is a software emulator of the mt32 works wonders with the OC.
1.2ghz overclock with munt on AO486 is working great.
NOT PERFECT, but great to be clear.

MT32pi is an a+
Munt at 1.2ghz is a A-
Munt at 800 is a D

And yet people will raise issues becasue its not perfect. Pretty much certain it will be reported as MT32 doesnt work and then subsequently will it be found to be on an overclocked arm and not a MT32Pi

It appears I'm alone in disliking this change but I see 0 compelling reasons for it to be present as anything but a user replaceable kernal image. Time will tell how it affects timing critical cores like the AO486 or for functionality that depends on the HPS such as CHD decompression.

FPGA64 wrote: ↑Mon Oct 24, 2022 3:50 pm And yet people will raise issues becasue its not perfect. Pretty much certain it will be reported as MT32 doesnt work and then subsequently will it be found to be on an overclocked arm and not a MT32Pi

It appears I'm alone in disliking this change but I see 0 compelling reasons for it to be present as anything but a user replaceable kernal image. Time will tell how it affects timing critical cores like the AO486 or for functionality that depends on the HPS such as CHD decompression.

The Ao486 is my "favorite" pc core, because of the game library, and I've been using it at 100mhz for 6 month with kernel oc without issues.
Could issues happen? Yes
Is the Ao486 a messy core in first place? Yes
But I'm so happy it exist even in its current state.
This will just make it better and easier to setup.

I know you don't agree, but here we are. If someone without the know about the Mister project goes to use munt and say it's the Mt32pi, he just needs to be informed. The same way people had to be inform for anything Mister related. Because you know what? Mister isn't so 'casual' in the first place.
Informing yourself about the project is a necessity, so that's not gonna change any of that.

@Neocaron, thanks for your answer. A long time ago I tried Munt on the Arm, before the overclocking, and it was disappointed. I also tried it via IP with Munt running on the PC, it was very good but not very convenient.
I will have to try it when the new kernel is released.

Not to go off topic, but if it's just close enough at 1.2 GHz, has anyone tried just running `renice` on the munt process to make it a higher priority when running it on-board? After the overclock the process priority might just make a difference.

Coolbho3k wrote: ↑Mon Oct 24, 2022 5:02 pm Not to go off topic, but if it's just close enough at 1.2 GHz, has anyone tried just running `renice` on the munt process to make it a higher priority when running it on-board? After the overclock the process priority might just make a difference.

I haven't tried no, how would that work?
Is the Kernel in main already updated btw?

Neocaron wrote: ↑Mon Oct 24, 2022 5:13 pm

Coolbho3k wrote: ↑Mon Oct 24, 2022 5:02 pm Not to go off topic, but if it's just close enough at 1.2 GHz, has anyone tried just running `renice` on the munt process to make it a higher priority when running it on-board? After the overclock the process priority might just make a difference.

I haven't tried no, how would that work?
Is the Kernel in main already updated btw?

Not yet, the kernel is rarely updated in main, but this zImage_dtb is up to date: https://github.com/coolbho3k/Linux-Kern ... tag/v1.0.1

To help people stay up to date, yesterday I made a PR on theypsilon's build automation repo to build kernel as an unstable nightly: https://github.com/MiSTer-unstable-nigh ... Ter/pull/1 If this gets merged and set up properly, the kernel will be built nightly whenever there are changes and posted to the relevant releases page/Discord channels

renice changes the process's priority which allows you to make the Linux scheduler prioritize it higher than other processes. I guess you can use chrt to really set the process to realtime to see if it makes any difference at all.

Find munt's PID with `top` and run: `chrt -f -p 99 $MUNT_PID`

Replacing $MUNT_PID with munt's PID

FPGA64 wrote: ↑Mon Oct 24, 2022 3:50 pm And yet people will raise issues becasue its not perfect. Pretty much certain it will be reported as MT32 doesnt work and then subsequently will it be found to be on an overclocked arm and not a MT32Pi

It appears I'm alone in disliking this change but I see 0 compelling reasons for it to be present as anything but a user replaceable kernal image. Time will tell how it affects timing critical cores like the AO486 or for functionality that depends on the HPS such as CHD decompression.

I'm missing something, isn't this an optional feature the user has to enable?

Coolbho3k wrote: ↑Mon Oct 24, 2022 5:40 pm

Neocaron wrote: ↑Mon Oct 24, 2022 5:13 pm

Coolbho3k wrote: ↑Mon Oct 24, 2022 5:02 pm Not to go off topic, but if it's just close enough at 1.2 GHz, has anyone tried just running `renice` on the munt process to make it a higher priority when running it on-board? After the overclock the process priority might just make a difference.

I haven't tried no, how would that work?
Is the Kernel in main already updated btw?

Not yet, the kernel is rarely updated in main, but this zImage_dtb is up to date: https://github.com/coolbho3k/Linux-Kern ... tag/v1.0.1

To help people stay up to date, yesterday I made a PR on theypsilon's build automation repo to build kernel as an unstable nightly: https://github.com/MiSTer-unstable-nigh ... Ter/pull/1 If this gets merged and set up properly, the kernel will be built nightly whenever there are changes and posted to the relevant releases page/Discord channels

renice changes the process's priority which allows you to make the Linux scheduler prioritize it higher than other processes. I guess you can use chrt to really set the process to realtime to see if it makes any difference at all.

Find munt's PID with `top` and run: `chrt -f -p 99 $MUNT_PID`

Replacing $MUNT_PID with munt's PID

Thanks! I'm gonna have fun with this

thisisamigaspeaking wrote: ↑Mon Oct 24, 2022 5:52 pm

FPGA64 wrote: ↑Mon Oct 24, 2022 3:50 pm And yet people will raise issues becasue its not perfect. Pretty much certain it will be reported as MT32 doesnt work and then subsequently will it be found to be on an overclocked arm and not a MT32Pi

It appears I'm alone in disliking this change but I see 0 compelling reasons for it to be present as anything but a user replaceable kernal image. Time will tell how it affects timing critical cores like the AO486 or for functionality that depends on the HPS such as CHD decompression.

I'm missing something, isn't this an optional feature the user has to enable?

I am fairly sure someone will write a script to enable max overclock. People will blindly run it and then be unaware or forget they are running it.

FPGA64 wrote: ↑Mon Oct 24, 2022 6:08 pm

thisisamigaspeaking wrote: ↑Mon Oct 24, 2022 5:52 pm

FPGA64 wrote: ↑Mon Oct 24, 2022 3:50 pm And yet people will raise issues becasue its not perfect. Pretty much certain it will be reported as MT32 doesnt work and then subsequently will it be found to be on an overclocked arm and not a MT32Pi

It appears I'm alone in disliking this change but I see 0 compelling reasons for it to be present as anything but a user replaceable kernal image. Time will tell how it affects timing critical cores like the AO486 or for functionality that depends on the HPS such as CHD decompression.

I'm missing something, isn't this an optional feature the user has to enable?

I am fairly sure someone will write a script to enable max overclock. People will blindly run it and then be unaware or forget they are running it.

Most PC BIOSes have options that would literally fry the CPU or RAM yet people don't seem to accidentally enable them very often.

Currently it gets unstable before it gets hot. So if you push to 1.4ghz you just get instability, but not in a way where you would TJ max the chip or burn it.
This will not happen in a official kernel anyway. Maybe someone will do what Coolbho3k while pushing voltage up and clocking it at 1.6 or even 2 ghz but this will never end up into main since you have to really increase voltage to make this possible. This is not what is happening here. This is just free performance without needing more power. If someone try to clock 2.ghz right now with this kernel, I'm pretty sure it will just crash and recover, because the voltage is the same and safe.

Neocaron wrote: ↑Mon Oct 24, 2022 6:20 pm Currently it gets unstable before it gets hot. So if you push to 1.4ghz you just get instability, but not in a way where you would TJ max the chip or burn it.
This will not happen in a official kernel anyway. Maybe someone will do what Coolbho3k while pushing voltage up and clocking it at 1.6 or even 2 ghz but this will never end up into main since you have to really increase voltage to make this possible. This is not what is happening here. This is just free performance without needing more power. If someone try to clock 2.ghz right now with this kernel, I'm pretty sure it will just crash and recover, because the voltage is the same and safe.

It's not easy to increase voltage as far as I can tell. It may be possible through a hardware mod. From what I remember in my explorations, it may be possible if you talk to the voltage regulator through SPI or something. I doubt that's even worth it.

This is awesome! I still can't believe it got in. Thank you Coolbho3k for working so hard on this.

It would be great to see a patch to the uartmode script which handles launching munt in the cores already. Then the overclock can be automatically enabled and disabled again as required. This may also be the right spot to experiment with nice if it ends up making a difference.

Coolbho3k wrote: ↑Mon Oct 24, 2022 10:27 pm

Neocaron wrote: ↑Mon Oct 24, 2022 6:20 pm Currently it gets unstable before it gets hot. So if you push to 1.4ghz you just get instability, but not in a way where you would TJ max the chip or burn it.
This will not happen in a official kernel anyway. Maybe someone will do what Coolbho3k while pushing voltage up and clocking it at 1.6 or even 2 ghz but this will never end up into main since you have to really increase voltage to make this possible. This is not what is happening here. This is just free performance without needing more power. If someone try to clock 2.ghz right now with this kernel, I'm pretty sure it will just crash and recover, because the voltage is the same and safe.

It's not easy to increase voltage as far as I can tell. It may be possible through a hardware mod. From what I remember in my explorations, it may be possible if you talk to the voltage regulator through SPI or something. I doubt that's even worth it.

Yeah and that's actually dangerous for REAL

FPGA64 wrote: ↑Mon Oct 24, 2022 1:56 pm My mindset is not to introduce something that has very little benefit. The Mister is an FPGA platform. The ARM exists to serve it not to turn the device into a poor copy of a PI.

Until its proven to do harm, it should be a heavily restricted function.

I dont expect my views to be taken as god like pronouncements. Its how I feel. I wont risk a very expensive hard to obtain device to run some triviality on the arm side

This doesn't apply as much to arcade cores, but computer cores are both Linux *and* the FPGA; they work in tandem. The FPGA usually implements the latency-sensitive circuitry, and then the Linux side handles most I/O. Speeding up the Linux side, as long as heat output isn't really changing, should be beneficial at least sometimes. For instance, it might make MUNT and Fluidsynth run fast enough that people could skip the MT32-Pi. Pis are really hard to find right now, and will be for a great long while yet, so that may let users get authentic MIDI music with minimal hassle and zero expense.

The Minimig forumgoers have also been dipping their toes into hybrid emulation, where the Linux side is the CPU, and the chipset is the FPGA. If they can get that working, it could really improve the quality of the emulation, because doing a cycle-exact 68030 or 68040 is a heck of a lot easier in software. And if the ARM is overclocked, it can run a faster CPU, which can be really nice for some Amiga titles. (Stunt Car Racer, for example, will burn a ton of CPU and increase its framerate dramatically.)

Overclocking might very well make the difference between a core working and not working; as the devs keep pushing up against the edge of what they can do with the FPGA, having a nice fast ARM available might just coax a not-quite-there core into workability.