Review Sthetix fusecheck: how did this tool get released?

  • Thread starter Thread starter auggiethecat
  • Start date Start date
  • Views Views 5,965
  • Replies Replies 46
  • Likes Likes 3
I'm sorry but you don't have the slightest clue. When you update in that manner you get semi-bricked. The only way you're going to enter OFW again is if you initiate a system update from the official update menu.

sthetix is a good guy and I can attest to his efforts because he helped tens of thousands unlike you people who think it's cool to dunk on someone. You people are simply dicks.
I'm a dick because I'm right? You're the one blindly defending someone who clearly doesn't know how the fuses work out of some sort of parasocial attachment. And no that won't semi-brick you. Again, for the people in the back that can't read:

If you install a newer firmware and there aren't enough fuses it'll simply burn more fuses to the correct amount and then continue booting as normal. Nothing bad will happen. There are no negative effects. This is literally how stock updating works.

I've used that button combo to bypass the modchip's payload before and guess what? I'm not bricked. Not to mention you can easily test this on RCM exploitable Switches too. Update sysMMC after booting with Hekate. The fuse won't burn. Then boot normally. The fuse will burn.
 
Last edited by SuffahBish,
I'm a dick because I'm right? You're the one blindly defending someone who clearly doesn't know how the fuses work out of some sort of parasocial attachment. And no that won't semi-brick you. Again, for the people in the back that can't read:

If you install a newer firmware and there aren't enough fuses it'll simply burn more fuses to the correct amount and then continue booting as normal. Nothing bad will happen. There are no negative effects. This is literally how stock updating works.

I've used that button combo to bypass the modchip's payload before and guess what? I'm not bricked. Not to mention you can easily test this on RCM exploitable Switches too. Update sysMMC after booting with Hekate. The fuse won't burn. Then boot normally. The fuse will burn.
Honestly I think I'm just talking to a brick wall surely there's some intelligent people around here? I iterate if you update through daybreak and efuses aren't burned, your screen will lock on your OFW boot. Why do this happen? Simply the stock bootloader will verify the mismatched efuses with the installed firmware leading the system to halt.

The only way you're going to enter the OFW with modchip is if you update through the official menu or drop back to your earlier firmware to match the efuses.
 
  • Haha
Reactions: ChibiMofo
Honestly I think I'm just talking to a brick wall surely there's some intelligent people around here? I iterate if you update through daybreak and efuses aren't burned, your screen will lock on your OFW boot. Why do this happen? Simply the stock bootloader will verify the mismatched efuses with the installed firmware leading the system to halt.

The only way you're going to enter the OFW with modchip is if you update through the official menu or drop back to your earlier firmware to match the efuses.
No, that's only if the firmware is lower than the fuse count. Eg. You have the fuse count for FW 21 but you're trying to boot 18. That won't work. The other way around? No problem. It just burns the fuses. Are you under the impression that people using AutoRCM can't go back to stock without bricking? Because that would have to be the case for that to be true.
 
No, that's only if the firmware is lower than the fuse count. Eg. You have the fuse count for FW 21 but you're trying to boot 18. That won't work. The other way around? No problem. It just burns the fuses.
This is true, it's logical and it has been well known for years. IDK what to tell you guys please stop going around in circles.
 
This is true, it's logical and it has been well known for years. IDK what to tell you guys please stop going around in circles.
Keep echoing like mindless parrots. The difference between you and us, we actually have the disposable switches to do our test on.

I tried two different switches with two different chips RP2040 and INSTINCT-NX both behaved differently.

RP2040: Daybreak Update from 18.0.0 -> 20.5.0 -> no burned efuses -> OFW lock (Black Screen)
INSTINCT-NX: Daybreak Update from 20.5.0 -> 21.2.0 -> efues burned -> OFW functional

I can go over 20 switches but I'm not playing this stupid game to convince some random people.
My conclusion is that its not a definitive answer.
 
Keep echoing like mindless parrots. The difference between you and us, we actually have the disposable switches to do our test on.

I tried two different switches with two different chips RP2040 and INSTINCT-NX both behaved differently.

RP2040: Daybreak Update from 18.0.0 -> 20.5.0 -> no burned efuses -> OFW lock (Black Screen)
INSTINCT-NX: Daybreak Update from 20.5.0 -> 21.2.0 -> efues burned -> OFW functional

I can go over 20 switches but I'm not playing this stupid game to convince some random people.
My conclusion is that its not a definitive answer.
I mean if you want to continue to be confidently wrong for your e-daddy than by all means go ahead.
If too many fuses are burnt the bootloader will panic immediately.

If too few are burnt, the bootloader will enable fuse programming and write the expected value to fuses reserved_odm6 and reserved_odm7. Afterwards, fuse programming is disabled and the panic value 0x21 is written to PMC_SCRATCH200 register (0x7000EC40). Finally, the watchdog timer is initialized and programmed to force a reset.

On a subsequent boot, after the anti-downgrade fuses are checked again, the PMC_RST_STATUS register (0x7000E5B4) is checked and if set to 0x01 (watchdog reset) the PMC_SCRATCH200 register (0x7000EC40) will be checked for the panic value 0x21. PMC_RST_STATUS will only be set back to 0 (power on reset) if the fuse count matches the new expected value, otherwise the system will panic.
https://switchbrew.org/wiki/Fuses
 
I mean if you want to continue to be confidently wrong for your e-daddy than by all means go ahead.

https://switchbrew.org/wiki/Fuses
Oh really? I'm only agreeing with him because its in part with my own findings. I have zero connections with the guy and I don't even know him. There is only a single time that I emailed him but that's about it. Calling him my e-daddy because I agree with him just shows your arrogance. No wonder you have beef with him. He called you out and rightfully ignored your interaction because I would have done the same.

I will make a video soon to demonstrate this so please prepare to show yours.
 
Oh really? I'm only agreeing with him because its in part with my own findings. I have zero connections with the guy and I don't even know him. There is only a single time that I emailed him but that's about it. Calling him my e-daddy because I agree with him just shows your arrogance. No wonder you have beef with him. He called you out and rightfully ignored your interaction because I would have done the same.

I will make a video soon to demonstrate this so please prepare to show yours.
Who are you talking about? I've never interacted with him. I'm just pointing out he's wrong in this thread. As for your "findings"... Have you considered that you're wrong? But I'm sure you and Sthetix have some hidden arcane knowledge the rest of us are missing out on.
 
Who are you talking about? I've never interacted with him. I'm just pointing out he's wrong in this thread. As for your "findings"... Have you considered that you're wrong? But I'm sure you and Sthetix have some hidden arcane knowledge the rest of us are missing out on.
You and your OP friend who else.

You try to dunk on a person who has far more knowledge and experience. I would trust a person who dealt with hundreds of consoles than some chatter mouth that never touched or fixed a console in his life.

Look here, this console is sitting on firmware 20.5.0 with 18 efuse count (its already bypassed efuses). The moment you upgrade with an RP2040 you are met with a black screen, though I'm certain its bricked already from the first upgrade since I never bother checking.

 
Keep echoing like mindless parrots. The difference between you and us, we actually have the disposable switches to do our test on.

I tried two different switches with two different chips RP2040 and INSTINCT-NX both behaved differently.

RP2040: Daybreak Update from 18.0.0 -> 20.5.0 -> no burned efuses -> OFW lock (Black Screen)
INSTINCT-NX: Daybreak Update from 20.5.0 -> 21.2.0 -> efues burned -> OFW functional

I can go over 20 switches but I'm not playing this stupid game to convince some random people.
My conclusion is that its not a definitive answer.
I've looked at this again.

- The known and well documented (and never before questioned) facts from countless Switches before these glitch chips were even a thing: fuses get burned to match higher firmware version on boot.
- Your own result from an instinct glitch chip: fuses get burned to match higher firmware version on boot.
- Your own result from an RP2040 glitch chip: boot failure if fuses don't match.
- Claims from sthetix who is known to have been developing for the RP2040 glitch chips since they came about: boot failure if fuses don't match.

Can we see it yet?

The RP2040 introduces this boot problem that isn't a normal part of how the Switch boot process operates.

Question answered.

Now stop going in circles.
 
  • Like
Reactions: SuffahBish
You and your OP friend who else.

You try to dunk on a person who has far more knowledge and experience. I would trust a person who dealt with hundreds of consoles than some chatter mouth that never touched or fixed a console in his life.

Look here, this console is sitting on firmware 20.5.0 with 18 efuse count (its already bypassed efuses). The moment you upgrade with an RP2040 you are met with a black screen, though I'm certain its bricked already from the first upgrade since I never bother checking.


You post this like we know what happened with this Switch. The modchip could be bad. You could've installed something on the sysMMC that bricked OFW boot. I'm at work right now but when I get home I can record mine booting OFW perfectly fine after holding that button combo. The + & - combo skips loading payload.bin and loads the stock bootloader instead.
 
I've looked at this again.

- The known and well documented (and never before questioned) facts from countless Switches before these glitch chips were even a thing: fuses get burned to match higher firmware version on boot.
- Your own result from an instinct glitch chip: fuses get burned to match higher firmware version on boot.
- Your own result from an RP2040 glitch chip: boot failure if fuses don't match.
- Claims from sthetix who is known to have been developing for the RP2040 glitch chips since they came about: boot failure if fuses don't match.

Can we see it yet?

The RP2040 introduces this boot problem that isn't a normal part of how the Switch boot process operates.

Question answered.

Now stop going in circles.
I'm not even sure if that's the reason. This works fine on my picofly. I've got a Seeed Studio RP2040 in mine.
 
You post this like we know what happened with this Switch. The modchip could be bad. You could've installed something on the sysMMC that bricked OFW boot. I'm at work right now but when I get home I can record mine booting OFW perfectly fine after holding that button combo. The + & - combo skips loading payload.bin and loads the stock bootloader instead.
If it repeats it not a fluke buddy.
 
I'm not even sure if that's the reason. This works fine on my picofly. I've got a Seeed Studio RP2040 in mine.
So it CAN be an issue with RP2040 chips in certain circumstances/configurations.

Until someone provides evidence of boot failure caused by too few fuses burned on a Switch that has never had a modchip fitted, they need to stop claiming it's a problem in the actual Switch boot process, rather than a problem being introduced by modifications.
 
  • Like
Reactions: SuffahBish
So it CAN be an issue with RP2040 chips in certain circumstances/configurations.

Until someone provides evidence of boot failure caused by too few fuses burned on a Switch that has never had a modchip fitted, they need to stop claiming it's a problem in the actual Switch boot process, rather than a problem being introduced by modifications.
I never said its a problem with a console without a fitted modchip. It is fixable by lifting the modchip. I would still call it a semi-brick because it locks the system.
 
That is not true. The modchip is perfectly fine because the moment the efuses matches the firmware OFW works perfectly.
Im not saying the chip is faulty, I'm saying the chip is causing this issue. The fact is right there from your example. The nx-instinct doesn't have this issue, v1 unpatched and the v1 patched (the units that are able to achieve cfw with ofw 4.1) don't have this issue either. It seems more like an issue with the rp2040 chip itself or the firmware they use.
Also daybreak uses the same method to update as if you were to go settings and update that way.
 

Site & Scene News

Popular threads in this forum