It is just a message. Does not mean anything. Do not expect anything on 10.3View attachment 29730 explain to me why my n3ds at 10.3 on ironhax is running arm9 payload????
- Joined
- Aug 29, 2015
- Messages
- 2,114
- Trophies
- 0
- Age
- 26
- Location
- looking up at the stars
- Website
- steamcommunity.com
- XP
- 1,882
- Country
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????
- Joined
- Jan 7, 2014
- Messages
- 14,600
- Trophies
- 4
- Location
- Another World
- Website
- www.gbatemp.net
- XP
- 25,217
- Country
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.
@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.
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.
Last edited by d0k3,
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?
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).
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).
Last edited by 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:
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.
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.
Last edited by d0k3,
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.
Last edited by d0k3,
As for the release 'fix2' the bottom screen is always displayed and the boot rate is more than correct.Good to hear
I wanted to say good job as usual for all of your releases !
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.
. Let me know about your results if you test it.
Last edited by 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
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.thank you for this, will try it over the next couple of days
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
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.
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.
Similar threads
-
- Article
- No one is chatting at the moment.
