So I know there is already a very detailed tutorial out there that is quite good and safer than what I am writing, but a number of people seem to be interested in the method I discovered and have tested.
If you are interested in the safer(perhaps) way please look at this thread:
https://gbatemp.net/threads/how-to-...nofficially-without-burning-any-fuses.507461/

So the way I figured out basically sets up autoRCM or Brickmii right after the update, before any fuses can be burned. This is why this is potentially risky, if you do not boot into rcm after the update restart before the regular switch os boots the fuses will be burned and you will not be able to downgrade (at least without some other caveats)

DISCLAIMER: I believe this procedure is safe, but I take no responsibility if you somehow do burn fuses, get banned online, or other wise damage or break(brick) your switch console or connected hardware.3

NOTE: AutoRCM and Brickmii have a good chance of causing a small bug that prevents the system from staying powered completely off for more than 30 seconds, there may be a fix for this in the future. Also note that if your console boots to RCM without a payload device or computer sending it, it will appear to be off and can not charge, but will drain battery. I personal find this mildly annoying but most of the time I can keep it asleep in dock or powered on.

Also NOTE: this manner of updates may affect your cart slot firmware and may make the slot not read carts when loading an old fw version.

Things you will need:

• a rcm jig, or other reliable way to enter rcm (not autorcm or brickmii as they get removed during updates)
• A SX pro widget or similar product, or a realiable way to load a payload like sx os or hekate

Steps:

1. Back up everything (boot, raw nand, sd card, you can't be too safe) and keep it someplace safe and labeled
2. Check the fuse info using hekate, note how many are burned, so you know what you expect to see after the update
3. Boot up switch in OFW or CFW or even just plain with no mods or loaders
4. Once booted have your RCM jig inserted and ready to go ( be sure you have confirmed that this actually works)
5. using either a cartridge or updating via system settings (assuming you are comfortable going online, but I think this is safe) begin updating your system
6. *MOST IMPORTANT* When the update is almost done or the second you see the complete notification hold the [VOL +] button. And continue holding it till you get to hekate or sx os menu.
7. When the system reboots it should be in RCM mode, if you have a widget plugged in it should boot to SX OS or Hekate
   IF ON SX OS: navigate to tools and enable auto RCM.
   IF ON HEKATE: navigate to tools and enable brickmii.
8. Boot into CFW and you will be on the updated fw without having burned fuses
9. Feel free to use hekate menu to view the fuse info to confirm the fuses are in the same state.

Hope you find this useful.
P.s. I may post a guide on how to downgrade using backup, and a way to protect your cart slot fw as well in the future.

 

[Lacius]

Could you elaborate, high level, what briccmii does?

AutoRCM and briccmii are functionally the same thing. They subtly corrupt your boot partitions on purpose in a way that makes the Switch boot into RCM on each coldboot or reboot. This makes entering RCM super easy, since you won't need to use a jig anymore.

However, it also means you can't reboot or coldboot your system without having something like a computer nearby that can send RCM payloads. This problem is solved by just keeping your system in sleep mode when you're not using it and not letting it die.

If you're upgrading a system without burning your efuses by following this or another guide, you must install some form of AutoRCM so that you don't accidentally burn efuses. If you follow one of these guides but then boot your system normally without an RCM payload like Hekate, then the efuses will be burned anyway, and you won't be able to downgrade.

 

[medi01]

AutoRCM and briccmii are functionally the same thing. They subtly corrupt your boot partitions on purpose in a way that makes the Switch boot into RCM on each coldboot or reboot. This makes entering RCM super easy, since you won't need to use a jig anymore.

However, it also means you can't reboot or coldboot your system without having something like a computer nearby that can send RCM payloads. This problem is solved by just keeping your system in sleep mode when you're not using it and not letting it die.

If you're upgrading a system without burning your efuses by following this or another guide, you must install some form of AutoRCM so that you don't accidentally burn efuses. If you follow one of these guides but then boot your system normally without an RCM payload like Hekate, then the efuses will be burned anyway, and you won't be able to downgrade.

Thanks.

Any idea on why installing AutoRCM using SX on 4.1.0 (long "no fuse" method) would remove exfat support?

 

[denyfate]

Hi, I just got a new switch and want to do a nand backup first, my sx pro and jig is coming in a week

so when i put in my sdxc, i will be prompted to update exfat without updating the fw?

i assume hekate can read the sdxc without updating the ofw right? so i can do the nand backup before i do any updating?

after updating exfat, how do i get back into ofw to update the fw without burning fuses? i have to get to ofw through sx os bootscreen?

thanks!

 

[annson24]

Wouldn't it be easier to just enable briccmii first before doing a system update as briccmii persists even when a system update is performed. That way you just wait for the system update to finish and it will reboot directly to RCM without needing to hold the vol.up button. And SX OS users can also use briccmii.

 

[olku]

@annson24 No, system update writes over corrupted boot partition, you won't have AutoRCM after system update.

 

[annson24]

@annson24 No, system update writes over corrupted boot partition, you won't have AutoRCM after system update.

I've read that briccmii is not like the typical (hekate or sxos) autorcm, briccmii re-bricks the boot partition after a system update. Or that's what I thought? Hmm..Let me find the thread. I'll report back.

Edit: So I might actually be wrong. Thanks for the clarification.

 

[medi01]

Updated to 5.1.0 online... oh well.
Seemed to work smoothly (and surprisingly fast)
Hekate reports 5 burnt fuses, as when I was "no fuse" on 4.1.0 (hopefully 5 burnt fuses correspond to 3.0.2).

Thank you so much, OP!

 

[shchmue]

5 fuses is the level for 4.x

 

[medi01]

5 fuses is the level for 4.x

Oh, fck.
At least it's not 5.1.0 though.

 

[puppydg68]

S
Hope you find this useful.
P.s. I may post a guide on how to downgrade using backup, and a way to protect your cart slot fw as well in the future.

Thanks, I am very interested in the downgrade tutorial using nand backup.

Also, is it possible to update via an installed NSP that is asking for an update upon launch? don't want to go online to get the update, and no access to the right cartridge at the moment.

 

[Sephirosu]

Also, is it possible to update via an installed NSP that is asking for an update upon launch? don't want to go online to get the update, and no access to the right cartridge at the moment.

Hmm that's more of a question for whichever CFW you use. This is mostly for using OFW to update via online. If ReiNX allows you to update via NSP then yeah. I know you could using XCI (in SX CFW).

 

[Mr. Wizard]

Hmm that's more of a question for whichever CFW you use. This is mostly for using OFW to update via online. If ReiNX allows you to update via NSP then yeah. I know you could using XCI (in SX CFW).

Really? I couldn't mount an xci in SXOS that needed a higher FW version therefore you cannot update from an xci unless you unpack it and use other tools.

Please explain to me how you did it.

Thanks, I am very interested in the downgrade tutorial using nand backup.

Also, is it possible to update via an installed NSP that is asking for an update upon launch? don't want to go online to get the update, and no access to the right cartridge at the moment.

You will burn your fuses if you don't reboot into RCM or use the no fuse burning guide.

 

[Sephirosu]

Really? I couldn't mount an xci in SXOS that needed a higher FW version therefore you cannot update from an xci unless you unpack it and use other tools.

Please explain to me how you did it.

Maybe I read wrong. I could have sworn I read somewhere that it would ask you to update and even allow you to. My bad.

 

[puppydg68]

Hmm that's more of a question for whichever CFW you use. This is mostly for using OFW to update via online. If ReiNX allows you to update via NSP then yeah. I know you could using XCI (in SX CFW).

i was asking here because the OP mentions booting with cfw with no memory hacks etc. (ie layeredfs) and only discussed online or cartridge, I was hoping to use the tutorial with another method to get the desired firmware.

 

[Deleted User]

Might try this.... should easily be able to recover if you have a nand backup.

--------------------- MERGED ---------------------------

though I don't have SXOS, using ReiNX

 

[alucard_xs]

Don't you think it could be hazardous to have a console on 5.1.0 and a number of efuses for 4.1.0 for exemple ? As it won't match.
What will happen in the next system update ?

 

[Draxzelex]

Don't you think it could be hazardous to have a console on 5.1.0 and a number of efuses for 4.1.0 for exemple ? As it won't match.
What will happen in the next system update ?

No one has been banned yet because of this and it doesn't appear that Horizon cares too much about fuses since that's the bootloader's job primarily. Its possible Nintendo may introduce a new system update that actively checks the number of fuses burnt.

 

[alucard_xs]

No one has been banned yet because of this and it doesn't appear that Horizon cares too much about fuses since that's the bootloader's job primarily. Its possible Nintendo may introduce a new system update that actively checks the number of fuses burnt.

If Nintendo introduces the new system update you're talking, the method described here to update without burning efuses could mean our switch as paperweight … I mean incapacity to update from now on (and staying at 5.1.0 forever) … so this method is not the best choose to make I guess.

 

[Draxzelex]

If Nintendo introduces the new system update you're talking, the method described here to update without burning efuses could mean our switch as paperweight … I mean incapacity to update from now on (and staying at 5.1.0 forever) … so this method is not the best choose to make I guess.

Both methods of updating without burning fuses introduce about the same risk since the whole point is to be on 5.1 anyways. This one is just less complicated. I get what you're saying because this one involves connecting online to grab the update, but I would imagine it would be safer to update officially rather than offline because the offline method involves a lot more hacking than this one. If your goal is to ultimately stay online until its safe, we're not sure if we can ever reach that point. Plus, online is going to become paid soon so a lot of people will stop going online once that happens.

 

[alucard_xs]

Both methods of updating without burning fuses introduce about the same risk since the whole point is to be on 5.1 anyways. This one is just less complicated. I get what you're saying because this one involves connecting online to grab the update, but I would imagine it would be safer to update officially rather than offline because the offline method involves a lot more hacking than this one. If your goal is to ultimately stay online until its safe, we're not sure if we can ever reach that point. Plus, online is going to become paid soon so a lot of people will stop going online once that happens.

Well, in fact, on my second switch, I do not want to go online (I've got another switch with retail games). I just want to update my second switch but keeping a possibility to go back to 3.1.0 (in case of a coldboot release) and keeping my card slot working at such lower downgrade firmware.