​

A new stable version of @Reisyukaku's Nintendo Switch custom firmware, ReiNX, was released today, bringing it to version 2.0. Various notable features were added, including but not limited to full 6.2.0 support (which was initially featured in a commit made on the 9th of December but was not added to a stable release until now), a recovery chainloader and, most interestingly, a partial implementation of SX OS' services - namely ldr:cht (used for cheats), usbfs (self-explainatory) and tx (general purpose, including licensing and a few rommenu functions). While said services are still in early stages, they can still be considered noteworthy additiom as it's the first time an open source CFW tries to add features only found in TX's offering aside from signature patches.

Thanks to the implementation of these services, it's now possible to boot SX OS' Rommenu and use some, not all its features under ReiNX (source here)

You can find the full changelog below:

• Full 6.2 support
• warmboot w/ sig checks disabled
• partial implemented services tx, ldr:cht, usbfs
• Recovery chainload
• landscape gfx
• all kips active by default (required)
• lots of stability updates (TM)

Source: GitHub
Official Thread
Releases

 

[RattletraPM]

How would a proper EmuNAND work and how does that differ from SX's current offering?

By actually redirecting I/O using hypervisor instructions instead of messing around with the partition table each time the console is booted. Just because you have an option to set up an EmuNAND on your microSD now it doesn't mean it's proper.

 

[Deleted User]

By actually redirecting I/O using hypervisor instructions instead of messing around with the partition table each time the console is booted. Just because you have an option to set up an EmuNAND on your microSD now it doesn't mean it's proper.

That's what SX does (redirecting I/O but without the hypervisor part as it's not needed). I don't know where you get the idea it's messing with the partition table because it clearly isn't.

Hence my question where does SX differ? Because it seems to do what you describe as a proper EmuNAND

 

[RattletraPM]

That's what SX does (redirecting I/O but without the hypervisor part as it's not needed). I don't know where you get the idea it's messing with the partition table because it clearly isn't.

The EmuNAND on internal NAND solution does that and that's why I said it's so bad. It does nothing else than check for another partition on the NAND, check if it's valid, then swap its entry in the GPT on the fly if the user decides to boot in EmuNAND. The microSD option does somewhat use redirection as it uses Thermosphère code, specifically the SDMMC driver, but there's a reason why Thermosphère isn't out yet - it's unfinished. If you don't believe me you can take a look at its code on GitHub. The other TX additions were done to the loader (which borrows some functions from the previous solution), not the driver itself, which means you're essentially using something that is unfinished and also borrows code that is known to not exactly be on spec for an EmuNAND. That's why I said it's better: it works okay for most people, but I wouldn't exactly call it proper.

If you want sources, it's a bit of Atmosphère's GitHub repo, hexkyz and naehrwert's Twitter and a bit of digging as I don't agree completely with those two's views so I want to keep myself neutral. If you have any in-detail insights on how the EmuNAND works past v2.3 to prove me wrong, let me know.

 

[Deleted User]

I feel like there is a lot of misunderstanding here. As I RE'd a lot of TX's code and delved deep into the workings of EmuNAND I can tell you how it works.

First misconception: The EmuNAND on internal NAND does not swap entries in the GPT on the fly. It simply redirects all eMMC SDMMC IO read/write blocks by changing the block address. The EmuNAND on microSD added support for enabling microSD early in the system boot process, but from there it's also just simply redirecting IO to microSD and changing the block address too.

Second misconception: Did you actually look at the thermosphere code on github? I'll point you to it:

• https://github.com/Atmosphere-NX/Atmosphere/tree/thermosphere_dev/thermosphere/src
• https://github.com/Atmosphere-NX/Atmosphere/tree/master/thermosphere/src/lib

Where's this so-called SDMMC driver for Thermosphere? There's nothing there!

And besides, there are so many possible SDMMC drivers out there as the Tegra X1 is a bog standard SD Host Controller interface. So it doesn't need to be a driver specifically written for the Switch.

At this point the Hypervisor method is not going to bring much more 'proper' to the table. In fact I'd wager it would make the system much much slower, because that Hypervisor context swapping does not come for free

Also one more note, naehrwert had a working emunand solution without hypervisor too. I'll let you think about that.

 

[guily6669]

Well I'm actually happy with my current emunand on M-SD, I only bought SX OS recently since they introduced the M-SD emunad, just had problems booting at first, but after making it run it never failed on me, though I barely used my Switch anyway...

I wanted is to use the new partition M-SD emunand, but I want to know how could I access the files and also update the emunand with exFat support since my console is on 3.02 with no exFat update, but my current emunand on M-SD as files is at 6.2 with exFat working fine (just had to make the emunand with the card as fat 32, update emunand with the exFat update, backup files, format mSD to exFat and put the emunand files back in and that's it).

On my newest recent Kingston 128GB A1 the emunand loads simply as fast as the original nand, no slowdows while with my older slow Toshiba 128GB crap mSD it gets pretty slow even to launch it, but I also had enough with cheaper Sandisk A1 since the 3 128GB original I had all had speed problems, Kingston A1 is my recommendation for a good fast mSD.

 

[RattletraPM]

I feel like there is a lot of misunderstanding here. As I RE'd a lot of TX's code and delved deep into the workings of EmuNAND I can tell you how it works.

First misconception: The EmuNAND on internal NAND does not swap entries in the GPT on the fly. It simply redirects all eMMC SDMMC IO read/write blocks by changing the block address. The EmuNAND on microSD added support for enabling microSD early in the system boot process, but from there it's also just simply redirecting IO to microSD and changing the block address too.
Second misconception: Did you actually look at the thermosphere code on github? I'll point you to it:

• https://github.com/Atmosphere-NX/Atmosphere/tree/thermosphere_dev/thermosphere/src
• https://github.com/Atmosphere-NX/Atmosphere/tree/master/thermosphere/src/lib

Where's this so-called SDMMC driver for Thermosphere? There's nothing there!

And besides, there are so many possible SDMMC drivers out there as the Tegra X1 is a bog standard SD Host Controller interface. So it doesn't need to be a driver specifically written for the Switch.

At this point the Hypervisor method is not going to bring much more 'proper' to the table. In fact I'd wager it would make the system much much slower, because that Hypervisor context swapping does not come for free

I'll give you one thing: I was wrong about GPT in the latest update. The driver did indeed change at some point so maybe it's actually viable, but things changed after the 2.3 update. Maybe it isn't so bad to use it now, but I definitely wouldn't recommend it before. (Source is below.)

About the second misconception, yes, I've looked at the source code and Atmosphère is not just using any standard driver but instead uses its own one. It's not directly used by Thermosphère, I might've been wrong there, but its indeed its own, not any standard one. It also does use not just the drivers but also other Thermosphère code (a bit veiled, I know, and I don't want to spark any "stolen code" discussion here) so if by linking that you wanted to demostrate it's unfinished then well... you did. That one tweet about Thermosphère is a bit old, but hey, there's others in the feed.

 

[Deleted User]

I don't base my findings on tweets, I delve deep into the code and see for myself. To that end I find no evidence that the SDMMC driver is 'borrowed' from Atmosphere's so I must assume this is more of hexkyz bias

Also I think you misunderstand the tweet about TPIDR_EL2, it's referencing an Aarch64 register that TX uses to detect tampering of their OS. However, leave it to hexkyz to spin it into some bias against TX again and suggest it is "stealing" the hypervisor method of Atmosphere (Thermosphere) which has almost next to no code at all in their github

 

[RattletraPM]

I don't base my findings on tweets, I delve deep into the code and see for myself. To that end I find no evidence that the SDMMC driver is 'borrowed' from Atmosphere's so I must assume this is more of hexkyz bias

Also I think you misunderstand the tweet about TPIDR_EL2, it's referencing an Aarch64 register that TX uses to detect tampering of their OS. However, leave it to hexkyz to spin it into some bias against TX again and suggest it is "stealing" the hypervisor method of Atmosphere (Thermosphere) which has almost next to no code at all in their github

...Alright, if this conversation is taking this track then it means it's starting to spiral out of control, no need to point fingers. I was just quoting him to give a source, not basing my opinions on his tweets. He proved to be biased in the past and that's why I said I've done some digging to check if whatever he said was too biased, then form an opinion of my own. He was the first one to actually gets his hands dirty with SX OS' decrypting and most of the times he gave detailed explainations and was provably right, so that's why I got into Atmosphère's source to check if there was a bit of truth, which I've found. Besides, while looking about EmuNAND I stumbled on your post about how SX OS's pre-2.3 EmuNAND worked and it looks like your explaination and hexkyz's largely match and his own was published a bit earlier than yours, so hey, at least you agree on something I guess?

About that last tweet, I was actually not sure whether to link it or not as I didn't fully understand it (if you don't believe me, look at the edit history) so I shouldn't have linked it in the first place.

Still, I was serious about the EmuNAND details, if you disagree with anyone and wish to either update that EmuNAND post covering SD EmuNAND or provide some more detailed evidence, I'd take it - I want to stay neutral in the TX vs Atmosphére debate so other independent sources would be appreciated considering how bisased the scene is with each side.

 

[Deleted User]

Thanks, that's appreciated. I understand in these days of "fake news" information is coming from everywhere and it's hard to differentiate what is true and what is propaganda. And for non-technical people especially to understand what's going on under the hood

 

[RattletraPM]

Thanks, that's appreciated. I understand in these days of "fake news" information is coming from everywhere and it's hard to differentiate what is true and what is propaganda. And for non-technical people especially to understand what's going on under the hood

No problem. Just be sure to include proof if what you want to do is combat said "fake news", otherwise they might not do all that good.
I think we're done here now, let's not derail this any further.

 

[EmulateLife]

I'm confused. Someone in the original ReinX thread said playing from usb is still not possible, but what is usbfs? Is that not the ability to play from usb like SX OS?

 

[RattletraPM]

I'm confused. Someone in the original ReinX thread said playing from usb is still not possible, but what is usbfs? Is that not the ability to play from usb like SX OS?

The usbfs sysmodule in ReiNX is still a stub, it's the only one that's basically empty. In a nutshell, the various command IDs have been noted down however they have to be filled with actual code before it'll be functional.

Also keep in mind that usbfs is just the sysmodule used to mount and interact with external USB drives, XCI loading is handled by other components, so even with it being fully functional there will still be other work to do before you'll be able to mount XCI files from USB.

 

[Nononoki]

Can't wait to switch back to ReiNX!

 

[dexter90]

hi, since I upgraded to reinx 2.0 I'm having a bit of trouble. When I try to enter the settings I get an error and the console crashes. It does not start anymore tinfoil (ex DZ), but this I think is a problem of the program. Occasionally it crashes when I leave homebrew. Does anyone have the same problems?

Sorry for me bad english

 

[whobroughtben]

This looks great, i might give this a try over my atmosphere setup.

Also, big thanks to moderators for cleaning up the posts with people thread bashing/trolling, it’s made reading through this article much easier.

 

[GaaraPrime]

Did anyone notice that using ReiNX 2.0 no longer shows "ReiNX" in System Settings > Firmware

 

[Alex4nder001]

I enabled autoRCM in hekate, and for some reason my Switch doesn’t seem to be charging unless it’s fully powered off. I thought it WOULD charge once booted into CFW?

Someone please help

 

[Panzerfaust]

updated my reinx to 2.0 last week and yesterday I noticed, that i can't access the album anymore. with older reinx version, it was R+album but now it doesnt work anymore...for me at least. any suggestion?

 

[chronoss]

Hello !

Someone can send me th splash 2.0 of ReiNX please ?

 

[Reisyukaku]

I enabled autoRCM in hekate, and for some reason my Switch doesn’t seem to be charging unless it’s fully powered off. I thought it WOULD charge once booted into CFW?

Someone please help

Mine charges fine in cfw. It's defintely not a cfw issue.

updated my reinx to 2.0 last week and yesterday I noticed, that i can't access the album anymore. with older reinx version, it was R+album but now it doesnt work anymore...for me at least. any suggestion?

You may have been using the legacy method.. in that case remove the hbl.nsp and see if that works.

Did anyone notice that using ReiNX 2.0 no longer shows "ReiNX" in System Settings > Firmware

I removed it for a few months because reasons but it should be back again in latest