ReiNX 2.0 released, adds partial TX services and full 6.2 support

VBliYDB.png

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)

:download: Source: GitHub
:arrow: Official Thread
:download: Releases
 
Last edited by RattletraPM,

RattletraPM

Well-Known Member
OP
Member
Joined
Jan 18, 2017
Messages
897
Trophies
1
XP
8,183
Country
Italy
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.
 
Last edited by RattletraPM,
D

Deleted User

Guest
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
 
  • Like
Reactions: thaikhoa

RattletraPM

Well-Known Member
OP
Member
Joined
Jan 18, 2017
Messages
897
Trophies
1
XP
8,183
Country
Italy
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.
 
Last edited by RattletraPM,
D

Deleted User

Guest
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:
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.
 
Last edited by ,

guily6669

GbaTemp is my Drug
Member
Joined
Jun 3, 2013
Messages
1,986
Trophies
0
Age
32
Location
Doomed Island
XP
1,562
Country
United States
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

Well-Known Member
OP
Member
Joined
Jan 18, 2017
Messages
897
Trophies
1
XP
8,183
Country
Italy
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:
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.
 
Last edited by RattletraPM,
D

Deleted User

Guest
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
 
Last edited by ,

RattletraPM

Well-Known Member
OP
Member
Joined
Jan 18, 2017
Messages
897
Trophies
1
XP
8,183
Country
Italy
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.
 
Last edited by RattletraPM,
  • Like
Reactions: Heichart

RattletraPM

Well-Known Member
OP
Member
Joined
Jan 18, 2017
Messages
897
Trophies
1
XP
8,183
Country
Italy
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.
 
Last edited by RattletraPM,
  • Like
Reactions: Heichart

EmulateLife

Well-Known Member
Member
Joined
May 30, 2016
Messages
3,981
Trophies
0
Age
40
XP
1,857
Country
United States
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

Well-Known Member
OP
Member
Joined
Jan 18, 2017
Messages
897
Trophies
1
XP
8,183
Country
Italy
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.
 
Last edited by RattletraPM,

dexter90

Active Member
Newcomer
Joined
Nov 20, 2016
Messages
30
Trophies
0
Age
32
XP
136
Country
Italy
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

Well-Known Member
Newcomer
Joined
Nov 14, 2018
Messages
93
Trophies
0
Age
34
XP
791
Country
United States
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.
 

Alex4nder001

Part-time thug
Member
Joined
Jul 28, 2017
Messages
450
Trophies
0
Location
London
XP
1,505
Country
United Kingdom
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

Well-Known Member
Member
Joined
Oct 25, 2018
Messages
112
Trophies
0
XP
1,148
Country
Germany
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?
 

Reisyukaku

Onii-sama~
Developer
Joined
Feb 11, 2014
Messages
1,534
Trophies
0
Website
reisyukaku.org
XP
5,379
Country
United States
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
 
Last edited by Reisyukaku,
  • Like
Reactions: chronoss
General chit-chat
Help Users
    Dark_Phoras @ Dark_Phoras: @_47iscool do you mean there's a conspiracy to hide the true origins of hip hop in 1920s Sweden?