Hacking Question SX OS doesn't power off my console.

[leonmagnus99]

hey mate @OP i have the same thing and just never rly cared though.
like i noticed when i had my switch powered off i did not need to press power to boot it then use tx app on my android to boot into either cfw/ofw.

as i connected like you with your pc, itd automatically turn on, this is most likely due to having autorcm enabled.
i love autorcm though and i dont mind that minor inconvenience, i never turn my switch off anyway, so its fine the way it works.

 

[DocAmes1980]

Yes. It seems to be involved with the power off routine / battery calibration code of the Linux desynchronization fix.

Are you sure? Wasn't the desync fix only introduced in SX OS 1.3? The powering off issue was happening before 1.3.

 

[mattytrog]

Are you sure? Wasn't the desync fix only introduced in SX OS 1.3? The powering off issue was happening before 1.3.

No, not 100%. At all. Just a theory.

Not done any in-depth testing yet as to why.

But it is definitely rebooting to RCM to get the payload to finish powering off the console.

One thing we did find out, was that in our internal trinket thread, Hekate was not powering down correctly due to the original Sam fuse launcher putting the trinket to sleep and the M92T36 didn't completely power off leaving the trinket asleep on reboot, leading to RCM. By setting foundtegra to false, the trinket now looks for the Tegra more. I'm in the process of making a GitHub with the differences in code. But they are minimal to say the least.

 

[Tomobobo]

It sounds like the trinket guys just got lucky, as their chips are always connected and trying to detect RCM modes. So when their chips detect semi-rcm and send a payload to it, they automatically turn off their switches. If I'm gathering this right they previously had setups that would fail to do this, like with homeboy's video, and they made changes to their installation and chip operation until desired results started happening.

But they didn't know that it was semi-rcm, I don't think anyone knew that it wasn't really RCM mode. So much misinformation out there and insults being tossed out but nobody actually knew what was happening at all.

From what I've gathered, it's as simple as this:

Horizon, for whatever reason, can't truly shut down a switch that has autorcm installed.

 

[mattytrog]

It sounds like the trinket guys just got lucky, as their chips are always connected and trying to detect RCM modes. So when their chips detect semi-rcm and send a payload to it, they automatically turn off their switches. If I'm gathering this right they previously had setups that would fail to do this, like with homeboy's video, and they made changes to their installation and chip operation until desired results started happening.

But they didn't know that it was semi-rcm, I don't think anyone knew that it wasn't really RCM mode. So much misinformation out there and insults being tossed out but nobody actually knew what was happening at all.

From what I've gathered, it's as simple as this:

Horizon, for whatever reason, can't truly shut down a switch that has autorcm installed.

I wouldn`t say luck. Symptoms presented slightly differently but the solution was the same.

Maybe a little luck and co-incidence.

 

[Retrojunkies]

If this is how it is supposed to work it's not documented in the SX OS manual nor is it stated in the warning on the SX OS boot menu. Of course users would expect that the system would stay powered down when you select "turn off" from horizon. You being a dick to the OP was unwarranted.

why would you cover how nintendo's recover mode works.

they have details how to use sx.

the user is told that when installing autorcm that the console will boot automatically into recovery mode all the time and that the dongle is required at all times during this process.

 

[mattytrog]

There really is no such thing as semi-RCM. But I understand the definition.

You are either in RCM or you aren`t.

The only difference is that the switch cannot complete the shutdown process without seeing "something" either Nintendo bootloader or a payload.

I think it is as simple as Horizon shutting down and once shut down, the USB controller is double-checking everything is shut down, hence the attempted boot to RCM... The controller sees a boot, says "yep, horizon is shut down" and shuts down itself.

 

[Tomobobo]

If I understand correctly, tegrarcmsmash only detects switches when in rcm mode.

When in rcm mode, you can send a payload using that tool and boot the switch with whatever payload you sent over.

When I shut down the switch with autorcm installed,but leave a cable connected from switch to pc, 12 seconds later tegrarcmsmash detects a device in RCM mode.

When I try to send a payload to that device, the switch shuts down. This doesn't seem like the intended operation of tegrarcmsmash, or how it operates when a device is really in RCM.

The same thing happens with the sx pro dongle, it attempts to send a payload in this mode, but the switch just shuts off.

So how then, when I am in that mode, am I in RCM? If it doesn't work like RCM, how can you call it RCM? This is semi-rcm, because it "is" in a way in RCM mode, but doesn't operate the same.

And you say that you knew this, but your explanation as to what happens to some usb controller after horizon powers down seems like speculation at best.

Team Xecuter didn't know about this, this issue was not addressed in their 1.3 update, yet you claimed they fixed this issue and because of some soldering method you used, it now shuts down properly.

I'm not trying to be disrespectful, but from here, your story seems to have changed into theories and speculation, leading me to believe that while you might have discovered that another payload must be sent before shutdown, you did and still do belive that that is RCM mode, and I believe that that information is wrong and the reason there is so much confusion with "autoRCM draining battery" on this forum.

Until semi-rcm mode works like rcm mode, I'm calling them different things. Call it zombie mode, call it anything, but don't call it RCM if it doesn't work like RCM. If you're in semi-rcm, rcm things don't work, in fact as far as we can tell, normal operations shut the system down.

If you have any information that a "usb controller" is running after horizon shut down, or have proof that somehow only with autoRCM installed do devices keep this controller running and need a "sign off" payload to shut down, I'd love to see it.

I'd be willing to bet that you could send a different payload to the switch. Say after booting hekate, you power down through horizon, attempt to send sxos payload, and the switch will shut down. That would show that there's no way it needs some kind of "closing" payload to be sent at all, if the two payloads have nothing to do with each other, but give the same result.

If we can understand how semi-rcm works, we have more info to make decisions with. Ideally though, if we could never get into this mode, it would be preferred.

 

[mattytrog]

If I understand correctly, tegrarcmsmash only detects switches when in rcm mode.

When in rcm mode, you can send a payload using that tool and boot the switch with whatever payload you sent over.

When I shut down the switch with autorcm installed,but leave a cable connected from switch to pc, 12 seconds later tegrarcmsmash detects a device in RCM mode.

When I try to send a payload to that device, the switch shuts down. This doesn't seem like the intended operation of tegrarcmsmash, or how it operates when a device is really in RCM.

The same thing happens with the sx pro dongle, it attempts to send a payload in this mode, but the switch just shuts off.

So how then, when I am in that mode, am I in RCM? If it doesn't work like RCM, how can you call it RCM? This is semi-rcm, because it "is" in a way in RCM mode, but doesn't operate the same.

And you say that you knew this, but your explanation as to what happens to some usb controller after horizon powers down seems like speculation at best.

Team Xecuter didn't know about this, this issue was not addressed in their 1.3 update, yet you claimed they fixed this issue and because of some soldering method you used, it now shuts down properly.

I'm not trying to be disrespectful, but from here, your story seems to have changed into theories and speculation, leading me to believe that while you might have discovered that another payload must be sent before shutdown, you did and still do belive that that is RCM mode, and I believe that that information is wrong and the reason there is so much confusion with "autoRCM draining battery" on this forum.

Until semi-rcm mode works like rcm mode, I'm calling them different things. Call it zombie mode, call it anything, but don't call it RCM if it doesn't work like RCM. If you're in semi-rcm, rcm things don't work, in fact as far as we can tell, normal operations shut the system down.

If you have any information that a "usb controller" is running after horizon shut down, or have proof that somehow only with autoRCM installed do devices keep this controller running and need a "sign off" payload to shut down, I'd love to see it.

I'd be willing to bet that you could send a different payload to the switch. Say after booting hekate, you power down through horizon, attempt to send sxos payload, and the switch will shut down. That would show that there's no way it needs some kind of "closing" payload to be sent at all, if the two payloads have nothing to do with each other, but give the same result.

If we can understand how semi-rcm works, we have more info to make decisions with. Ideally though, if we could never get into this mode, it would be preferred.

It isn't the intended behaviour from Tegra RCM smash.

However, it is intended from Horizon / the usb controller.

It is the reason Horizon boots when plugged in...

 

[Tomobobo]

This also isn't the intended behavior for the sx pro dongle.
With your trinket, you did intend for the trinket to inject a payload after shut down, but again only because it give you desired results. You don't actually know the reason why when you send another payload in semi-rcm it shuts down, only that it does, and that's what you wanted.

With my virgin switch, if I shut down and leave a usb cable connected, 12 seconds later I do not get the usb connect notification, so without booting from rcm, the switch doesn't seem to "turn back on" 12 seconds later.

But a switch that booted from rcm does turn back on, you're saying that's horizon's intended behaviour?
Maybe it's a misunderstood behavior of booting from rcm.

When sx menu says shutdown, we don't get the same problem, so the problem does lie in horizon somewhere.

The switch boots when plugged in because the switch detects a power source. If you have auto rcm, and plug in a powered usb, the switch will boot RCM. (even if it is in semi-rcm) Here we don't even need to send a payload, without autorcm = horizon, with autorcm = RCM, and idk even how we would affect the "bootloader" by pluging in a powered usb cable.

I don't see anywhere in the development of these payloads, did they engineer the payload to be re-sent after shut down. And definitely Nintendo wouldn't expect a payload either on normal reboot so saying it's intended horizon behavior doesn't seem like the right thing to say to me, maybe it's an intended behavior of RCM.

Somehow, after booting from rcm, horizon fumbles the shut down. Doesn't seem like something you'd intentionally try to do, but maybe I/we don't understand rcm fully?

From where I'm standing, it looks like booting from rcm messes up horizons shutdown, and we end up actually rebooting into RCM but without any thing else powered up. That's why I call it semi-rcm. If this is intentional, horizon would have to know that it booted from rcm somehow, right? We might need to change the way horizon shuts down. I'm thinking it'd be easeir to just have cfw shut down in whatever way the sx menu shuts down the switch rather than using horizons method, or a combination of both shutdown types. This should happen automatically. We can currently manually shut down through various methods, but it would be tits if we could get it to work right on its own.

edit: I think that's right. I went off on autorcm for some reason, but I remembered in kids video he doesn't have autorcm on, and the 12 second reboot still happens. Please correct me if I'm misunderstanding things.

 

[mattytrog]

This also isn't the intended behavior for the sx pro dongle.
With your trinket, you did intend for the trinket to inject a payload after shut down, but again only because it give you desired results. You don't actually know the reason why when you send another payload in semi-rcm it shuts down, only that it does, and that's what you wanted.

With my virgin switch, if I shut down and leave a usb cable connected, 12 seconds later I do not get the usb connect notification, so without booting from rcm, the switch doesn't seem to "turn back on" 12 seconds later.

But a switch that booted from rcm does turn back on, you're saying that's horizon's intended behaviour?
Maybe it's a misunderstood behavior of booting from rcm.

When sx menu says shutdown, we don't get the same problem, so the problem does lie in horizon somewhere.

The switch boots when plugged in because the switch detects a power source. If you have auto rcm, and plug in a powered usb, the switch will boot RCM. (even if it is in semi-rcm) Here we don't even need to send a payload, without autorcm = horizon, with autorcm = RCM, and idk even how we would affect the "bootloader" by pluging in a powered usb cable.

I don't see anywhere in the development of these payloads, did they engineer the payload to be re-sent after shut down. And definitely Nintendo wouldn't expect a payload either so saying it's intended horizon behavior doesn't fly with me, maybe it's an intended behavior of RCM.

Somehow, after booting from rcm, horizon fumbles the shut down. Doesn't seem like something you'd intentionally try to do, but maybe we don't understand rcm fully?

From where I'm standing, it looks like booting from rcm messes up horizons shutdown, and we end up actually rebooting into RCM but without any thing else powered up. That's why I call it semi-rcm. We might need to change the way horizon shuts down. I'm thinking it'd be easeir to just have cfw shut down in whatever way the sx menu shuts down the switch rather than using horizons method, or a combination of both shutdown types. This should happen automatically. We can currently manually shut down through various methods, but it would be tits if we could get it to work right on its own.

edit: I think that's right. I went off on autorcm for some reason, but I remembered in kids video he doesn't have autorcm on, and the 12 second reboot still happens.

This "quirk" hasn`t been invented by any payload dev or launcher dev.

It is a side-effect if you like, of Horizon shutting down.

Yes, we figured out that something was happening after shutdown, and through experimentation, dealt with the problem in the easiest way. By changing the fusee launcher code to look for the Tegra in RCM after sending payload/shutdown rather than going to sleep straight away. Sleep isn`t required as much as the USB controller turns the trinket on and off as needed.

Because Horizon has shut down, the bootrom knows Horizon has shut down and is checking all is well and maybe handing power up control to the USB controller... this is happening at a lower level... IE in the USB controller (least likely) or Tegra bootrom (more likely).

What I 99% sure is happening...

The bootrom is checking that there has been a proper and intended shut-down. Flushing buffers? Checking NAND corruption maybe?

 

[Tomobobo]

This "quirk" hasn`t been invented by any payload dev or launcher dev.

It is a side-effect if you like, of Horizon shutting down.

Yes, we figured out that something was happening after shutdown, and through experimentation, dealt with the problem in the easiest way. By changing the fusee launcher code to look for the Tegra in RCM after sending payload/shutdown rather than going to sleep straight away. Sleep isn`t required as much as the USB controller turns the trinket on and off as needed.

Because Horizon has shut down, the bootrom knows Horizon has shut down and is checking all is well and maybe handing power up control to the USB controller... this is happening at a lower level... IE in the USB controller (least likely) or Tegra bootrom (more likely).

What I 99% sure is happening...

The bootrom is checking that there has been a proper and intended shut-down. Flushing buffers? Checking NAND corruption maybe?

Ah, that makes sense for sure. I still wonder why these same checks wouldn't happen when selecting power off from sx menu, and why when we get into this mode, when we send a payload, it shuts down, or if we insert a powered usb, it turns on seemingly forgetting it was in this mode.

 

[mattytrog]

Ah, that makes sense for sure. I still wonder why these same checks don't happen when selecting power off from sx menu....

I don`t know. Maybe SX have enabled their own power-off routine in SX loader (different from the one in the actual SXOS). Remember, SX loader is still on v1.0. It looks like it has basic (low level) power on/off stuffs, then hands over all control straight away to boot.dat on SD card, which will THEN boot SXOS or external payload.

Which is why it doesn`t get updated. It doesn`t need to be.

 

[Tomobobo]

Right so I went to boot hekate to see if from that menu the switch would turn back on after 12 sec. Pretty sure team x would be using something similar in their menu, but was just gonna check. It does work similarly to sx menu's power off.

Then I noticed different behavior than when I was messing around previously.

If I'm in SXOS and select Turn Off through Horizon with a usb cable connected to PC. 12 seconds later the switch comes back on into what I was calling semi-rcm. If I push sx payload through tegrarcmsmash, I will get a power off. BUT! if I push hekate here, hekate boots up... Now I'm totally confused. Semi-rcm was a lie? You just can't double up the payload or you'll power down?

No because booting hekate, then stock fw, Turn Off, 12 secs later, push hekate, and hekate boots up. Does team x actually have a trick up their sleeves after all?

 

[mattytrog]

Right so I went to boot hekate to see if from that menu the switch would turn back on after 12 sec. Pretty sure team x would be using something similar in their menu, but was just gonna check. It does work similarly to sx menu's power off.

Then I noticed different behavior than when I was messing around previously.

If I'm in SXOS and select Turn Off through Horizon with a usb cable connected to PC. 12 seconds later the switch comes back on into what I was calling semi-rcm. If I push sx payload through tegrarcmsmash, I will get a power off. BUT! if I push hekate here, hekate boots up... Now I'm totally confused.

Pretty sure SXOS and SX loader are working together on that.

So it appears it is not semi-RCM / zombie mode or whatever (just as I said, they don`t exist!) - it is RCM proper.

Horizon in SXOS is shutting down and SX loader provides the last bit of the puzzle.

Try Bricmii or memloader. Bet its the same result. Anything apart from SX loader, which is working with SXOS to shut down the switch.

Test the theory...

 

[Tomobobo]

Not sure what you wanted to test here but, when I push memloader, the only way to power off actually powers off, it doesn't reboot 12 sec later.

When I push bricmiiv2, the power button reboots into rcm, but when I try to repush bricmiiv2, tegrarcmsmash gives me a warning and says you want to push the same payload to the stack are you sure? and if I do, I get black screen but backlight on switch so.

OH I'm dumb. I was trying to test what other payloads did when the same payload was sent again, but you wanted sxos to bricmii..

 

[mattytrog]

Not sure what you wanted to test here but, when I push memloader, the only way to power off actually powers off, it doesn't reboot 12 sec later.

When I push bricmiiv2, the power button reboots into rcm, but when I try to repush bricmiiv2, tegrarcmsmash gives me a warning and says you want to push the same payload to the stack are you sure? and if I do, I get black screen but backlight on switch so.

I meant from SXOS, shut down and try pushing different payloads and see if they boot.

Hekate boots to menu...
SX Loader turns the console off...
What about the others? Bet they boot and don`t turn off the console.SX Loader will be the only one what will shut down the console I`m thinking...

 

[Tomobobo]

I meant from SXOS, shut down and try pushing different payloads and see if they boot.

Hekate boots to menu...
SX Loader turns the console off...
What about the others? Bet they boot and don`t turn off the console.SX Loader will be the only one what will shut down the console I`m thinking...

It's true. Team x might have thought of this after all, eh? Have they said anything about this?

 

[mattytrog]

It's true. Team x might have thought of this after all, eh?

Its the conclusion I came to during my tests.

We will still get noobs not understanding how it works and saying "SX pro sucks / Trinket sucks / TegraRCMsmash sucks" "My battery went flat using autoRCM - it sucks" then the old "You brick your console on purpose you idiot - you suck", not forgetting "You have flagged yourself for a ban for using big bad autoRCM - Your intelligence sucks"

If you get it, you get it. Which you clearly do!

 

[Tomobobo]

Well if the payload's .bin handles this already, this was either designed from the beginning, or they're the one's who got lucky.

If I boot hekate, go stock, powerdown, 12sec later I get rcm mode in tegrarcmsmasher. If I push sx payload, the switch shuts down. So how then can it know that it's on it's 2nd rcm go around? Semi-rcm lives?