will my fuse burn if i will update to 10.0.1 using ChoiDujourNX in emunand/emummc?

You need to install emunand. In emunand you can update without burning fuses.

Gesendet von meinem ELE-L29 mit Tapatalk

 

Would recommend to use it, but otherwise you can activate AutoRcm and update. In that you cannot boot without activated AutoRcm - othwise fuses will burnt.

Gesendet von meinem ELE-L29 mit Tapatalk

 

When you boot into CFW, since your booting into RCM first then into CFW, RCM prevents from any fuses from being burnt.

As soon as you boot into OFW, fuses will be burnt if you perform an system update, this can be prevented but enabling AutoRCM when booting into OFW.

 

Just so we are on the same page, when I say CFW, I am referring to EmuNAND, I assume this will be the same for EmuMMC, I'm an SX OS user so only used EmuNAND.
The answer will be NO, if you updated your EmuNAND firmware and you accidently boot into OFW, you will NOT burn a fuse since the OFW and EmuNAND does not talk to each other and don't know one or the other exists. Since you need to boot into RCM to get into EmuNAND, RCM will always prevent any fuses being burnt evertime you boot into EmuNAND.

As advised in my previous answer, to add, take CFW (EmuNAND/EmuMMC) out of the equation, updating the firmware on CFW (EmuNAND/EmuMMC) will not affect or burn a fuse if you boot into OFW.
Updating OFW and NOT using AutoRCM will burn a fuse.

 

Correct, from experience, whenever I update my EmuNAND firmware to the latest version using choidujournx, I never burnt any fuses when I boot into OFW. My OFW never touched any CFW or homebrew, so I use this purely for online, eshop, gaming, etc.. My EmuNAND is completely OFFLINE and this is where I play backups, emulators and homebrew.

Firmware v10.0.0+ will burn 13 fuses, if v10.0.2 comes out, going by past history, this will not burn a fuse, only when it jumps from 10.0.0 to 10.1.0 will burn a fuse, anything in 10.0.x will not burn a fuse.

 

Isn't this just wrong?

 

For some yes this seems wrong, however, OP original post says CFW and then later says he has EmuNAND/EmuMMC.
So my replies, I made it clear that I'm referring to EmuNAND/EmuMMC.

@vincekillua28 Just so you are on the same page, are you using EmuNAND/EmuMMC? or just flat out CFW?

 

fuses are not burned when updating but when booting the console.
the fuse burner happen in the "payload booter" :
when you update the firmware it also update the payload booter which contains fuse information.
then, on next reboot (usually right after update !) the fuses are checked and burned if needed.

The payload checks the requesting number of burned fuses against the actual physical burned fuse of the console.
If the payload requests less fuses than your console current burned fuses, it means you downgrading and refuse to boot.
If the payload requests more fuses than your console, it physically burn the needed fuses to match the current "payload number of fuses to be burnt"



If you boot CFW, or emuNAND, you are using RCM and a custom payload (hekate?)
Hekate doesn't check or burn fuses :

Hetate payload doesn't care how much fuse you have (more, exact or less), it always boot Horizon OS applying CFW patches or "stock" (OFW)

so, as long as you use a custom payload to boot the console, you will not burn fuses.

 

Thanks @Cyan for the technical information about fuse burning.

I don't have enough experience/knowledge in this area so I can't comment,

 

factory reset to get a "clean" NAND is not useful if you once used it with CFW.
you can't "factory reset" to go clean, as it doesn't delete everything.
you need to "write NAND backup" you did from a clean NAND before using homebrew or any hacks on that console.
if you never performed a clean NAND backup without any trace of hacks, you can't revert back to a clean state.

if you have a clean NAND backup :
create your emuNAND (using current firmware version?)
Restore (and downgrade?) your clean NAND backup on OFW
update OFW officially online to not use any CFW app (it will NOT burn fuse until you reboot, remember?)

you'll have :
(Auto)RCM to boot into custom payload
from payload choose to boot OFW (updated, clean NAND for online) and emuNAND (updated, NEVER online)


Not burning fuse is useful ONLY if you ever want to keep your OFW low (like 4.1) to run it without RCM and use one of the existing softmod hacks to boot into homebrew mode, instead of RCM.
For example if you have a patched switch and want to keep your OFW on low vulnerable firmware to boot into emuNAND.

if you use RCM, you don't care about number of burned fuses (OFW or CFW or emuNAND)
You can then boot OFW with correct burned fuses number !

keeping low burn fuses is only useful to boot low OFW without custom payload.
if you ever update OFW, what's the purpose of keeping low fuses?


Do not burn fuse if you EVER think you will ONE DAY want to downgrade your OFW and use it without hekate or RCM for whatever reason (lost your dongle? new kernel hacks?) but only if your "most possible lower firmware" has any vulnerability. or if you think your "current firmware" will one day have a possible soft hack without dongle or RCM.

 

downgrade is "restore NAND backup", you'll get your OFW "down" back to 7.0.1
if you didn't burn fuses since you did that backup, then you will be able to boot into 7.0.1 officially without RCM.

if you burned fuses between 7.0.1 and 9.x, then you'll need hekate to boot "stock" (ofw)
read the end of my previous message about the need of fuses. you might not care if they are burned or not.