Homebrew ARM9Loader -- Technical Details and Discussion

[peteruk]

I will try to add screeninit to my arm9 bootloader, together with some additional configuration(like start this without screen, start this with screen init), after they released the screen init source. Also I will try to fix the bugs some people have while using my bootloader(atm its hard to debug the most stuff, because the only way to debug it is to log everything to a file, but this way its not possible to debug file opening problems)

Sounds great thank you, will this be purely a CFW selector or do you have something extra in mind ?

 

[RednaxelaNnamtra]

Sounds great thank you, will this be purely a CFW selector or do you have something extra in mind ?

The first thing would be to get it work on every device, after this I will think about other possible features.

 

[dkabot]

I will try to add screeninit to my arm9 bootloader, together with some additional configuration(like start this without screen, start this with screen init), after they released the screen init source. Also I will try to fix the bugs some people have while using my bootloader(atm its hard to debug the most stuff, because the only way to debug it is to log everything to a file, but this way its not possible to debug file opening problems)

Last I heard, screen init was going to be a patch for A9LH itself, with screen deinit handled by payloads before firmlaunching.

 

[peteruk]

Last I heard, screen init was going to be a patch for A9LH itself, with screen deinit handled by payloads before firmlaunching.

I read the same thing

 

[Supster131]

Last I heard, screen init was going to be a patch for A9LH itself, with screen deinit handled by payloads before firmlaunching.

Is that already confirmed?
If so, I may consider updating to the new version. Only reason I wasn't going to update was because I didn't want "broken" 3D.

 

[peteruk]

Is that already confirmed?
If so, I may consider updating to the new version. Only reason I wasn't going to update was because I didn't want "broken" 3D.

Bilis confirmed the fix

 

[dkabot]

Is that already confirmed?
If so, I may consider updating to the new version. Only reason I wasn't going to update was because I didn't want "broken" 3D.

I think dark_samus is working on an updater that doesn't suck or something along those lines.
Deinit is very confirmed, there's a test build of cakes with it and 3D bug is gone alongside having a menu you can see/use.

 

[daxtsu]

Is that already confirmed?
If so, I may consider updating to the new version. Only reason I wasn't going to update was because I didn't want "broken" 3D.

The bug vanishes as long as the payload turns the screens off, so you can expect all of the CFWs to be turning the screens off after showing their menus/splash screens soon.

 

[Supster131]

I think dark_samus is working on an updater that doesn't suck or something along those lines.
Deinit is very confirmed, there's a test build of cakes with it and 3D bug is gone alongside having a menu you can see/use.

Let's hope it works smoothly with (Au)ReiNand.

The bug vanishes as long as the payload turns the screens off, so you can expect all of the CFWs to be turning the screens off after showing their menus/splash screens soon.

I wouldn't notice I no longer use a splash screen.

Do we have any info on boot times or how fast Decrypt9 boots up?

 

[daxtsu]

Do we have any info on boot times or how fast Decrypt9 boots up?

No clue about D9, but when I was testing Cakes earlier, I noticed no difference with screen init vs not having it.

 

[peteruk]

No clue about D9, but when I was testing Cakes earlier, I noticed no difference with screen init vs not having it.

Do you know if they managed to get around the D9 decryption/encryption problems at boot yet ? Or is it purely being used as a recovery mode ?

 

[Supster131]

No clue about D9, but when I was testing Cakes earlier, I noticed no difference with screen init vs not having it.

Great to know! Hopefully this can be released by the time I get out of school.

 

[Mrrraou]

Do you know if they managed to get around the D9 decryption/encryption problems at boot yet ? Or is it purely being used as a recovery mode ?

The reason why D9 fails at boot at the moment is because keys aren't set. It's not done yet, and D9 will mainly be used for recovery, I guess.

 

[daxtsu]

Great to know! Hopefully this can be released by the time I get out of school.

Cakes does boot a little slower than ARN anyway (for me anyway), about 2 seconds slower, but big deal.

 

[peteruk]

The reason why D9 fails at boot at the moment is because keys aren't set. It's not done yet, and D9 will mainly be used for recovery, I guess.

thank you for the reply

 

[Supster131]

The reason why D9 fails at boot at the moment is because keys aren't set. It's not done yet, and D9 will mainly be used for recovery, I guess.

So all we can do is backup and restore the NAND in its entirety, right? If so, that's good enough.

Cakes does boot a little slower than ARN anyway (for me anyway), about 2 seconds slower, but big deal.

2 seconds? No big deal. Still way better than menuhax

 

[Mrrraou]

So all we can do is backup and restore the NAND in its entirety, right? If so, that's good enough.

You can backup and restore partitions, too. (they will be encrypted, however)

 

[Supster131]

You can backup and restore partitions, too. (they will be encrypted, however)

Sorry, I don't know what that means. What does this mean to the end-user? What's the difference between a decrypted partition/NAND and an encrypted partition/NAND?

 

[peteruk]

I have a question for Dax or Mrraou please

Obviously we have the arm9loaderhax.bin payload on our cards atm, this will obviously need to be replaced with a new payload

Do we know what the process will be to do this ?

Will we have to compile another .3dsx and let it change the nand OR will it simply be swapping out the payload file ?

Hope I explained my question ok

 

[Mrrraou]

Sorry, I don't know what that means. What does this mean to the end-user? What's the difference between a decrypted partition/NAND and an encrypted partition/NAND?

Summed up: Decrypted partition => readable and "modifiable", has to be reencypted to reinject
Encrypted partition => not modifiable, but can be dumped anyway and reinjected

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

I have a question for Dax or Mrraou please

Obviously we have the arm9loaderhax.bin payload on our cards atm, this will obviously need to be replaced with a new payload

Do we know what the process will be to do this ?

Will we have to compile another .3dsx and let it change the nand OR will it simply be swapping out the payload file ?

Hope I explained my question ok

The arm9loaderhax.bin is your CFW.
There is a payload on NAND too. This one will need to be updated. Updaters will be given for this. You won't need to compile them if you already have a9lhax installed.