I tried it and it didn't work :/Gateway firm payload if no one did convert it yet
edit:I got it working it turns out my Cart slot is not reading my gateway at all times
Last edited by BADDINOROX99,
I tried it and it didn't work :/Gateway firm payload if no one did convert it yet
Windows users (at least on python 2.7) need to prefix commands with "python". For example, after installing the firmtool module, the command to convert gateway.bin would be:WARNING: I am not responsible for any damage to any devices.
Anyway, so head on over to https://github.com/TuxSH/firmtool.git
Download the firmtool file
Scroll down to "Building a firmware binary from an arm9loaderhax.bin payload "
Copy the code "firmtool build test.firm -n 0x23F00000 -e 0 -D arm9loaderhax.bin -A 0x23F00000 -C NDMA"
Run that but replace the arm9loaderhax.bin with the payload of your choice
For me on windows 10, python won't recognize as a command even after added to path. What did work was instead using firmtool.py in that command instead of python firmtool or just firmtoolWindows users (at least on python 2.7) need to prefix commands with "python". For example, after installing the firmtool module, the command to convert gateway.bin would be:
python firmtool build test.firm -n [emoji354]0000 -e 0 -D gateway.bin -A [emoji354]0000 -C NDMA
Thank you @TuxSH!!!
edit: but I end up with different hashes on the resulting .firm than what is posted above. I'll have to try both real quick...
and... neither of them boot gateway from my o3ds
Yeah someone here already said that Luma was converted using an .elf, not an arm9.bin. So it seems like that's how you have to convert them to get them to work. I don't think anyone has tried it yet. I would if I could find .elf files for these things, but I don't even use Gateway and my setup works perfectly fine sans my poor boot animations Lol.Windows users (at least on python 2.7) need to prefix commands with "python". For example, after installing the firmtool module, the command to convert gateway.bin would be:
python firmtool build test.firm -n 0x23F00000 -e 0 -D gateway.bin -A 0x23F00000 -C NDMA
Thank you @TuxSH!!!
edit: but I end up with different hashes on the resulting .firm than what is posted above. I'll have to try both real quick...
and... neither of them boot gateway from my o3ds
I'm on windows 10. You did something wrong. Read over the environment setup in my sig for rxtools (it applies to almost everything 3ds)For me on windows 10, python won't recognize as a command even after added to path. What did work was instead using firmtool.py in that command instead of python firmtool or just firmtool
Yeah but AFAIK they don't work when loading CFW .bin payloads, only homebrew payloads like D0k3 tools........ Don't most people use bootmanagers to dual boot their sig patchers?For the lazy kiddies, if you convert a chainloader (like bootctr9) to b9s, you are able to load some a9lh .bins.
Trust me, I didn't. I'm not some noob, I am an IT professional with experience in programming as well, and I have set up python numerous times on other computers.I'm on windows 10. You did something wrong. Read over the environment setup in my sig for rxtools (it applies to almost everything 3ds)
Most of the things that properly runs that way (not everything will work in my experience) can simply be converted to .firm anyway so why even botherFor the lazy kiddies, if you convert a chainloader (like bootctr9) to b9s, you are able to load some a9lh .bins.
Maybe running "Python install setup.py" again would fix that weird variable issue?Trust me, I didn't. I'm not some noob, I am an IT professional with experience in programming as well, and I have set up python numerous times on other computers.
Maybe. To be fair i didn't even bother with the basics of restarting the pc. It was late last night and I didn't have the time to troubleshoot as I had work in the morning. Haven't looked at it yetMaybe running "Python install setup.py" again would fix that weird variable issue?
Well we all know electronics in general have a mind of their own Lol. Not like it's a huge deal either way if the CMD recognizes the input anyway.Maybe. To be fair i didn't even bother with the basics of restarting the pc. It was late last night and I didn't have the time to troubleshoot as I had work in the morning. Haven't looked at it yet
I hate when people say "the computer only does what you tell it to do". As someone who works with broken computers on regular basis I'll have to say that is false.Well we all know electronics in general have a mind of their own Lol. Not like it's a huge deal either way if the CMD recognizes the input anyway.
Lol I always think it's funny when I tell people to turn it off and on again and they think I'm joking. Like no, that literally fixes 75% of problems not caused by hardware...... There is a reason that meme exists.I hate when people say "the computer only does what you tell it to do". As someone who works with broken computers on regular basis I'll have to say that is false.
So what? You are not infallible (and neither is the software or your system). I'm on Windows 10 and It works for me.Trust me, I didn't. I'm not some noob, I am an IT professional with experience in programming as well, and I have set up python numerous times on other computers.
Literally the only thing I need from the rxtools compiling guide is Python, and according to that guide it's as easy as installing python and adding the path to environment variables. Just triple checked and yes that is all set up properly. So unless you have some other additional steps to add, I've done everything properly on my end.So what? You are not infallible (and neither is the software or your system). I'm on Windows 10 and It works for me.
And when you do repeated tasks on multiple systems, complacency always comes around to bite you in the ass. And in this case (bragging about how "I'm a professional..." it makes you LOOK like an ass.
But it really IS that simple. If you open cmd, type "python" and hit enter, it should not say it is not a recognized command if it is in your path. It should sayLiterally the only thing I need from the rxtools compiling guide is Python, and according to that guide it's as easy as installing python and adding the path to environment variables. Just triple checked and yes that is all set up properly. So unless you have some other additional steps to add, I've done everything properly on my end.
If python was not set up properly in path even my modified command of firmtool.py wouldn't work.
--------------------- MERGED ---------------------------
Just to see I'll try reinstalling python. Maybe it didn't install correctly somehow
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
Just as I said, I did everything perfectly, including path. Python was just somehow borked during install. Removing and reinstalling fixed the issue. Now if you would please stop assuming I had somehow made a mistake or don't know what I'm doing that would be great. Trust me I know how to add a simple path in environment variables, I've done much more difficult CLI stuff with cisco networking devices. I'll always be first to admit I don't know what I'm doing, but something as easy as python setup is not difficult.But it really IS that simple. If you open cmd, type "python" and hit enter, it should not say it is not a recognized command if it is in your path. It should say
Code:Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>>
I have python 2.7.something installed to C:\Python27
Near the top of my environment, I have both "C:\Python27\" and "C:\Python27\Scripts" in my path.
is your path entry near the top or is it after a path with spaces (such as after a "Program Files" entry). Not that it SHOULD matter today, but it might. It was made to be cross platform, and *nix systems don't play nice with spaces in paths...