Hacking Is it possible to "dual boot" 2 CFW's

Status
Not open for further replies.
Thx alot!
You might want to chainload ReiNAND through Luma, or at least chainload BootCtr9 through it if you still want to use that. I've heard reports that BootCtr9 is not entirely stable when booting Luma, and Luma sometimes errors as a result. That may have been fixed now, but it was only a few days that I last saw someone post about that.
I think it has something to do with the way it's passing the .firm path to Luma.
 
I never actually meant to imply ReiNand wasn't simple, but rather that the dev has left the scene, meaning there's no official updates.
I remember when ReiNand was seemingly discontinued around November & a few games / updates (e.g. ACNLs) couldn't work on it. Obviously it got updated a while later but my point still stands that without updates, stuff will eventually get broken. That doesn't mean users shouldn't/can't use it while it's still functional though.
I am a official dev. I have been the one upkeeping Reinand since December.
 
When I first came into the Scene ReiNand was the big thing, and I was as happy as a child getting some toys when I managed to run it through menuhax, good old memorys. I'll never forget Reinand.
Mine was RXTools and I still remember the first time I booted into an emuNAND and my mind was blown! I was quick and eager to learn more and do more.
 
  • Like
Reactions: CrimsonMaple
I know, I guess it's something I'll work around. Personally I find it a pain. But that's me.

Much of the goal with B9S's release was to set standards for payload loading via FIRM etc, so that everyone (including non-luma cfws) can reap the benefits of a standardized execution environment where you know what to expect, and without gross hardcoded stuff of previous payload loaders. I'd like to think B9S is, like bootmii before it, a platform in that regard.

I'm sorry you find it a pain, but standards like argc/argv are for the best.

Is there any compelling reason you can provide to prefer the old "hardcoded shit" model of operation?
 
Last edited by SciresM,
My opinion on that is, people think it is better having less because they are free to add anything they want in it, such as ReiNAND. It is like, you are "baking" your perfect CFW by only taking the patches you need. Luma is a pack of patches (that can be useful or not depending of the user), but you are not free to change. I do think i've "resumed" the situation. Feel free to correct me ico.
If you want to add anything you want, just fork luma. It's still open sourced, this isn't ntr but it's an actual cfw.
 
Mine was RXTools and I still remember the first time I booted into an emuNAND and my mind was blown! I was quick and eager to learn more and do more.
After trading my 6 months old O3DS for a N3DS (obviously updating to 9.5 for the transfer) and later finding Cubic Ninja for 15 €, I bought a 2DS on 8.1 just to install legit cias on rxtools 2.3...

What has science done!
 
I am a official dev. I have been the one upkeeping Reinand since December.
Could you point me to an active github repo then? Because Rei's one and your fork don't seem to be active. I'm genuinely curious in trying it out lol
 
Much of the goal with B9S's release was to set standards for payload loading via FIRM etc, so that everyone (including non-luma cfws) can reap the benefits of a standardized execution environment where you know what to expect, and without gross hardcoded stuff of previous payload loaders. I'd like to think B9S is, like bootmii before it, a platform in that regard.

I'm sorry you find it a pain, but standards like argc/argv are for the best.

Is there any compelling reason you can provide to prefer the old "hardcoded shit" model of operation?
No, no I find no reason to prefer the "hardcoded shit", I just don't like that chainloaders have to pass their own ARGC and ARGV. I feel like the payloads can do that themselves, especially if they are meant to work as standalones.
 
If you want to add anything you want, just fork luma. It's still open sourced, this isn't ntr but it's an actual cfw.

But being the fact that this is Luma, don't you think that some patches will be already up to go ? Deleting Rosalina for example could be very difficult to do. Imagine you wanna go from scratch, since reiNAND is the core of Luma, don't you think you might start with Rei and then add things in it ? Only my opinion though.
 
If you want to add anything you want, just fork luma. It's still open sourced, this isn't ntr but it's an actual cfw.
If you want a 3-floor building, why buy bricks for a 10-floor one and only use some of them, when you could buy a package good for 2 floors then add the few missing ones?
 
But being the fact that this is Luma, don't you think that some patches will be already up to go ? Deleting Rosalina for example could be very difficult to do. Imagine you wanna go from scratch, since reiNAND is the core of Luma, don't you think you might start with Rei and then add things in it ? Only my opinion though.
Um, use the luma legacy branch? If you do that, you get way more features from the start, and are free to add and remove features.
 
  • Like
Reactions: sp3off
Could you point me to an active github repo then? Because Rei's one and your fork don't seem to be active. I'm genuinely curious in trying it out lol
I haven't pushed any code. Mostly because my big update isn't ready yet.
 
Um, use the luma legacy branch? If you do that, you get way more features from the start, and are free to add and remove features.

Ah. You might get a point mate.

EDIT : The thing is, legacy is deprecated, since it uses A9LH instead of B9S. It means a total rework of the code (and yes, I know that some builds were made using B9S, but to be sure about good builds, you need to go to the normal branch)
 
Last edited by sp3off, , Reason: Thought about it. Twice.
No, no I find no reason to prefer the "hardcoded shit", I just don't like that chainloaders have to pass their own ARGC and ARGV. I feel like the payloads can do that themselves, especially if they are meant to work as standalones.

If the primary loader for a platform (as B9S does) provides argc/argv, all applications designed to be run on the arm9 can and should expect it -- that kind of standardization of execution environment is part of what I mean by saying it's a platform.

Luma, as far as I'm aware, complies with this in order to support payloads that rely on this standardized execution environment, as it should.

Payloads can ignore what's passed to them trivially, by simply overwriting the contents of R0 and R1 in init and thus losing argc and argv....but every chainloader should (and does, presently) comply to the standard to support the payloads that rely on it.
 
Um, use the luma legacy branch? If you do that, you get way more features from the start, and are free to add and remove features.
If you want to add anything you want, just fork luma. It's still open sourced, this isn't ntr but it's an actual cfw.

Or one could use, you know, something other than Luma. Luma isn't the holy grail, nor is it the answer to everything. Hell, it doesn't *need* to be the answer to everything.


It's not actually an "actual cfw", however. It's more of a patcher than anything else.
 
Or one could use, you know, something other than Luma. Luma isn't the holy grail, nor is it the answer to everything. Hell, it doesn't *need* to be the answer to everything.


It's not actually an "actual cfw", however. It's more of a patcher than anything else.
It runs a custom sysmodule with a kernel extension, that's pretty actual-cfwy to me.
 
It's not actually an "actual cfw", however. It's more of a patcher than anything else.
Only the other CFWs are patchers, including older versions of luma (and even that isn't entirely true with Loader being reimplemented).

Luma on the other hand has its own process, own code injected into the kernel, etc...
 
It runs a custom sysmodule with a kernel extension, that's pretty actual-cfwy to me.
Wow HZMod also is a custom sysmodule, that doesn't turn it into an actual custom firmware, if somone presents me something like the linux 3ds project (which doesn't really do that much atm) that boots a complete different os, thats a custom firmware
 
  • Like
Reactions: sp3off
Wow HZMod also is a custom sysmodule, that doesn't turn it into an actual custom firmware, if somone presents me something like the linux 3ds project (which doesn't really do that much atm) that boots a complete different os, thats a custom firmware
HorizonM doesn't have a kernel extension you dolt.
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum