Hacking WIP [Trinket] [Rebug] [Others] SWITCHBOOT_UF2 / FUSEE_UF2 modchip software

[mattytrog]

Wait... you can block original fw from destroying fuses?

If you use both straps, yes.

 

[linuxares]

If you use both straps, yes.

How the heck did you figure that out? xD

 

[mattytrog]

How the heck did you figure that out? xD

Well, fuses are burnt upon first boot of the stock Nintendo bootloader as we know.

However, because both "straps" are fitted and are active at every boot, it is not possible to boot without RCM as the chip triggers RCM 100% of the time.

The only time fuses will get burnt is if the reset button on the modchip is held down, which will result in a normal OFW boot, thus burning fuses as we are not booting through RCM.

I thought it was common knowledge that the "both" file saves fuses. Only pointed it out for those who are still getting head round it.

So. Yeah. Pretty good solution. I guess

 

[mattytrog]

already tried, not help.

--------------------- MERGED ---------------------------

i forget to mention that, i am using SD file emunand (not partition).

I see a few people are reporting similar. The problem must be TX's side. Go to sxos site and download newest boot.dat from there. I'm guessing you used the built in updater

 

[khpda]

I see a few people are reporting similar. The problem must be TX's side. Go to sxos site and download newest boot.dat from there. I'm guessing you used the built in updater

I have same issue since 2.5.0, then i try to download dat (2.5.1) file from sx, problem still exist.

I think payload not able to read emuland file if we boot from ur uf2 file.

 

[mattytrog]

I have same issue since 2.5.0, then i try to download dat (2.5.1) file from sx, problem still exist.

I think payload not able to read emuland file if we boot from ur uf2 file.

Very puzzling indeed...

Here, two of my test units are running latest (0.9.3 Simple-UF2, 6.2.0, FAT32 emunand SXOS 2.5.1) with zero issues whatsoever.

Random thought... As SXOS doesn`t correctly HWinit, could you have a problem with your battery? As Hekate does init correctly, maybe something is showing up and crashing the boot process. Battery / BQ24193 problem?

Seems more common in people who use autoRCM if battery has gone DEAD flat. Just a thought.

Gimme half hour... I`ll build you something to try.

 

[khpda]

Very puzzling indeed...

Here, two of my test units are running latest (0.9.3 Simple-UF2, 6.2.0, FAT32 emunand SXOS 2.5.1) with zero issues whatsoever.

Random thought... As SXOS doesn`t correctly HWinit, could you have a problem with your battery? As Hekate does init correctly, maybe something is showing up and crashing the boot process. Battery / BQ24193 problem?

Seems more common in people who use autoRCM if battery has gone DEAD flat. Just a thought.

Gimme half hour... I`ll build you something to try.

my device is fully charge and i just bought it 3 days ago, it can boot sx without emunand.

 

[mattytrog]

@khpda

Try this...

SX loader is payload 1. Other payloads are Simple-UF2.

So... Just put your boot.dat in SD root as usual... Flash this UF2 to chip.

Good luck!

 

[khpda]

@khpda

Try this...

SX loader is payload 1. Other payloads are Simple-UF2.

So... Just put your boot.dat in SD root as usual... Flash this UF2 to chip.

Good luck!

still cant boot Emunand. (able to boot SX in normal mode without Emunand).

 

[ErAzOr]

• Does not waste power. Switch is properly shut off

What does it exactly mean?
Usually when using AutoRCM and power off the switch, it stucks in RCM mode and drains the battery.

Does this feature prevent this?

 

[Gismor]

• Does not waste power. Switch is properly shut off

What does it exactly mean?
Usually when using AutoRCM and power off the switch, it stucks in RCM mode and drains the battery.

Does this feature prevent this?

you dont need AUTORCM for what? Make autoRCM disable and you have not battery drain

 

[ErAzOr]

But if I use the "Joycon Only" installation and want to boot directly into CFW, I need AutoRCM

 

[Gismor]

But if I use the "Joycon Only" installation and want to boot directly into CFW, I need AutoRCM

i use joycon onlyt and have auto rcm off.
you have the dual boot option this is the best way for joycon only and auto rcm off and boot directly into CFW

 

[ErAzOr]

So the question is the same for the "boot directly into CFW" variant. Does it drain the battery after powering off the switch?

 

[Gismor]

So the question is the same for the "boot directly into CFW" variant. Does it drain the battery after powering off the switch?

when you have AutoRCM off --> no
when you have AUTORCM on --> yes
or im wrong master @mattytrog

 

[mattytrog]

So the question is the same for the "boot directly into CFW" variant. Does it drain the battery after powering off the switch?

Nope. Off means off.

There is still a Mini-boot when turning off, but because payload is injected every time, it turns off.

For example... In atmosphere 0.8.2... rename "fusee-primary.bin" to "payload.bin"... Starts all good as expected.

Go to shut down, it will shutdown and 12 second layer, you will think it is booting again.

But watch... When atmosphere splash screen displays, the switch powers completely off.

Nothing we can do about this until someone figures out how to un-ipatch the t210.

 

[ErAzOr]

Thanks for the info.
But it's still not 100% clear to me.

Summarized it means
-AutoRCM enabled: the battery will drain after power off
-Volume+ strap connected: the battery will NOT drain after power off

Is this correct?

 

[snam11]

Dunno if it helps, but on mine i can run fine emunand (6.2) and sx os 2.4-2.5, with single and both straps connected.
I've never used autorcm (and to be honest i think is pointless because with both straps the chip can do better...).

 

[mattytrog]

Thanks for the info.
But it's still not 100% clear to me.

Summarized it means
-AutoRCM enabled: the battery will drain after power off
-Volume+ strap connected: the battery will NOT drain after power off

Is this correct?

No. Almost.

AutoRCM only drains the battery because the console cannot finish the "Mini-boot" and the max77620 is stuck in a limbo state.

AutoRCM will not drain battery if system is allowed to complete this mini-boot (which involves a fuse check (iirc) and routines to properly shut down oscillators, regulators and ic's and setting a flag to say it has done so).

Next time you turn your console off in AutoRCM , leave your payload injector plugged in. The console will then shut down correctly.

That's why this works.

Using a chip with switchboot etc, the following needs to be remembered..

Every time RCM is triggered by the chip, a payload is sent. Therefore being stuck unknowingly in RCM is impossible. Almost.

The only exception to this is when console is off and you plug into your PC. The chip cannot send the payload. However, RCM is still triggered. Now, this can be fixed relatively easily in code and fitting one more strap. However, it is handy for testing / pushing payloads from the PC with minimum of fuss.

The boot0 boot1 are not corrupted (which is how we do AutoRCM without modchip) so in the zero-likely event of being stuck in RCM, the emmc isn't corrupted. So you can get straight out of it.

Hope I making sense!

 

[Deleted User]

What would cause my trinket to not boot anymore? My switch died and I can’t get into hekate now. The green light on the trinket flashes green 5-8 times followed by a red light and doesn’t do anything

 

[mattytrog]

What would cause my trinket to not boot anymore? My switch died and I can’t get into hekate now. The green light on the trinket flashes green 5-8 times followed by a red light and doesn’t do anything

Broken USB connection to the trinket
Poorly soldered GND to trinket (very very common)

Failed payload send. What payload are you sending? What version are you using?