Hacking [Pre-release, WIP] Yet another rxTools?

[Billy Acuña]

@ Billy Acuna How's Lima3DS coming along, any new developments? Look forward to hearing back from you [emoji3]


Sent from my iPhone using Tapatalk

So much personal problems since 2 weeks ago sorry

 

[shawn_]

So much personal problems since 2 weeks ago sorry

I'm very sorry for what you are going through, hoping for the best [emoji1317] Personal things should definitely be first priority.


Sent from my iPhone using Tapatalk

 

[duke_srg]

Still works with EmuNAND 11.1

 

[AyanamiRei]

Actually I didn't touch entry points and CFW at all. Only menu system and actual tools was refactored. Literally only code in /rxtools subfolder was changed.

BTW, current rxTools fork is less hardcoded than any existing 3DS CFW. 3DS file formats, NAND format, SD boot sectors - all has been moved to structures from the hardcoded values.

Shall I use the current prealpha (4) or wait for a potential future beta version who might functions correctly with DS cartridges? (I would like to change my RxT while keeping most of its non-CFW functions)

 

[duke_srg]

Shall I use the current prealpha (4) or wait for a potential future beta version who might functions correctly with DS cartridges? (I would like to change my RxT while keeping most of its non-CFW functions)

You can try to use current version because there is no plans for beta in mean time since I currently have no time for development

 

[Madridi]

Since all the positive talks from the community has come up about rxTools revival. Maybe there is a renewed interest in this?

Glad to see some members are getting over their fanboyism over a certain cfw, and just allow the scene to grow. No harm with having options

 

[duke_srg]

For now it's not an interest but just idle talks. It's clear that many, if not the most, of the people wants to have a nice looking swiss-army-knife tool, but as a matter of fact almost none of them are able to contribute.
Interest will grow as soon as AL9H support will be added and I'm not capable of doing that.

 

[Madridi]

For now it's not an interest but just idle talks. It's clear that many, if not the most, of the people wants to have a nice looking swiss-army-knife tool, but as a matter of fact almost none of them are able to contribute.
Interest will grow as soon as AL9H support will be added and I'm not capable of doing that.

Yeah I was talking about interest from the community, not the devs. Clearly everyone is only supporting what they are supporting. I hope that doesn't remain to be the case

Still, great to hear from ya buddy

 

[Sketchy1]

Do I see an RX revival? Kudos, someone's standing up for the little guy

Good luck, will watch how this progresses

 

[Madridi]

@duke_srg
Btw, there was another branch in the main rxTools repo that added a9lh. It wasn't the greatest, as the installation that happens when you access rxTools menu for the first time was broken, and you had to do that the manual way. Worked fine afterwards.

Anyway, my point, I know the original rxTools code was messy, but surely you can use that to add a9lh support?

 

[iAqua]

+1, here's the branch with arm9loaderhax support.

 

[duke_srg]

+1, here's the branch with arm9loaderhax support.

This is a branch of rxTools Ver. 3 and I'm not sure it was ever working.
My branch was forked from the very last commit of version 2, just before the 'tools' were ripped out.
If someone have balls to check that branch at least can boot, I could reverse commits and add to my fork.

 

[Madridi]

This is a branch of rxTools Ver. 3 and I'm not sure it was ever working.
My branch was forked from the very last commit of version 2, just before the 'tools' were ripped out.
If someone have balls to check that branch at least can boot, I could reverse commits and add to my fork.

Yeah that's true. It was implemented after the decision to get rid of the tools. I did not move to rxtools v3 because of that.

While I can't test atm, I can only pass on the information that was available at the time: it does work, but the initial installation didn't work through a9lh. Had to be done first through mset/spider, etc..

Edit: also, why would you reverse commits? I don't get what you mean by that.

 

[duke_srg]

Yeah that's true. It was implemented after the decision to get rid of the tools. I did not move to rxtools v3 because of that.
While I can't test atm, I can only pass on the information that was available at the time: it does work, but the initial installation didn't work through a9lh. Had to be done first through mset/spider, etc..
Edit: also, why would you reverse commits? I don't get what you mean by that.

I just meant to take only the a9lh changes from that branch to give this one a bump.
Just looked into that commit, it looks like entry point is altered for use with a9lh but not the actual entry point address address, NAND mount seems to be broken (since unsuccessfull mount continues boot process, unlike in older versions).
Anyway to test either version we need a tested since I don't have a9lh enabled unit or desire to make a hardmod atm.
The good news is that devkitPro bundle has been recently updated, so master fork could be updated with the new libctru and other depenedencies.

 

[Madridi]

I just meant to take only the a9lh changes from that branch to give this one a bump.
Just looked into that commit, it looks like entry point is altered for use with a9lh but not the actual entry point address address, NAND mount seems to be broken (since unsuccessfull mount continues boot process, unlike in older versions).
Anyway to test either version we need a tested since I don't have a9lh enabled unit or desire to make a hardmod atm.
The good news is that devkitPro bundle has been recently updated, so master fork could be updated with the new libctru and other depenedencies.

I won't claim to know much about addresses, but from what I understand, the correct addresses in the payload for a9lh is 0x12000 .. Not sure if that helps in anyway but I'm sure people can weigh in.

In any case, I would be able to test anything you might decide to implement. I am just not able to test the older a9lh implementation atm.

 

[duke_srg]

I won't claim to know much about addresses, but from what I understand, the correct addresses in the payload for a9lh is 0x12000 .. Not sure if that helps in anyway but I'm sure people can weigh in.
In any case, I would be able to test anything you might decide to implement. I am just not able to test the older a9lh implementation atm.

It is the payload offset, I'm talking about the start address, check the mentioned commit comment
I didn't track a9lh changes, whats the different implementations?

 

[Madridi]

It is the payload offset, I'm talking about the start address, check the mentioned commit comment
I didn't track a9lh changes, whats the different implementations?

What I meant by my comment is that the a9lh implemented in the main rxTools right now uses different files than the original branch, and I didn't replace that as I use an older version (the beta from 15th October I believe) where everything at the time worked. I was never interested in the tools stripped out version.

As for the changes, I'm unfortunately not the best person to talk about this since I've haven't been much in the scene lately. What I do remember though is that there have been different implementation that deals with the option of having or not having screen init on boot. I'd rather leave this question for people who know more about this

 

[duke_srg]

What I meant by my comment is that the a9lh implemented in the main rxTools right now uses different files than the original branch, and I didn't replace that as I use an older version (the beta from 15th October I believe) where everything at the time worked. I was never interested in the tools stripped out version.

If you have a working a9lh-enabled unit and also able to launch rxTools, that is enough to test.
Older rxTools version can be easily backed up and restored with just folder renaming.

 

[Madridi]

If you have a working a9lh-enabled unit and also able to launch rxTools, that is enough to test.
Older rxTools version can be easily backed up and restored with just folder renaming.

Sure, I'll try that in a while, though I'm surely going have some problems with it due to missing firms or something. I don't remember what it requires anymore. I'll report my findings here

 

[Madridi]

@duke_srg
Just to follow up:
- Compiled rxtools (a9lh branch) from source
- Ran o3ds_cdn_firm.py (using o3ds here)
- Replaced the resulting 0004013800000002.bin with the one from a previous build that I had working (The resulting one was 2kb.. I think that's cause it's not in cdn anymore?)
- Placed rxtools folder and arm9haxloader.bin on root

Result:
- As soon as I turned it on, I get the data installation failed msg (expected, like I said before)
- 3 Options: X to launch sysnand, A to launch emunand, Y to launch pastamode
- Pressing Y freezes the 3ds. Hard reboot required
- Pressing A or X gives this msg: "Failed to load NATIVE_FIRM: 4 Reboot rxTools and try again."

I assume I am missing Native_Firm from my setup. But I'm not sure if that's the issue. Is there a specific firmware.bin that I should be posting inside rxtools/sys folder?

Hope that helps

Edit: I also would like to point out that while my emunand is on latest version (or 11.1 maybe), my sysnand is still on 9.2. So we have the added benefit on working with that