Hacking Switch Fuse burning RCM

txeriff · Nov 21, 2018

Quick question:

-if you boot by RCM and then go to OFW, update, are fuses burnt?
-If negative answer, then if you go into OFW without RCM, will you get a kernel panic? Expected burnt fuses won´t be there.

thanks.

The Real Jdbye · Nov 21, 2018

txeriff said:
Quick question:

-if you boot by RCM and then go to OFW, update, are fuses burnt?
-If negative answer, then if you go into OFW without RCM, will you get a kernel panic? Expected burnt fuses won´t be there.

thanks.

Fuses are burnt any time you boot OFW or update in OFW.

txeriff · Nov 21, 2018

The Real Jdbye said:
Fuses are burnt any time you boot OFW or update in OFW.

Somebody is telling me that fuses are burnt when console boots, so like if you RCM to OFW, update then again RCM will be ok (no fuses burnt) but like if you then boot OFW with no RCM it will burn fuses.

So it´s like while you are in RCM it won´t never burn fuses until you OFW with no RCM (normal boot)

Am I right?

thanks

thmo_ · Nov 21, 2018

Update normally -> fuse burnt
Boot OFW normally -> fuse burnt
RCM and then boot OFW -> fuse burnt

RCM -> CFW -> fuses intact

Right?

Draxzelex · Nov 21, 2018

thmo_ said:
Update normally -> fuse burnt
Boot OFW normally -> fuse burnt
RCM and then boot OFW -> fuse burnt

RCM -> CFW -> fuses intact

Right?

Fuses aren't burn in RCM necessarily even if you boot into OFW as long as you're using a bootloader that doesn't burn fuses. Hekate and SX OS can boot OFW without burning fuses because they bypass the fuse check but the latter doesn't do that until Version 1.2; Version 1.0 burns fuses and Version 1.1 stops fuses from being burnt but doesn't bypass the fuse check

thmo_ · Nov 21, 2018

Draxzelex said:
Fuses aren't burn in RCM necessarily even if you boot into OFW as long as you're using a bootloader that doesn't burn fuses. Hekate and SX OS can boot OFW without burning fuses because they bypass the fuse check but the latter doesn't do that until Version 1.2; Version 1.0 burns fuses and Version 1.1 stops fuses from being burnt but doesn't bypass the fuse check

Haven‘t thought about bootloaders bypassing fuse check for OFW. *thumbs up*

8BitWonder · Nov 21, 2018

thmo_ said:
Update normally -> fuse burnt
Boot OFW normally -> fuse burnt
RCM and then boot OFW -> fuse burnt

RCM -> CFW -> fuses intact

Right?

All fuse burning happens in the bootloader, not in HOS.

Code:

Update normally -> fuse burnt

You can update normally, but only if you boot normally without a custom bootloader (ex: hekate) that disables fuse r/w will it burn fuses.

Code:

Boot OFW normally -> fuse burnt

This is correct, booting normally without a custom bootloader disabling fuse r/w will burn fuses.

Code:

RCM and then boot OFW -> fuse burnt

This does not burn fuses when using a custom bootloader disabling fuse r/w.

Code:

RCM -> CFW -> fuses intact

Correct, but not because of booting into CFW, only because the custom bootloader disabled fuse r/w. (Sorry I typed that so many times)

Edit: Ninja'd

thmo_ · Nov 21, 2018

Splendid. So to keep it short.
Boot normally without any bootloader bypassing fuse r/w -> fuse burnt
Boot using bootloader that bypasses fuse r/w -> fuse intact

Generally we can say hekate and sx bootloader (version 1.2+) bypass fuse stuff. I assume fusee does that too?

Draxzelex · Nov 21, 2018

thmo_ said:
Splendid. So to keep it short.
Boot normally without any bootloader bypassing fuse r/w -> fuse burnt
Boot using bootloader that bypasses fuse r/w -> fuse intact

Generally we can say hekate and sx bootloader (version 1.2+) bypass fuse stuff. I assume fusee does that too?

Fusee and ReiNX not only bypass the fuse check must like Hekate and SX OS V1.2+, but also prevent fuses from being burnt. I guess we can throw RajNX into the mix too if we're being all inclusive (even though its just a bastardization of Hekate).

Shift-X · Nov 21, 2018

I'm now confused. Isn't RCM the one that bypasses e-fuse check? Hekate is just the payload, just like ReiNX, RajNX, and Atmosphere. What I'm trying to say is that Hekate isn't needed to preserve e-fuse, it's just a utility. You should be able to into any CFW without first going through Hekate. I personally load ReiNX directly

Sent from my SM-G965U1 using Tapatalk

Draxzelex · Nov 21, 2018

Shift-X said:
I'm now confused. Isn't RCM the one that bypasses e-fuse check? Hekate is just the payload, just like ReiNX, RajNX, and Atmosphere. What I'm trying to say is that Hekate isn't needed to preserve e-fuse, it's just a utility. You should be able to into any CFW without first going through Hekate. I personally load ReiNX directly

Sent from my SM-G965U1 using Tapatalk

What burns fuses is the stock bootloader. RCM stops the console from using its stock bootloader but the console won't turn on without a bootloader. This is where we supplement one as a payload. These bootloaders perform most of the same functions as the stock bootloader with a few differences such as preventing fuses from being burnt, bypassing the fuse check, patching the firmware etc. However if the custom bootloader doesn't modify certain functions from the stock one, then it can do something like burn fuses. For example, SX OS V1.0 doesn't prevent fuses from being burnt. So if you updated without burning fuses but use SX OS V1.0 as your bootloader, the fuses will be burnt.

Hellboybeats · Nov 22, 2018

Could someOne please help me

I just restored my nand back up of 6.1.0 as I accidentally updated to 6.2.0 created an emunand of the 6.1.0 back up , but I haven’t updated for exfat in the 6.1 back up , and I don’t want to boot it usually ofw because of the fuses , if I add exfat support inside emunand will it allow me to use exfat for for the entire switch

thmo_ · Nov 22, 2018

Hellboybeats said:
Could someOne please help me I just restored my nand back up of 6.1.0 as I accidentally updated to 6.2.0 created an emunand of the 6.1.0 back up , but I haven’t updated for exfat in the 6.1 back up , and I don’t want to boot it usually ofw because of the fuses , if I add exfat support inside emunand will it allow me to use exfat for for the entire switch

You updated your OFW to 6.2 normally or through ChoiDujour? Or did you update the Emunand to 6.2?

Firexploit · Nov 22, 2018

Hellboybeats said:
_______________________________________________________
|"if I add exfat support inside emunand will it allow| |me to use exfat for for the entire switch |
_______________________________________________________

No. You will only have exfat support in emunand. Not for the entire switch.

just2mad · Jan 10, 2019

8BitWonder said:
Boot OFW normally -> fuse burnt
This is correct, booting normally without a custom bootloader disabling fuse r/w will burn fuses.

Why should a normal boot of the ofw burn a fuse?
If every little reboot/boot would burn a fuse, you could reboot the device limited times.
This makes no sense to me?!

8BitWonder · Jan 10, 2019

just2mad said:
Why should a normal boot of the ofw burn a fuse?
If every little reboot/boot would burn a fuse, you could reboot the device limited times.
This makes no sense to me?!

To clarify, here's an example:
Let's say you're on 6.0.0 with 7 burnt fuses (the expected total for this firmware).
When you boot normally on that firmware with Nintendo's bootloader it checks the number of fuses currently burned (7 fuses) vs the number expected for that firmware (also 7 fuses).
Since they match, it doesn't need to do anything more and boots you into Horizon OS.

Now let's say you update to 6.2.0 and then reboot.
Nintendo's bootloader will now once again check your currently burned fuses (still 7 fuses) vs the expected number of burned fuses for 6.2.0 (8 fuses).
It will notice that your total burned fuses is less than the expected, so it will burn fuses until it matches the expected number (8 fuses).

TL;DR
Nintendo's bootloader only burns additional fuses if it notices your total burned fuses is less than the amount specified by the current firmware.

There's a table on the bottom of this page with the expected burned fuses by firmware if interested:
https://switchbrew.org/wiki/Fuses

just2mad · Jan 10, 2019

8BitWonder said:
To clarify, here's an example:
Let's say you're on 6.0.0 with 7 burnt fuses (the expected total for this firmware).
When you boot normally on that firmware with Nintendo's bootloader it checks the number of fuses currently burned (7 fuses) vs the number expected for that firmware (also 7 fuses).
Since they match, it doesn't need to do anything more and boots you into Horizon OS.

Now let's say you update to 6.2.0 and then reboot.
Nintendo's bootloader will now once again check your currently burned fuses (still 7 fuses) vs the expected number of burned fuses for 6.2.0 (8 fuses).
It will notice that your total burned fuses is less than the expected, so it will burn fuses until it matches the expected number (8 fuses).

TL;DR
Nintendo's bootloader only burns additional fuses if it notices your total burned fuses is less than the amount specified by the current firmware.

There's a table on the bottom of this page with the expected burned fuses by firmware if interested:
switchbreworg/wiki/Fuses

Hi, thanks for the answer.

I thought you guys mean every reboot a fuse gets burned

I read that SX OS 1.0.0 burned fuses. Does this mean that every boot a fuse was burned by SX OS?

8BitWonder · Jan 10, 2019

just2mad said:
Hi, thanks for the answer.

I thought you guys mean every reboot a fuse gets burned

I read that SX OS 1.0.0 burned fuses. Does this mean that every boot a fuse was burned by SX OS?

Similar to Nintendo's bootloader, SX OS would only burn your fuses up to the amount specified by the current firmware.
It wouldn't burn an additional one on each reboot (Unless you updated your switch prior to each reboot).
Though I hear that issue was fixed quickly. (v1.2 I think?)

Hacking Switch Fuse burning RCM

Member

*is birb*

Member

Member

Well-Known Member

Member

Small Homebrew Dev

Member

Well-Known Member

Well-Known Member

Well-Known Member

Member

Member

Well-Known Member

New Member

Small Homebrew Dev

New Member

Small Homebrew Dev

Similar threads

Popular threads in this forum

is birb