This is a sysmodule/service for Atmosphere and ReiNX that uses IPC's to communicate with its companion NRO, Freeset. This allows you to use any clock speed I've found on the Switch. The only restriction I have put in place is that you must be plugged into an official charger or docked if you are crazy enough to want to use the highest two GPU clock speeds. I am leaving it completely up to you to choose what clock speeds you want to use. Be careful.



Intructions:

• Atmosphere: Copy over the contents of the zip and reboot your system to load the module. Open Freeset and use that to send over the clock speeds you want.
• ReiNX: Create a folder in your ReiNX folder named titles if there isn't one. Copy the titles folder from the atmosphere folder to ReiNX/titles. Open "010000000000C235" and move the boot2.flag to the same directory as the exefs.nsp file. Reboot and freebird should now be working on ReiNX.

X turns freebird's clock setting feature on and off. Remember to turn this off before putting your system to sleep. I'm working on it™, but it will cause and require you to fully shutdown and restart your Switch if accidentally left on. When on, freebird will check and set the clocks if they don't match what you choose. When turned off, your clock speeds will be reset and no longer forced.

A sends over the clock speeds shown/chosen from the menu. Up and down change the currently selected option, left and right change speed.

If I missed anything, don't be afraid to ask. I'm open to suggestions too.

I'd like to thank @taggen86, @nabelo, @mathew77, @vanraz86, and @Kirby567fan for taking the chances and testing it. Thanks guys!

Download link: https://gbatemp.net/download/freebird.35566/

 

[AliciaBurrito]

Hey all to get this working on reinx is simple

Just move the boot2.flag out of the flags folder next to the exefs.nsp

Enjoy

Yep, this simple copy/paste seems to make it work in ReiNX no issues

 

[AliciaBurrito]

After some more testing of Switch overclocking in both Atmosphere and ReiNX, I have some very interesting findings to share.
First, let's get everyone up to speed on everything the current overclock implementation allows, and some of the basics.

Undocked Default Clock Speeds
CPU: 1020MHz
GPU: 307MHz
RAM: 1331MHz

Docked Default Clock Speeds
CPU: 1020MHz
GPU: 768MHz
RAM: 1600MHz

Max Clockspeeds Available
CPU: 1785MHz
GPU: 921MHz
RAM: 1600MHz

You are able to reach the maximum GPU clock speeds on both handheld and docked, however you must be plugged into the official Nintendo charger to enable GPU clock speeds of 844MHz and above. On both handheld and docked you are able to reach the maximum available overclock of the CPU of 1785MHz without needing the official Nintendo charger.
Now that we have the basics covered, onto the findings:

Test Environment
Firmware: 6.2.0
Atmosphere: 0.8.3
ReiNX: 2.0 and Latest Nightly 80095f252597d4006d15f09c6866fd9efe0ef893
Hekate: 4.6

On Atmosphere, myself and others that have tested alongside me have found that in general it is far more prone to instability and crashes than ReiNX when running an otherwise identical setup and overclock settings on the same system.

Testing Methodology
On both systems, I launched each game that I had in NSP format alongside RetroArch in NSP format (non-forwarded) and the regular RetroArch.nro.
In Atmosphere, if I had an overclock that was too high (what is determined as too high is variable, but usually above 1122MHz) a game launch (or RetroArch) would cause the Switch to immediately turn off.
Entering any game without an OC, and re-enabling it afterwards would usually allow the game to play fine. However very likely would the Switch would immediately power off (crash) soon afterwards at random, in particular during loading screens. This issue is exacerbated the higher the CPU OC. GPU and RAM clock speed changes did not seem to affect stability or the chance of system crashes.
I was unable to reproduce any of the system crashes while using ReiNX. My testing on ReiNX was playing every game on both docked and handheld at the maximum available clock speeds for CPU, GPU and RAM and I did not encounter a single system crash, or the Switch immediately turning off.

Conclusion
I am unsure what causes stability issues in Atmosphere when changing the CPU clock speed, as ReiNX seems to be perfectly stable even with everything cranked at all times. Myself and others have tested with and without Hekate as the bootloader for Atmosphere, and that does not seem to change anything. Whatever the difference is, it seems inherent to a difference in Atmosphere.
Perhaps it would be possible to achieve higher clock speeds on the Switch than what Freebird supplies in ReiNX given the lack of stability issues.

TL;DR
Atmosphere has stability issues with overclocking and will crash often causing the Switch to immediately shut off.
ReiNX does not suffer from the same issues and I haven't been able to invoke a single crash.

 

[Sayora]

Does this override the overclock setting set by other apps such as retroarch? Or can those apps override freebird?

 

[ZachyCatGames]

After some more testing of Switch overclocking in both Atmosphere and ReiNX, I have some very interesting findings to share.
First, let's get everyone up to speed on everything the current overclock implementation allows, and some of the basics.

Undocked Default Clock Speeds
CPU: 1020MHz
GPU: 307MHz
RAM: 1331MHz

Docked Default Clock Speeds
CPU: 1020MHz
GPU: 768MHz
RAM: 1600MHz

Max Clockspeeds Available
CPU: 1785MHz
GPU: 921MHz
RAM: 1600MHz

You are able to reach the maximum GPU clock speeds on both handheld and docked, however you must be plugged into the official Nintendo charger to enable GPU clock speeds of 844MHz and above. On both handheld and docked you are able to reach the maximum available overclock of the CPU of 1785MHz without needing the official Nintendo charger.
Now that we have the basics covered, onto the findings:

Test Environment
Firmware: 6.2.0
Atmosphere: 0.8.3
ReiNX: 2.0 and Latest Nightly 80095f252597d4006d15f09c6866fd9efe0ef893
Hekate: 4.6

On Atmosphere, myself and others that have tested alongside me have found that in general it is far more prone to instability and crashes than ReiNX when running an otherwise identical setup and overclock settings on the same system.

Testing Methodology
On both systems, I launched each game that I had in NSP format alongside RetroArch in NSP format (non-forwarded) and the regular RetroArch.nro.
In Atmosphere, if I had an overclock that was too high (what is determined as too high is variable, but usually above 1122MHz) a game launch (or RetroArch) would cause the Switch to immediately turn off.
Entering any game without an OC, and re-enabling it afterwards would usually allow the game to play fine. However very likely would the Switch would immediately power off (crash) soon afterwards at random, in particular during loading screens. This issue is exacerbated the higher the CPU OC. GPU and RAM clock speed changes did not seem to affect stability or the chance of system crashes.
I was unable to reproduce any of the system crashes while using ReiNX. My testing on ReiNX was playing every game on both docked and handheld at the maximum available clock speeds for CPU, GPU and RAM and I did not encounter a single system crash, or the Switch immediately turning off.

Conclusion
I am unsure what causes stability issues in Atmosphere when changing the CPU clock speed, as ReiNX seems to be perfectly stable even with everything cranked at all times. Myself and others have tested with and without Hekate as the bootloader for Atmosphere, and that does not seem to change anything. Whatever the difference is, it seems inherent to a difference in Atmosphere.
Perhaps it would be possible to achieve higher clock speeds on the Switch than what Freebird supplies in ReiNX given the lack of stability issues.

TL;DR
Atmosphere has stability issues with overclocking and will crash often causing the Switch to immediately shut off.
ReiNX does not suffer from the same issues and I haven't been able to invoke a single crash.

Maybe try an older version of atmos to see if it's because of a recent thing? Current versions of ReiNX (including nighlies) are pretty much equivalent Atmosphere 0.7.4/0.7.5, so try one of those versions maybe?

 

[AliciaBurrito]

Maybe try an older version of atmos to see if it's because of a recent thing? Current versions of ReiNX (including nighlies) are pretty much equivalent Atmosphere 0.7.4/0.7.5, so try one of those versions maybe?

The lowest version I am able to try on my Switch without dealing with NAND restore as I'm on 6.2.0 is Atmosphere 0.8.0. This version still exhibits the same behavior.

If someone is willing and on a lower firmware, would you be able to max out the CPU, GPU and RAM and try launching and playing a few games on the older versions?

 

[bytar]

The lowest version I am able to try on my Switch without dealing with NAND restore as I'm on 6.2.0 is Atmosphere 0.8.0. This version still exhibits the same behavior.

If someone is willing and on a lower firmware, would you be able to max out the CPU, GPU and RAM and try launching and playing a few games on the older versions?

how do you consider the optimum settings for each game?

 

[AliciaBurrito]

how do you consider the optimum settings for each game?

I just run the max overclock tbh lol
If I'm on handheld not connected to the charger, I'll likely only bump the GPU to 460MHz and RAM to 1600Mhz.

 

[Xebastron]

I have the same problem with atmosphere, the blocks are random, although I managed to stabilize 1.1Ghz CPU since the GPU and RAM were not affected by this problem. There may be a frequency block in CFW and that's why it does not work well.

 

[ZachyCatGames]

The lowest version I am able to try on my Switch without dealing with NAND restore as I'm on 6.2.0 is Atmosphere 0.8.0. This version still exhibits the same behavior.

If someone is willing and on a lower firmware, would you be able to max out the CPU, GPU and RAM and try launching and playing a few games on the older versions?

Oh :/. 0.8.0 was the one I thought may have broken it, because it was a HUGE update. I guess I could try downgrading my system to 6.1.0 and then try 0.7.5 myself

 

[crow132]

After some more testing of Switch overclocking in both Atmosphere and ReiNX, I have some very interesting findings to share.
First, let's get everyone up to speed on everything the current overclock implementation allows, and some of the basics.

Undocked Default Clock Speeds
CPU: 1020MHz
GPU: 307MHz
RAM: 1331MHz

Docked Default Clock Speeds
CPU: 1020MHz
GPU: 768MHz
RAM: 1600MHz

Max Clockspeeds Available
CPU: 1785MHz
GPU: 921MHz
RAM: 1600MHz

You are able to reach the maximum GPU clock speeds on both handheld and docked, however you must be plugged into the official Nintendo charger to enable GPU clock speeds of 844MHz and above. On both handheld and docked you are able to reach the maximum available overclock of the CPU of 1785MHz without needing the official Nintendo charger.
Now that we have the basics covered, onto the findings:

Test Environment
Firmware: 6.2.0
Atmosphere: 0.8.3
ReiNX: 2.0 and Latest Nightly 80095f252597d4006d15f09c6866fd9efe0ef893
Hekate: 4.6

On Atmosphere, myself and others that have tested alongside me have found that in general it is far more prone to instability and crashes than ReiNX when running an otherwise identical setup and overclock settings on the same system.

Testing Methodology
On both systems, I launched each game that I had in NSP format alongside RetroArch in NSP format (non-forwarded) and the regular RetroArch.nro.
In Atmosphere, if I had an overclock that was too high (what is determined as too high is variable, but usually above 1122MHz) a game launch (or RetroArch) would cause the Switch to immediately turn off.
Entering any game without an OC, and re-enabling it afterwards would usually allow the game to play fine. However very likely would the Switch would immediately power off (crash) soon afterwards at random, in particular during loading screens. This issue is exacerbated the higher the CPU OC. GPU and RAM clock speed changes did not seem to affect stability or the chance of system crashes.
I was unable to reproduce any of the system crashes while using ReiNX. My testing on ReiNX was playing every game on both docked and handheld at the maximum available clock speeds for CPU, GPU and RAM and I did not encounter a single system crash, or the Switch immediately turning off.

Conclusion
I am unsure what causes stability issues in Atmosphere when changing the CPU clock speed, as ReiNX seems to be perfectly stable even with everything cranked at all times. Myself and others have tested with and without Hekate as the bootloader for Atmosphere, and that does not seem to change anything. Whatever the difference is, it seems inherent to a difference in Atmosphere.
Perhaps it would be possible to achieve higher clock speeds on the Switch than what Freebird supplies in ReiNX given the lack of stability issues.

TL;DR
Atmosphere has stability issues with overclocking and will crash often causing the Switch to immediately shut off.
ReiNX does not suffer from the same issues and I haven't been able to invoke a single crash.

could the reason be that your CPU oc aint taking place on Reinx? how do you make sure its applied?

 

[AliciaBurrito]

could the reason be that your CPU oc aint taking place on Reinx? how do you make sure its applied?

That's not the issue, it is being applied correctly. An easy way to test would be to turn the CPU to 1.7GHz and scroll around in hbmenu. It will perform at 2x of its usual speed.

Also I can measure the additional power draw when overclocking, and see the performance differences between games. Eg. Skyrim as an example on handheld, I have disabled the framecap of 30FPS and on handheld it cannot hit 60 at all, but when overclocked it easily hits 60FPS.

These are just a few examples, but the overclock is certainly taking place. Keep in mind though, that the Tegra X1 in the Switch comes factory underclocked, so stability shouldn't be a huge concern. Even when overclocking to the limits of Freebird, it is still considered underclocked compared to a stock Tegra X1 in eg. the Nvidia Shield.

This is perhaps a bug that only appears in Atmosphere that only presents itself when the system runs outside of spec. Or maybe a bug in Freebird that only happens in Atmosphere? Outside of that I am unsure why ReiNX is unaffected. Curious if SX OS could load Freebird if it would exhibit the bug or not.

 

[mrcroket]

I can confirm that cpu oc even at 1,75ghz its stable on reinx in any game. I tried wolfenstein and the switch sounds like a hair dryer but stable.

 

[ZeroFX]

Yeah hahaha just like an hair dryer. i could really see the difference in games like dark souls, skyrim, naruto etc.

 

[m4xw]

TL;DR
Atmosphere has stability issues with overclocking and will crash often causing the Switch to immediately shut off.
ReiNX does not suffer from the same issues and I haven't been able to invoke a single crash.

This doesn't make sense. Stock system using a patched PPC service exhibits the same behaviour.
The system simply uses a lot of timings based to ticks that then get converted into nanoseconds, changing the clocks will skew all of ninties internal calculations in nearly all sysmodules, especially nvservices.
The issue is inherently a race condition.

 

[JK_]

Update: The simple menu is done, but the advanced menu is taking longer than expected. It works, but I don't like the current layout I slapped together. I want it to be easier to read. It has also shown a few new bugs in the module itself I need to get straightened out.

Does this override the overclock setting set by other apps such as retroarch? Or can those apps override freebird?

It will override them.

 

[m4xw]

It will override them.

Yea you should absolutely not touch CPU if it is running != 1020MHz.
You kill all our workarounds for using the high clocks, for example the system will get a nice cyan panic screen if u override it to max clocks and open swkbd (we handle it properly)

 

[AliciaBurrito]

This doesn't make sense. Stock system using a patched PPC service exhibits the same behaviour.
The system simply uses a lot of timings based to ticks that then get converted into nanoseconds, changing the clocks will skew all of ninties internal calculations in nearly all sysmodules, especially nvservices.
The issue is inherently a race condition.

What part of it does not make sense? I gave results based on an observation that others have corroborated.

Perhaps I'm misunderstanding something, but Nintendo's services and kernel need to support changing clocks if it wants to function at all. I don't see how this would be any different. And I don't see how anything would be a race condition when the system is just running faster than normal. It doesn't introduce any other variables into the mix that could cause that.

Also doesn't explain why it happens in Atmosphere but not ReiNX.

 

[m4xw]

What part of it does not make sense? I gave results based on an observation that others have corroborated.

Perhaps I'm misunderstanding something, but Nintendo's services and kernel need to support changing clocks if it wants to function at all. I don't see how this would be any different. And I don't see how anything would be a race condition when the system is just running faster than normal. It doesn't introduce any other variables into the mix that could cause that.

Also doesn't explain why it happens in Atmosphere but not ReiNX.

[... cut ...]
Some hw parts expect you to wait at least a certain amount of time when sending commands, some get potentially broken.
It would indicate either a broken hw init if it would actually work on reinx, or given it's a race, it's random by nature. I could often start games with atmo, other loads it would fail at max clocks and so on.

Clarified in https://gbatemp.net/threads/freebird-switch-clock-speed-control-sysmodule.530641/page-8#post-8511733
https://gbatemp.net/threads/freebird-switch-clock-speed-control-sysmodule.530641/page-8#post-8511899

 

[AliciaBurrito]

Its a race because the fixed amount of cycles the system does calculation with are all invalidated.
If you clock to double the speed, it will handle double the cycles and all sync/sleep operations will be too short.
Some hw parts expect you to wait at least a certain amount of nanoseconds when sending commands, all these get broken.
It would indicate either a broken hw init if it would actually work on reinx, or given it's a race, it's random by nature. I could often start games with atmo, other loads it would fail at max clocks and so on.

Power management is not hard coded, the Switch is used to changing frequencies within a predefined limit based on load similar to a full computer and the X1 is made within the specs that Freebird allows you to "overclock" to. I also very highly doubt that there is a switch statement in every sysmodule that handles sync / sleep operations for every single clock. The only failure points would be touch, SD, internal NAND, and UART for the Joycons - but those all work. Can you give any examples of where this is the case?

Also hwinit is mostly Hekate code as a base, with some minor tweaks and changes. It's very much possible that one of the developers might have fixed an edge-case in the existing code that happened to cause this issue. Calling it a bug in ReiNX because it functions correctly seems a bit disingenuous.

 

[YlwHrt]

Its a race because the fixed amount of cycles the system does calculation with are all invalidated.
If you clock to double the speed, it will handle double the cycles and all sync/sleep operations will be too short.
Some hw parts expect you to wait at least a certain amount of nanoseconds when sending commands, all these get broken.
It would indicate either a broken hw init if it would actually work on reinx, or given it's a race, it's random by nature. I could often start games with atmo, other loads it would fail at max clocks and so on.

Everything you just said is a bold face lie, i replaced my thermal paste this morning with mx4 and have been running my switch undocked but on charger for 10 hours at 1785mhz cpu, 921 mhz gpu, and 1600mhz ram, and not only did the thermal paste make it run at the same temp as normal undocked (the paste nintendo uses is awful) but its been stable the whole time, no game crashes, no homebrew crashes, no errors in the error history, no artifacts in game, why are you lying, everyone who knows how the switches internals work KNOWS youre lying, youre only impressing the average gbatemp user who can barely into homebrew.