Homebrew [RELEASE] CtrBootManager/CtrBootManager9

[Billy Acuña]

I had some difficulties to initialise an ARM11 stub and I don't understand why: even the slightest operation makes the 3DS freeze.
Currently, I am working on some small projects for PS Vita (and I also play games a lot ).

Nice to see you again and too bad news you are losing interest into 3ds scene hope you somehow figure out how to implement ARM11 stub, this is by far my favorite boot manager.

 

[Kazuma77]

New version 2.5.2 is available!
https://github.com/OperationNT414C/CtrBootManager/releases/tag/2.5.2

Fix A9LH and B9S v1.0 crashes at load (since update v2.5.1)

Thanks for keeping this updated. Though the A9LH .bin seems to have issues with no-init builds, but it's no big deal. I have a copy that works. Anyway, I tried to compile the latest source, and (after a lengthy dependency chase I won't go into details about to keep this short) it didn't give me a .firm for some reason. Actually, it gave me an error at the "add_executable(loader" line until it hit me -- there's no "loader" folder. So I made a copy of the "chainloader" folder and renamed it to "loader" and it finally built a .bin file, but no .firm file was generated. What am I missing?

 

[OperationNT]

Hello @Kazuma77,
Actually, the ".firm" generation is not by default in the automatic build process (because I am not very good with CMake and I didn't take enough time to understand it). So I manually generate it from the ".bin" file using "firmtool":
https://github.com/TuxSH/firmtool
Currently, I don't stay in my home so I don't have my script under my eyes but I think the command looks like:
"firmtool build CtrBootManager9.firm -n 0x23F00000 -e 0 -D CtrBootManager9.bin -A 0x23F00000 -C NDMA"

 

[Kazuma77]

Hello @Kazuma77,
Actually, the ".firm" generation is not by default in the automatic build process (because I am not very good with CMake and I didn't take enough time to understand it). So I manually generate it from the ".bin" file using "firmtool":
https://github.com/TuxSH/firmtool
Currently, I don't stay in my home so I don't have my script under my eyes but I think the command looks like:
"firmtool build CtrBootManager9.firm -n 0x23F00000 -e 0 -D CtrBootManager9.bin -A 0x23F00000 -C NDMA"

That's pretty much the example for converting an A9LH payload from the firmtool "readme.md" file. It crossed my mind to try that. But it seems like no payload I convert that way ever works with Luma. I get nothing with the file I built. Just to test, I tried building the binary in the release to a .firm file and it gave a black screen as boot.firm, ran OK from BootCTR9, and crashed under Luma. If you're converting the .bin file, it would be extremely helpful just to know what that line is. I could finally create converted payloads that Luma doesn't crash with.

 

[urherenow]

That's pretty much the example for converting an A9LH payload from the firmtool "readme.md" file. It crossed my mind to try that. But it seems like no payload I convert that way ever works with Luma. I get nothing with the file I built. Just to test, I tried building the binary in the release to a .firm file and it gave a black screen as boot.firm, ran OK from BootCTR9

Are you sure you have the latest firmtool? IIRC, there was a version with a mistake in the crypto...

 

[Kazuma77]

Are you sure you have the latest firmtool? IIRC, there was a version with a mistake in the crypto...

Running firmtool with -v gives 1.2. Luma just doesn't support "-e 0" conversions at all. I think the Luma devs just don't want their chainloader to run Gateway. That's one payload their chainloader has never run right. It seems deliberate. For that matter, I think the changes in B9S 1.2 were an attempt to pull a "GW Fastboot" and break everything that wasn't Luma or GodMode9.

 

[urherenow]

I think the changes in B9S 1.2 were an attempt to pull a "GW Fastboot" and break everything that wasn't Luma or GodMode9.

Well, bootctr9 chainloads from Luma just fine, which in turn can load GW. Just takes like 1.5 seconds longer than if Luma could directly load GW
¯\_(ツ)_/¯

EDIT: wait... I keep forgetting who you are. Why you gotta use different user names

 

[OperationNT]

I just come back from holidays so I can give you my script:
"call firmtool.py build CtrBootManager9.firm -n 0x23F00000 -e 0 -D CtrBootManager9.bin -A 0x23F00000 -C NDMA -i"
I used firmtool version 1.1 to generate CtrBootManager9.firm version 2.5.2.

 

[Kazuma77]

I just come back from holidays so I can give you my script:
"call firmtool.py build CtrBootManager9.firm -n 0x23F00000 -e 0 -D CtrBootManager9.bin -A 0x23F00000 -C NDMA -i"
I used firmtool version 1.1 to generate CtrBootManager9.firm version 2.5.2.

OK, well, I can revert the version if I need to. That "-i" is different though so I'll try that first. Just looked it up in firmtool's help. It's for screen init. I'm doing a facepalm for not noticing this switch before. I think it's time to re-convert everything. Gateway might even run as boot.firm with that. Thanks.

 

[urherenow]

Gateway might even run as boot.firm with that. Thanks.

What?
Really!?

╿︡O͟-O︠╿

Now I can't wait to get home to my PC tomorrow to find out.

 

[Kazuma77]

What?
Really!?

╿︡O͟-O︠╿

Now I can't wait to get home to my PC tomorrow to find out.

Sorry if I got your hopes up for nothing. But it works well for this. And I learned something about firmtool in the process -- never use "-b" if you want it to boot. But given I can now have infinite copies of this, I could make it look like GW and other converted payloads are working normally. All I have to do is make copies of this that launch one payload each (granted, for GW to work with this trick, I have to make the payload it runs BootCTR9 and patch the .ini file it uses in memory). The resulting loaders will work with both hotkey chainloaders and GUI-based ones. They will be like having a "proper" payload in all the ways that matter.