Homebrew ARM9Loader -- Technical Details and Discussion

  • Thread starter Thread starter Selver
  • Start date Start date
  • Views Views 572,566
  • Replies Replies 4,025
  • Likes Likes 42
why are people using sysnand now with the arm9loaderhax?
is not better to continue using emunand? we don't have risks using sysnand anymore?
there are vantages using sysnand that worth the risk?
I'm very confused
 
  • Like
Reactions: Boogieboo6
Same result, both screens are black, pressing A does nothing
Alright, I thought the last case of this was isolated (I changed some things, it worked, changed everything back and it still worked, then the original binary was working fine, so I thought it was just the tester) use the stage0x5C000.bin from the last zip and try the attached file renamed so it doesn't have the .txt extension on it (and named arm9loaderhax ofc)

--------------------- MERGED ---------------------------

why are people using sysnand now with the arm9loaderhax?
is not better to continue using emunand? we don't have risks using sysnand anymore?
there are vantages using sysnand that worth the risk?
I'm very confused
Well, sysNAND solves a lot of the emuNAND problems (twl things not working sometimes, GBA VC installation only once, etc.) I keep my emuNAND, however I have my sysNAND at 10.6 and my emuNAND at 9.2 since sometimes 9.2 comes in handy (for launching certain arm9 payloads, though that's slowly going away)
 

Attachments

Last edited by dark_samus3,
I apologise if this has been explained already, but what does "screen init" refer to in the context of arm9loader? I know that it stands for "screen initialisation", but people seem to refer to another build of arm9loaderhax that makes use of screen init or something.
 
I apologise if this has been explained already, but what does "screen init" refer to in the context of arm9loader? I know that it stands for "screen initialisation", but people seem to refer to another build of arm9loaderhax that makes use of screen init or something.
Originally we couldn't turn on the screen before the firmware was loaded. This prevented us from using things like bootloaders and recovery tools. This was fixed later on.
 
Sounds awesome!

Edit: But... the falling back to nand part... how is this done when all of this happens before keys are even initted? Or do you know how to init the keys now? So... decrypt9 will be able to do ALL of its functions when booting from a9lh?
Just saw this edit, we aren't talking about Decrypt9 at all, we're talking about the recovery payload, and since it will be plaintext in NAND there's no need to do anything but read it, which is as easy as "sdmmc_read_sectors(memloc, NAND_loc, size)" (memloc and NAND_loc being the memory address where we temporarily store what's read and the address of the sector in NAND where we read it from) so it's relatively simple :)
 
Last edited by dark_samus3,
@dark_samus3 Sorry for asking this, but I've been out of the loop for a bit. The 3ds scene is moving way too fast :ha:. So far, I've compiled the a9lh from last month (right after revision 2.1 came out) and I've added stage 2 to my 3ds. Am I missing anything atm? Isn't there something new with using the 3ds without the sd card or am I just imagining stuff right now?
 
@dark_samus3 Sorry for asking this, but I've been out of the loop for a bit. The 3ds scene is moving way too fast :ha:. So far, I've compiled the a9lh from last month (right after revision 2.1 came out) and I've added stage 2 to my 3ds. Am I missing anything atm? Isn't there something new with using the 3ds without the sd card or am I just imagining stuff right now?
Nothing that matters too much... All that's really missing is the no SD card detection fix, which means your console will power off when you don't have an SD card inserted, just like when you don't have an arm9loaderhax.bin file... I'd recommend waiting for the recovery update, when it becomes available
 
why haven't I been able to find a comprehensive tutorial for this yet? It seems like the OP in this thread just threw a bunch of info out there and now everyone suddenly knows how to do everything with this. Honestly, with and O3ds, I'm a little worried about downgrading AGAIN and losing what I have already if it fails. Everything I've searched for just returns more info on technicalities or solving people's issues with it.
 
Nothing that matters too much... All that's really missing is the no SD card detection fix, which means your console will power off when you don't have an SD card inserted, just like when you don't have an arm9loaderhax.bin file... I'd recommend waiting for the recovery update, when it becomes available

It wasn't so much the sd thing that made me want to do a full update from your repository but rather this commit;
switch back to just python

Suggests to me that this recent commit may result in cleaner code as opposed to what I had installed before; a stage 1 by delebile and a stage 2 by darksamus.
 
Last edited by democracy,
why haven't I been able to find a comprehensive tutorial for this yet? It seems like the OP in this thread just threw a bunch of info out there and now everyone suddenly knows how to do everything with this. Honestly, with and O3ds, I'm a little worried about downgrading AGAIN and losing what I have already if it fails. Everything I've searched for just returns more info on technicalities or solving people's issues with it.
https://github.com/Plailect/Guide/wiki/OTP-Info
 
  • Like
Reactions: peteruk
2 questions:
1. I saw some New3ds files referenced on the main github page for a9lh, I don't need them with an O3ds, right?
2. wait, SO I'M DOWNGRADING EMUNAND? (thats some relief, but it still scares me a bit having to image it to sysnand.)
1. Last sentence states "These steps are unneeded on an Old 3DS."
2. Yes.
 
  • Like
Reactions: peteruk
that was just a mistake, the patch I got from the previous annon contrib. changed it to python2 and a bunch of people were complaining, so I switched back

Thanks for clarifying. Just one more question :) are the Arm9 gurus such as yourself, in your programming, wiping firm1 and firm0 before writing new files to it? Or should we be restoring nand before a new flash to avoid having residual files left in firm0 and firm1?

And by the way, thank you again to you and your team for sharing your talent with us :)
 
Last edited by democracy,

Site & Scene News

Popular threads in this forum