Homebrew [Release] Easily load payloads in HB Launcher via Brahma 2 mod

[Dean_]

View attachment 29730 explain to me why my n3ds at 10.3 on ironhax is running arm9 payload????

It is just a message. Does not mean anything. Do not expect anything on 10.3

 

[Yami_Industries]

It is just a message. Does not mean anything. Do not expect anything on 10.3

you're saying its just a glitch of somekind that arm9 is somehow running on my 3ds??? then why didn't it give me a fail message????

 

[Dean_]

you're saying its just a glitch of somekind that arm9 is somehow running on my 3ds??? then why didn't it give me a fail message????

Have you heard about false hope?

 

[VinsCool]

you're saying its just a glitch of somekind that arm9 is somehow running on my 3ds??? then why didn't it give me a fail message????

It's not running arm9 at all.

It fails to access arm11 exploit, which is requires to exploit arm9.
So basically, it's just a userland code unning, showing a failed message.

 

[d0k3]

@Everyone, I rebased this around my Brahma2Loader, which seems like the much better choice, as the Brahma2Loader was already designed to direct-boot payloads from the beginning. There is also a new feature, the Voodoo loader. For now, I still kept the old fix2 and fix5 downloads in the opening post, but it is recommended to update.

Note that there are now four parameters inside the XML <args> instead of the previous three. The fourth parameter is for the Voodoo loader. The Voodoo loader is called the way it is because no one (at this point) seems to know why the methods it implements do work (but they seem to do, almost a bit like magic). It takes a parameter from 0x0 to 0xF (0x0 means standard loading, 0xF means full voodoo). Depending on your ARM9 payload and your system, different values may work for you and experimentation is strongly recommended. The highest value is most likely not always the best. The last release before (fix5), f.e. does the same as the Voodoo loader with parameter 0xC - and that doesn't mean that 0xF is guaranteed to be better, but it may be. If you are lazy and just want a good value to use everywhere, I'd recommend 0x0 or 0xF, but I'd also like to hear what values you had success with if you are willing to experiment.

Also, the <executable> is now "/3DS/BrahmaLoader/BrahmaLoader.3dsx" instead of "/Brahma2/Brahma2.3DSX". You may move the executable somewhere else but you have to change it in your XML shortcuts as well, of course.

Looking forward to hear your opinions. Also note that the instructions in the opening post are now slightly changed.

 

[Shadowtrance]

Dammit, you can try compiling all you want, but no matter, there's still some dependency left somewhere... Know of a truly static version of smdhtool?

Pretty sure i shared a dll independent compiled version with you at some point. Forget where, might have been your theme preview tool thread i think?

 

[d0k3]

I've seen there have been a few downloads already, so, how is the mileage for thse users that are already using Brahma2Loader instead of Brahma2? Anyone tried around with the voodoo loader parameter? I myself have tried around for a bit and get very good boot rates for ReiNAND (in fact, 100% so far) with voodoo 0xF, but it looks like Decrypt9 fares better with a different paramter, that I still have to find out.

BTW, if you want to understand the voodoo launcher paramter better, it is actually processed in binary (0b1111 = 0xF = 15). Starting from the right, this is what those bits do (and of course you can combine this three fixes, this is what is intended).

• Bit 0: Load (unnecessary) HB services. 0b0001/0x1 => Load them.
• Bit 1: "Magic Fix" no one (might not be absolutely correct) knows what it does, but CTR Boot Manager, BootCTR and HBL itself all use it. 0b0010/0x2 => Use magic fix.
• Bit 2 and Bit 3: length of the bootfix delay (0b0000/0x0 => 0; 0b0100/0x4 => 50; 0b1000/0x8 => 100; 0b1100/0xC = 150).

 

[FONZD]

About Brahma2Loader_XML_release

After some tests I have the best results for rxTools with this arg: <arg>/rxtools/sys/code.bin 0x12000 0x10000 0x8</arg> (boot rate without pb 5/10)

FYI with version 'fix2', the bottom screen is still displayed, the top screen is displayed in about 80% of cases... (<arg>/rxtools/sys/code.bin 0x12000 0x10000</arg>)

So I prefer to keep this version:

 

[d0k3]

About Brahma2Loader_XML_release

After some tests I have the best results for rxTools with this arg: <arg>/rxtools/sys/code.bin 0x12000 0x10000 0x8</arg> (boot rate without pb 5/10)

FYI with version 'fix2', the bottom screen is still displayed, the top screen is displayed in about 80% of cases... (<arg>/rxtools/sys/code.bin 0x12000 0x10000</arg>)

So I prefer to keep this version:

Thanks a ton! Well, fix2 intitialized text output, then deinitialized it and set the screenmode correct before going on - that's the one difference. As you see, that still leads to garbled output at times, so I didn't even include it in the voodoo_load() function. I'll see about including that back in now, of course.

 

[d0k3]

About Brahma2Loader_XML_release

After some tests I have the best results for rxTools with this arg: <arg>/rxtools/sys/code.bin 0x12000 0x10000 0x8</arg> (boot rate without pb 5/10)

FYI with version 'fix2', the bottom screen is still displayed, the top screen is displayed in about 80% of cases... (<arg>/rxtools/sys/code.bin 0x12000 0x10000</arg>)

So I prefer to keep this version:

Alright, I made a new release (see opening post). Now, the VOODOO parameter is between 0x00 and 0x1F, the additional bit controls wether the console is initialized or not. Should have the exact same result as the earlier 'fix2' version.

Here, the updated description of what the voodoo parameter does:
It is actually processed in binary (0b11111 = 0x1F = 31). Starting from the right, this is what those bits do (and of course you can combine these four fixes, this is what is intended).

• Bit 0: Load (unnecessary) HB services. 0b00001/0x01 => Load them.
• Bit 1: "Magic Fix", no one (might not be absolutely correct) knows what it does, but CTR Boot Manager, BootCTR and HBL itself all use it. 0b00010/0x02 => Use magic fix.
• Bit 2 and Bit 3: length of the bootfix delay (0b0000/0x0 => 0; 0b00100/0x04 => 50; 0b01000/0x08 => 100; 0b01100/0x0C = 150).
• Bit 4: Initialize console and print some nonsense text. 0b10000/0x10 => Use this fix.

 

[FONZD]

Alright, I made a new release (see opening post). Now, the VOODOO parameter is between 0x00 and 0x1F, the additional bit controls wether the console is initialized or not. Should have the exact same result as the earlier 'fix2' version.

Here, the updated description of what the voodoo parameter does:
It is actually processed in binary (0b11111 = 0x1F = 31). Starting from the right, this is what those bits do (and of course you can combine these four fixes, this is what is intended).

• Bit 0: Load (unnecessary) HB services. 0b00001/0x01 => Load them.
• Bit 1: "Magic Fix", no one (might not be absolutely correct) knows what it does, but CTR Boot Manager, BootCTR and HBL itself all use it. 0b00010/0x02 => Use magic fix.
• Bit 2 and Bit 3: length of the bootfix delay (0b0000/0x0 => 0; 0b00100/0x04 => 50; 0b01000/0x08 => 100; 0b01100/0x0C = 150).
• Bit 4: Initialize console and print some nonsense text. 0b10000/0x10 => Use this fix.

THX !

I use this for rxTools: <arg>/rxtools/sys/code.bin 0x12000 0x10000 0x1A</arg>

with a good boot rate (8/10)

 

[d0k3]

THX !

I use this for rxTools: <arg>/rxtools/sys/code.bin 0x12000 0x10000 0x1A</arg>

with a good boot rate (8/10)

Good to hear . There are no problems like garbled output now, correct? And we still haven't reached the boot rate possible by other means (10/10, if I got that correct)? Maybe loading HBL (which is heavyweight compared to the likes of CBM or BootCTR) automagically reduces the success rate and not much can be done about it. Still unsure.

 

[FONZD]

Good to hear . There are no problems like garbled output now, correct? And we still haven't reached the boot rate possible by other means (10/10, if I got that correct)? Maybe loading HBL (which is heavyweight compared to the likes of CBM or BootCTR) automagically reduces the success rate and not much can be done about it. Still unsure.

As for the release 'fix2' the bottom screen is always displayed and the boot rate is more than correct.

I wanted to say good job as usual for all of your releases !

 

[d0k3]

Everyone, I just uploaded a new release (check the opening post). This contains the system stabilty / bootrate fix by @173210 and should greatly improve boot rates on N3DS. Maybe it will even make parts of the voodoo loader unnecessary. It might also help on O3DS, but I don't know yet. Experimentation needed . Let me know about your results if you test it.

 

[peteruk]

Everyone, I just uploaded a new release (check the opening post). This contains the system stabilty / bootrate fix by @173210 and should greatly improve boot rates on N3DS. Maybe it will even make parts of the voodoo loader unnecessary. It might also help on O3DS, but I don't know yet. Experimentation needed . Let me know about your results if you test it.

thank you for this, will try it over the next couple of days

 

[d0k3]

thank you for this, will try it over the next couple of days

Let me know how it works for you! For me, I just tested it with ReiNAND CFW, 10/10 boots without problems (voodoo parameter 0xF). Before it was around 8/10. Your mileage may vary and I might have been lucky, but I think that fix really helped.

 

[peteruk]

Let me know how it works for you! For me, I just tested it with ReiNAND CFW, 10/10 boots without problems (voodoo parameter 0xF). Before it was around 8/10. Your mileage may vary and I might have been lucky, but I think that fix really helped.

Ok will report back as soon as i can, am trying to help a relative with his new O3DS atm and it's taking up my time, but will report back ASAP

 

[FONZD]

Let me know how it works for you! For me, I just tested it with ReiNAND CFW, 10/10 boots without problems (voodoo parameter 0xF). Before it was around 8/10. Your mileage may vary and I might have been lucky, but I think that fix really helped.

N3DS - boots 10/10 wirth rxtools (voodoo parameter 0x1A)
2/10 without top screen & 8/10 without problems

 

[d0k3]

N3DS - boots 10/10 wirth rxtools (voodoo parameter 0x1A)
2/10 without top screen & 8/10 without problems

If problems persist only with the top screen, I can extend the consolefix (voodoo bit 0b10000) to the topscreen. Let me try that, new release coming up.

 

[d0k3]

N3DS - boots 10/10 wirth rxtools (voodoo parameter 0x1A)
2/10 without top screen & 8/10 without problems

Alright, check the opening post. The newest release extends the consolefix to the top screen. This might not do anything useful, but it may also solve your problems with rxTools not showing anything on there.