Hacking Question Switch semi-bricked after NAND restore - crashes after sleep

jsherm101 · Sep 25, 2018

Hiya, not sure if this is technically a brick, but i am encountering a frustrating problem after restoring to my 5.1.0 NAND on my Switch.

RCM is working. Can load hekate and boot CFW (ReiNX) just fine. Games are loading, Switch seems fine... But every time it goes to sleep, it crashes. Screen turns off, have to turn back on and re-jig into RCM in order to reboot. Perhaps a corrupt partition somewhere? It could also be that autoRCM was enabl

I restored BOOT 0/1 and rawnand just to be sure.

I originally had a "sleep mode library missing" but then I just followed the instructions to unarchive my bit and that error went away, but the above issue persists.

Any suggestions on how to debug?

Flabou · Sep 25, 2018

I had the same problem. Thou my console is on 6.0.0. It turned out reinx was not compatible. So maybe try getting the latest reinx and latest hekate files. Or you can try using latest rajnx.

JJTapia19 · Sep 25, 2018

CTCaer said:
The zip you downloaded had a bootloader folder. Copy that into your sd.

jsherm101 · Sep 25, 2018

thanks both for the suggestions. Unfortunately, updating hekate + reinx including updates to sdfiles (or trying another CFW) had no effect. Also, on stock, the device goes to sleep and won't turn on afterwards as well.

would any other tools like gptrestore or briccmii help here?

JJTapia19 · Sep 25, 2018

jsherm101 said:
thanks both for the suggestions. Unfortunately, updating hekate + reinx including updates to sdfiles (or trying another CFW) had no effect. Also, on stock, the device goes to sleep and won't turn on afterwards as well.

would any other tools like gptrestore or briccmii help here?

Do you have the bootloader folder on the root of your sd card? It comes bundled with the hekate .zip
https://github.com/CTCaer/hekate/releases/tag/v4.2
This is really weird if you're still in 5.1.0. The problems with reinx sleepmode were with 6.0 and even then they were fixed in the latest nightly found here http://builds.reinx.guide/nightly/ReiNX-latest.zip

jsherm101 · Sep 25, 2018

JJTapia19 said:
Do you have the bootloader folder on the root of your sd card? It comes bundled with the hekate .zip
This is really weird if you're still in 5.1.0. The problems with reinx sleepmode were with 6.0 and even then they were fixed in the latest nightly found here

Spoke to someone on the sd files switcher discord -- turns out this is what a broken fuse count looks like when you downgrade, in case anyone else finds this thread in the future. Only solution is to upgrade back to 6.0.0 which i can confirm resolved the issue.

CTCaer · Sep 25, 2018

Ah, you have more fuses than your fw?
Then yeah, that's why.

Warmboot binary checks your fuses. If they are equal or less than needed, sleep mode works. Otherwise doesn't.
So if you updated to 5 or 6 and burnt fuses, and go back to 4 or 5, it will not work.

Unfortunately this can't be patched, because warmboot is signed with nintendo's private key. So any modification to that binary, also breaks sleep mode.

Cyan · Sep 25, 2018

is there a way to prevent warmboot from working at all? (patching it so it's unsigned)
forcing users to shutdown and coldboot then use autorcm to skip the warmboot efuse burning?

warmboot is only when selecting reboot from the power menu, or also when exiting sleepmode?

CTCaer · Sep 25, 2018

warmboot has nothing to do with efuse burning, reboots, etc..
The warmboot binary is only for one thing: waking from sleep.

Also only nxbootloader burns fuses. Autorcm is for avoiding running that.

jsherm101 · Sep 25, 2018

For me it was happening for reboots, sleeps, and power off. In order to jump back into RCM i'd have to hold power for something like 30 seconds, wait a little bit, and eventually RCM would kick in again. So it felt pretty unavoidable

bundat · Sep 26, 2018

CTCaer said:
Unfortunately this can't be patched, because warmboot is signed with nintendo's private key. So any modification to that binary, also breaks sleep mode.

I'm surprised there is actually code that can't be patched. I thought full control was available due to how early the RCM exploit is available. After all, fuse checking/burning was patched (which afaik lives in the read-only bootloader), and sig checks are patched (which afaik lives in HOS), so I thought everything was fair game.

Is it an option for the "wake from sleep" functionality of the warmboot, for too many burned fuses, be recreated from scratch instead in some CFW (like Atmosphere), using raw Tegra access? Although I'd assume that's at the same league of difficulty as writing sound drivers for Lakka

Myron49485 · Sep 26, 2018

Does this mean that it is impractical to use a firmware that requires less fuses to be burnt, even though it is possible to run it?
E.g. If I want to use 5.1.0 for theme support but have 7 fuses burnt.

Why can't we just patch away the need for warmboot to be properly signed, so that we can modify it?

Does "wake from sleep" functionality work if we use SX's emunand to run firmwares that require less fuses to be burnt?

CTCaer · Sep 26, 2018

bundat said:
I'm surprised there is actually code that can't be patched. I thought full control was available due to how early the RCM exploit is available. After all, fuse checking/burning was patched (which afaik lives in the read-only bootloader), and sig checks are patched (which afaik lives in HOS), so I thought everything was fair game.

Is it an option for the "wake from sleep" functionality of the warmboot, for too many burned fuses, be recreated from scratch instead in some CFW (like Atmosphere), using raw Tegra access? Although I'd assume that's at the same league of difficulty as writing sound drivers for Lakka

Even if you recreate it (which is very easy. It's the smallest binary 5KB.), it just wont work.

The warmboot binary is like the BCT. Bootrom checks its signature and sees if it matches the data. If not, halts.
The problem is that we can't create that signature.

I suppose that using a warmboot from another version may work. Never tried that though.
With hekate you can do this. Dump a warmboot that matches your fuses and use that on the downgraded one.
warmboot={SD path}
And then create a patch for secmon, so it will use the correct PA segment for warmboot (also checked together with efuses).

hippy dave · Nov 20, 2018

CTCaer said:
I suppose that using a warmboot from another version may work. Never tried that though.
With hekate you can do this. Dump a warmboot that matches your fuses and use that on the downgraded one.
warmboot={SD path}
And then create a patch for secmon, so it will use the correct PA segment for warmboot (also checked together with efuses).

Did anyone try this yet? Just curious, personally I'm still on 5.1 with the right number of fuses.

XaneTenshi · Nov 20, 2018

hippy dave said:
Did anyone try this yet? Just curious, personally I'm still on 5.1 with the right number of fuses.

I'm really interested in this aswell. Currently playing on my 6.1 clean nand, but my 5.1 hacked nand is semi-broken because trying to officially update without burning fuses, following this guide https://gbatemp.net/threads/an-easy...ch-firmware-without-burning-any-fuses.511847/, failed miserably and my fuses were burned anyway:/

Atleast for now, I cannot update my hacked nand with ChoiDujourNX, so another solution would be greatly appreciated.

bundat · Nov 21, 2018

hippy dave said:
Did anyone try this yet? Just curious, personally I'm still on 5.1 with the right number of fuses.

I'm interested as well, also just curious, I'm still on 5 burned fuses.
I have no idea what tools are needed to do this too.

i.e. dump warmboot (I'm looking at the partitions of my Hekate SYSTEM dump and I don't think this is what I need... or at least, I don't know how to extract it).

And I have no idea what/how to patch secmon... would this actually involve patching Atmosphere? I have no idea how they actually make those :/

Hacking Question Switch semi-bricked after NAND restore - crashes after sleep

Member

Member

I fight for my friends.

Member

I fight for my friends.

Member

Developer

GBATemp's lurking knight

Developer

Member

¿

Well-Known Member

Developer

BBMB

Well-Known Member

¿

Similar threads

Popular threads in this forum