Just so I understand this correctly, do I want to go into Nyx before putting any data on the SD card? Just injecting the payload without anything on the card at all?
Unfortunately yes but if you're worried, you can quickly make a backup of your sysMMC, run the homebrew app on CFW, than when you're done, restore the backup which will make it so it was as if you never ran CFW or homebrew on your sysMMC.
No, I did all of those steps in sysMMC meaning technically yes, I did boot CFW on sysMMC. I'm also very well aware of the risks but I do anything other than boot CFW. No .NSP, no homebrew, no nothing.
you need on your card minimum Hekate and Atmosphère files in order to boot on to NYX.
Don't fuses get burned for physical game copies? Would Animal Crossing or Pokemon Violet burn fuses if I own physical versions?
Anti-Downgrade fuses are burnt when you turn on the console while running a firmware higher than the fuse count. Meaning, fuses are typically burnt when you use the stock bootloader. The fuses you might be thinking about are the game cartridge fuses which are burnt at the same time as anti-downgrade fuses and under the same conditions. Meaning, even your game cartridge fuses would have been burnt long before you boot up a physical cartridge. But no, your anti-downgrade fuses won't be burnt by running a legitimate game.
What I am reading is that people use AutoRCM or just remember to always launch using the jig in order to preserve fuse count in case a coldboot solution comes to fruition. If I update my sysnand through Nintendo and then ALWAYS launch sysnand from hekate, will that prevent the fuse burn? Why wouldn't anti downgrade fuses be burned by running a physical cartridge that has a higher required fw than what the switch is currently on?
Yes, launching sysMMC through Hekate will preserve your anti-downgrade fuses. The magic is in the bootloader which is Hekate. As I explained earlier, the stock bootloader is what burns those fuses in the first place. If you boot normally, they will be burnt in an instant like by the time you see the Nintendo logo. But Hekate is a custom bootloader that is designed not to burn fuses even if you boot through Stock mode. The same can be applied to fusee as well but it cannot boot Stock so its not useful for this application.
It seems like a bit more trouble than it is worth, but I am still considering it. How likely is it that we will cold boot on a previous firmware? I am already sacrificing newshax. It just seems way too easy to forget RCM or having a softbrick for autorcm which I am a bit weary about. Might just go ahead and burn the fuses..... What do most people on temp do?
How likely is all to your perception. The truth is nobody knows so you're going to get a different answer based on who you ask. The fact is according to SciresM, there is a theoretical untethered coldboot exploit on 3.X that he nor anyone else has ever be able to trigger so he put up a bounty for it. Past that firmware is truly uncharted territory. The way I see it though is that since Nintendo doesn't ban people for mismatched fuse counts, there is literally no benefit to burning your fuses. Who knows, maybe someone else sees the value in a potential downgrade which can up the market cost of your Switch if you ever decide to sell. Also, you could just leave your console in sleep mode instead of turning it off. The Switch is a glorified phone; its designed to be in sleep mode for extended periods of time. Not to mention that AutoRCM saves unnecessary wear and tear on your right Joy-Con rail which can give out if abused given enough time.
I am always upgrade my OFW first, then upgrade other components. Honestly, I don't care about those minion fuses. As of now, there is no benefit of downgrading. So what? Just let it be. I am quite happy with RCM dongle for emuNAND and still buy legal copies of my favorite game from eshop with OFW. In next few month, I will try to do a mini fusee glee project and then, I can leave my dongle rest in piece.
What is fuse glee? Are the fuses on your switch burnt?
Your hekate_ipl.ini file only has 2 options: booting CFW on emuMMC and Stock on sysMMC. You don't have an option that allows you to boot CFW on sysMMC. For that, you will either need to create a boot entry in your hekate_ipl.ini file that allows this or you can download a pre-configured hekate_ipl.ini file that already contains that boot entry. You can find a pre-configured hekate_ipl.ini file in the first post of the patches thread.
So my hekate ini that points to emunand cfw looks like this:
Using SD formatter and redoing everything from scratch did not work, I'm gonna give it one more try by zeroing the SD with diskpart, but if that too fails I'll buy a new card and see if that's the issue.
Unknown pkg1 version.
HOS version not supported!
or emuMMC corrupt!I know it is emunand because my emunand has a black background and sysnand has a white background. My emunand also has 30 games compared to just 1 on my sysnand. If they serve the same purpose, why do they look so different?
SysNAND is the data and OS what is on the physical MMC chip on your console board.
Useless post. I know what an emunand and sysnand is. Question is what the user below you answered.
So fusee.bin knows that when it is ran it has to check for emunand? If so that is absolutely amazing and whoever developed that payload is an intelligent individual. So I assume emummc_force_disable is what tells hekate to use the sysnand instead?
@
BigOnYa:
@
BigOnYa:
