Homebrew Question Idea for a semi-permanent hack, is it doable?

[smf]

If for every reason a patched Switch should find itself with a corrupted BOOT0 (in the same way as AutoRCM corrupts it), it can't be fixable and this can be considered a "full brick" (probably fixable only by Nintendo).

1. I don't have a patched unit.

2. There are many hacks that work on one model or software revision which will brick later hardware or software revisions.

3. If you can enable autorcm on a patched switch then you have a way to disable it.

There is nothing to say that patched units won't be exploitable in the future, fusee gelee exploit has been patched but there could easily be others.

 

[Diablos90]

If you think its not a brick, then it would be fine to use it on a patched systems? Right?

It is fine on a patched system to get you into RCM on every boot. RCM will just reject fusee gelee, but if you have another exploit or signed files then that isn't a problem.

If you don't then you can say that autorcm bricks a patched system.

3. If you can enable autorcm on a patched switch then you have a way to disable it..

I never said that, I suggest you to read with more attention:

If for every reason a patched Switch should find itself with a corrupted BOOT0 (in the same way as AutoRCM corrupts it), it can't be fixable and this can be considered a "full brick" (probably fixable only by Nintendo).

That suggested by me and ZachyCatGames was clearly an hypotetical (and paradoxical) situation to let you understand that AutoRCM can be considered a brick, since if a patched Switch haves a corrupted BOOT0 (again, very unlikely and hypothetical situation, and not enabled by AutoRCM) it can't be restored.

I hope I was clear.

 

[smf]

That suggested by me and ZachyCatGames was clearly an hypotetical (and paradoxical) situation to let you understand that AutoRCM can be considered a brick, since if a patched Switch haves a corrupted BOOT0 (again, very unlikely and hypothetical situation, and not enabled by AutoRCM) it can't be restored.

I hope I was clear.

By your argument PS3 CFW can be considered a brick, because it bricks super slims if you manage to install it.

Even every file ever created can be considered a brick, because if you flash it to something you shouldn't then it will brick it.

 

[ZachyCatGames]

By your argument PS3 CFW can be considered a brick, because it bricks super slims if you manage to install it.

If it does brick them, then yes it'd be a brick

Also if you're saying autoRCM isn't a brick because it's easy to reverse/fix or whatever, then a bluescreen'd switch also wouldn't be bricked.

 

[smf]

If it does brick them, then yes it'd be a brick

His argument was that if it can brick something, then it's ALWAYS a brick. So every file ever created is considered a brick, because it could brick something.

Trying to include patched switches in the argument makes it meaningless.

Also if you're saying autoRCM isn't a brick because it's easy to reverse/fix or whatever, then a bluescreen'd switch also wouldn't be bricked.

It's not a brick because RCM is working fine & you wanted it to go into RCM mode & you can then boot from RCM mode.

If consoles with autorcm were bricked then nobody would be using it.

 

[ZachyCatGames]

It's not a brick because RCM is working fine & you wanted it to go into RCM mode & you can then boot from RCM mode.

If consoles with autorcm were bricked then nobody would be using it.

Why do you think it automatically boots a system into RCM...
And end users aren't intended to be using RCM/APX mode

 

[smf]

And end users aren't intended to be using RCM/APX mode

So what? if they didn't want people to access it they shouldn't have made it accessible via a key combination.

 

[ZachyCatGames]

so what? if they didn't want people to access it they shouldn't have made it accessible via a key combination.

It's intended for companies to repair systems, if we didn't have fusee gelee we wouldn't be able to do ANYTHING with RCM/APX mode. It automatically boots to it when it can't boot to anything, we're taking advantage of that my intentionally messing up our BOOT0 so it has nothing to boot to. It is factually partially bricking our systems

 

[smf]

if we didn't have fusee gelee we wouldn't be able to do ANYTHING with RCM/APX mode.

Luckily we do. Auto rcm is almost like changing your pc boot settings to boot from an external usb stick and never from the internal hard drive.

 

[ZachyCatGames]

Luckily we do. Auto rcm is almost like changing your pc boot settings to boot from an external usb stick and never from the internal hard drive.

I'm honestly starting to think you're a troll or something

 

[smf]

I'm honestly starting to think you're a troll or something

I already know you are.

Once we have emunand then should be able to remove the eMMC completely and you'll again always end up in RCM where you can boot from external media. Will you still be claiming that is a brick?

Does that mean everything that boots from external media is a brick? All raspberry pi's are bricks for example?

 

[mattytrog]

I have a solution!

We can call autoRCM a "controlled brick".

Anyway... someone mentioned Hekate "sleep mode"

Adding sleep mode to Hekate should be a matter of putting MAX77620 into a different state (doable), by modifying the power_off instruction
Turning backlight off after a timeout (doable)
(probably not necessary) - freeing fb

It would only work with Atmosphere though.

Will look into it later and post my findings

EDIT:

Just for testing, I am in the process of adding "LiveRCM" to my Franken-Hekate.

What it does (or supposed to do) is enable autoRCM at every shutdown and just prior to launching, before pkg1 is unpacked, disables autoRCM. This would allow horizon to see a correct boot0/1 / bct.

Coupled with Atmos` reboot to payload feature, every "power-off" from within Hekate would re-enable autoRCM prior to sending switchoff command to MAX77620.

Just a concept. Will let you know how it works in practice.

 

[smf]

We can call autoRCM a "controlled brick".

Why the insistence on using the word brick? It's a negative word that means the device is broken, it puts people off using it just because of the word brick. The switch is fine.

I understand the argument but it's black/white thinking that is really unhelpful.

We already have a term that more accurately described it, it's a recovery boot loop. If you feel like you need to give it some description other than forcing rcm on every boot.

 

[mattytrog]

Why the insistence on using the word brick? It's a negative word that means the device is broken, it puts people off using it just because of the word brick. The switch is fine.

I understand the argument but it's black/white thinking that is really unhelpful.

We already have a term, it's a recovery boot loop.

I dunno. Don`t give a monkeys to be honest.

Choose what term you like... "Controlled Brick", "Controlled byte-replacement".

The fact remains is IF you enable/use autoRCM, and you suddenly have NO WAY of injecting a payload (ie USB port breaks), then whichever way you cut that cake, it IS a brick. Not in the traditional sense, but a brick nonetheless.

 

[smf]

The fact remains is IF you enable/use autoRCM, and you suddenly have NO WAY of injecting a payload (ie USB port breaks), then whichever way you cut that cake, it IS a brick. Not in the traditional sense, but a brick nonetheless.

You mean if it breaks in a way that prevents data, but power is fine?

 

[mattytrog]

You mean if it breaks in a way that prevents data, but power is fine?

Erm... I suppose.

Like I say, it isn`t important. It can be called "Steaming Turd" for all I care

I don`t think its important to split hairs like this

 

[Zumoly]

Just for testing, I am in the process of adding "LiveRCM" to my Franken-Hekate.

What it does (or supposed to do) is enable autoRCM at every shutdown and just prior to launching, before pkg1 is unpacked, disables autoRCM. This would allow horizon to see a correct boot0/1 / bct.

Coupled with Atmos` reboot to payload feature, every "power-off" from within Hekate would re-enable autoRCM prior to sending switchoff command to MAX77620.

Just a concept. Will let you know how it works in practice.

Interesting. I'd like to see this experiment.

 

[mattytrog]

Interesting. I'd like to see this experiment.

Well... Experiment tested with a modchip-less unit.

It works.
However, if you hard power off from Horizon, autoRCM will remain disabled of course. So I`d forget about saving fuses with it.

And if you do "power-off" from within Hekate, you will need your dongle to re-inject.

Haven`t looked at sleep mode yet.
Think I need to add some code to max77620.h looking at datasheet.

Seems to be at 0x43(I think), send bit 2 to sleep instead of bit 1 to power-off. I`m sure there is more to it than that, but its a start.

Not really had a play yet. Will do later.