Homebrew Official [Release] EmuNAND9 - Open Source EmuNAND Formatter & Manager

[d0k3]

I tried to apply the same modification to BrahmaLoader, and it fails to run. I also tried to edit the AppInfo with that modification, no success.
Seems like a BrahmaLoader issue to me.

The voodoo parameter... try to set it to zero. If you do so, it should work exactly as Brahma 2 does. (that parameter is in resources/BrahmaAppInfo)

 

[Mrrraou]

So, I was able to do a working Decrypt9 CIA, here are the steps to do it:

1. Copy source/brahma.c from delebile's Brahma2 to BrahmaLoader/source/brahma.c (replace it)
2. Edit BrahmaLoader/source/brahma.c and replace the firm_reboot(void) function by this:
   

   s32 firm_reboot (void) {
           s32 fail_stage = 0;
   
           fail_stage++; /* platform or firmware not supported, ARM11 exploit failure */
           if (setup_exploit_data()) {
                   fail_stage += 2; /* Firmlaunch failure, ARM9 exploit failure*/
                   svcBackdoor(priv_firm_reboot);
           }
   
           /* we do not intend to return ... */
           return fail_stage;
   }

3. In BrahmaLoader/source/main.c, replace all occurences for load_arm9_payload to load_arm9_payload_offset
4. In BrahmaLoader/Makefile, remove the line

          @rm -fr $(OUTPUT).elf

5. Run

   make brahma

6. Build your CIA using BrahmaLoader/output/<project name>.elf

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

The voodoo parameter... try to set it to zero. If you do so, it should work exactly as Brahma 2 does. (that parameter is in resources/BrahmaAppInfo)

I will test that.

 

[d0k3]

So, I was able to do a working Decrypt9 CIA, here are the steps to do it:

1. Copy source/brahma.c from delebile's Brahma2 to BrahmaLoader/source/brahma.c (replace it)
2. Edit BrahmaLoader/source/brahma.c and replace the firm_reboot(void) function by this:
   

   s32 firm_reboot (void) {
           s32 fail_stage = 0;
   
           fail_stage++; /* platform or firmware not supported, ARM11 exploit failure */
           if (setup_exploit_data()) {
                   fail_stage += 2; /* Firmlaunch failure, ARM9 exploit failure*/
                   svcBackdoor(priv_firm_reboot);
           }
   
           /* we do not intend to return ... */
           return fail_stage;
   }

3. In BrahmaLoader/source/main.c, replace all occurences for load_arm9_payload to load_arm9_payload_offset
4. In BrahmaLoader/Makefile, remove the line

          @rm -fr $(OUTPUT).elf

5. Run

   make brahma

6. Build your CIA using BrahmaLoader/output/<project name>.elf

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


I will test that.

If it worked the way you described it, the voodoo parameter might not be problem. It is pretty strange this works, though, and it does not work with the old brahma.c. brahma.c, apart from some slight implementation differences is identical between BrahmaLoader, CakeBrah and Brahma II. With that one change you described above, it should work in all three.

 

[Mrrraou]

If it worked the way you described it, the voodoo parameter might not be problem. It is pretty strange this works, though, and it does not work with the old brahma.c. brahma.c, apart from some slight implementation differences is identical between BrahmaLoader, CakeBrah and Brahma II. With that one change you described above, it should work in all three.

Indeed, changing the Voodoo parameter doesn't fix anything.

 

[Arizato]

EDIT: Fixed it myself. I was stupid. Copied the files before I started the emuNAND resulting in database confusions. Fixed it by redoing the whole process and rebuilding my .db files before I actually copied the content back to the card.

Seems I managed to fuck something up. Decided to use this to reformat my SD card because rxtools keeps freezing. Made sysNAND as well as emuNAND backups just in case and decided to format the card. rxtools works great now, but when I restored my emunand from file in Emunand9 I can't see my installed CIAs and games in emuNAND mode anymore, even though I copied everything back. I tried to change the theme and now the emuNAND tells me that my add on database is corrupted.

What are my options now? Can I restore all my stuff without having to redownload it?

 

[d0k3]

EDIT: Fixed it myself. I was stupid. Copied the files before I started the emuNAND resulting in database confusions. Fixed it by redoing the whole process and rebuilding my .db files before I actually copied the content back to the card.

Seems I managed to fuck something up. Decided to use this to reformat my SD card because rxtools keeps freezing. Made sysNAND as well as emuNAND backups just in case and decided to format the card. rxtools works great now, but when I restored my emunand from file in Emunand9 I can't see my installed CIAs and games in emuNAND mode anymore, even though I copied everything back. I tried to change the theme and now the emuNAND tells me that my add on database is corrupted.

What are my options now? Can I restore all my stuff without having to redownload it?

Normally you should actually copy the files before starting the EmuNAND (actually, before even starting the SysNAND is best). Problem here is the <id1> in Nintendo 3DS/<id0>/<id1>. While the <id0> is dependant on your current 3DS setup (meaning: this will stay constant when you restore a backup), the <id1> is somewhat random and if it (the <id1> folder) does not already exist, a new one is created. You'd have to copy your stuff into Nintendo 3DS/<old_id0>/<new_id1> then to fix the situation. Or you would just start from Nintendo 3DS/<old_id0>/<old_id1> if you have not started the EmuNAND yet.

 

[MelonGx]

@d0k3

Do you remember the "rare 2DS which has 1.21GB NAND size"?
Unfortunately, the recently released JPN Pokemon RGBY exclusive 2DSes are in that case.

Those 1.21GB NAND size 2DSes's emuNAND can only be formatted in 1.21GB / 2GB legacy.
But GW / rxTools / other CFWs are not intelligent enough to recognize that "O3DS/2DS with emuNAND over 1GB" properly.

3 month ago, a GBATemp member gave a worked solution about this:
1) Borrow an O3DS
2) Format 1GB legacy emuNAND on that O3DS
3) Force injecting 1.21GB 2DS NAND/emuNAND backup to that 1GB legacy emuNAND partition with emuNANDTool 1.0.3

So.....
I don't know whether current emuNAND9 version can force formatting 1GB emuNAND partition for O3DS/2DS or not.
If it can, then this problem is already resolved.
If it cannot, I would like it to be added on next version.
Thanks for reading this article.

 

[d0k3]

@d0k3

Do you remember the "rare 2DS which has 1.21GB NAND size"?
Unfortunately, the recently released JPN Pokemon RGBY exclusive 2DSes are in that case.

Those 1.21GB NAND size 2DSes's emuNAND can only be formatted in 1.21GB / 2GB legacy.
But GW / rxTools / other CFWs are not intelligent enough to recognize that "O3DS/2DS with emuNAND over 1GB" properly.

3 month ago, a GBATemp member gave a worked solution about this:
1) Borrow an O3DS
2) Format 1GB legacy emuNAND on that O3DS
3) Force injecting 1.21GB 2DS NAND/emuNAND backup to that 1GB legacy emuNAND partition with emuNANDTool 1.0.3

So.....
I don't know whether current emuNAND9 version can force formatting 1GB emuNAND partition for O3DS/2DS or not.
If it can, then this problem is already resolved.
If it cannot, I would like it to be added on next version.
Thanks for reading this article.

This might be more complicated than you think... See, for EmuNANDs, the actual EmuNAND header follows after the full NAND chip size. In your case, the EmuNAND header would be at ~1.21GB on the SD card. Now, if your EmuNAND is only 1GB in size, it is missing the EmuNAND header. For that reason, I highly doubt that the solution you provided above will work, especially if CFWs don't accept the 1.21GB / 2GB EmuNAND size.

For GW, I have already given up hope. All flashy new features (when they feel like it) and never fixing any existing bugs. You should bring up that issue in the CakesFW / rxTools / other CFW threads, though. These have to work with the >= 1.21GB sized EmuNAND, there is no reason why they should not.

if I'm wrong and your solution actually works... can you point me to some proof (ie. users who have already tried it and could provide more information).

 

[MelonGx]

This might be more complicated than you think... See, for EmuNANDs, the actual EmuNAND header follows after the full NAND chip size. In your case, the EmuNAND header would be at ~1.21GB on the SD card. Now, if your EmuNAND is only 1GB in size, it is missing the EmuNAND header. For that reason, I highly doubt that the solution you provided above will work, especially if CFWs don't accept the 1.21GB / 2GB EmuNAND size.

For GW, I have already given up hope. All flashy new features (when they feel like it) and never fixing any existing bugs. You should bring up that issue in the CakesFW / rxTools / other CFW threads, though. These have to work with the >= 1.21GB sized EmuNAND.

if I'm wrong and your solution actually works... can you point me to some proof (ie. users who have already tried it and could provide more information).

I'm asking one of those 2DS owners to try that force-injecting-1.21GB-on-1GB-partition method.
Maybe the result will come out in 24 hrs.

 

[d0k3]

I'm asking one of those 2DS owners to try that force-injecting-1.21GB-on-1GB-partition method.
Maybe the result will come out in 24 hrs.

Alright! Also let them try if the 1.21GB / 2GB EmuNAND size works, if they haven't already tried.

 

[MelonGx]

Alright! Also let them try if the 1.21GB / 2GB EmuNAND size works, if they haven't already tried.

2GB emuNAND partition has been proved not work.
Already told him to try 1.21GB. Now waiting for the result.....

 

[d0k3]

2GB emuNAND partition has been proved not work.
Already told him to try 1.21GB. Now waiting for the result.....

One thing that won't work almost for sure with that is Multi EmuNAND on CakesFW, but that problem is by design in Multi EmuNAND Creator and CakesFW. Maybe ask the respective authors?

 

[MelonGx]

@d0k3
Bad news - Force-injecting-1.21GB-to-1GB-partition method failed.
Currently there are no way to launch that case's rare 2DS emuNAND.
So no need to add force-formatting-1GB function on emuNAND9 anymore.
Thanks for watching this reply.

 

[d0k3]

@d0k3
Bad news - Force-injecting-1.21GB-to-1GB-partition method failed.
Currently there are no way to launch that case's rare 2DS emuNAND.
So no need to add force-formatting-1GB function on emuNAND9 anymore.
Thanks for watching this reply.

Well, I told you.... that problem is in CFWs, not in EmuNAND9.

 

[MelonGx]

Well, I told you.... that problem is in CFWs, not in EmuNAND9.

I know that.
I was thinking if the 1GB method worked then adding a force-formatting-1GB function on emuNAND9 would help that rare 2DS case.
Now no need to add it because it doesn't work.

 

[MelonGx]

@d0k3
I found the successful case.
http://gbatemp.net/threads/release-...olkit-fw-2-0-9-2.382782/page-357#post-5580703
He used an old version (earlier than Jul.19 2015) Decrypt9 to create a 943MB NAND backup from his "1.21GB" 2DS.
I don't know if it's that
- Old version of Decrypt9 can force generating 943MB NAND size from real 1.21GB NAND
or
- That 2DS NAND is a fake 1.21GB and actually it's 943MB, only GW Launcher misrecognized it
@thaikhoa
I need your help.
If you have spare time, please perform a NAND backup with current version of EmuNAND9 and Decrypt9WIP on that "1.21GB" 2DS, to see the NAND backup size.
Thanks.

 

[dark_samus3]

@d0k3
I found the successful case.
http://gbatemp.net/threads/release-...olkit-fw-2-0-9-2.382782/page-357#post-5580703
He used an old version (earlier than Jul.19 2015) Decrypt9 to create a 943MB NAND backup from his "1.21GB" 2DS.
I don't know if it's that
- Old version of Decrypt9 can force generating 943MB NAND size from real 1.21GB NAND
or
- That 2DS NAND is a fake 1.21GB and actually it's 943MB, only GW Launcher misrecognized it
@thaikhoa
I need your help.
If you have spare time, please perform a NAND backup with current version of EmuNAND9 and Decrypt9WIP on that "1.21GB" 2DS, to see the NAND backup size.
Thanks.

I think what's going on here is the same thing that goes on with the NAND chips on the n3ds... Some are 1.2 GB and others are 1.8 GB, but only 1.2 GB is ever actually used on any of the chips... So it seems that the 2ds is using the 1.2 GB chip with the o3ds NAND layout and has some extra space on it

 

[d0k3]

@d0k3
I found the successful case.
http://gbatemp.net/threads/release-...olkit-fw-2-0-9-2.382782/page-357#post-5580703
He used an old version (earlier than Jul.19 2015) Decrypt9 to create a 943MB NAND backup from his "1.21GB" 2DS.
I don't know if it's that
- Old version of Decrypt9 can force generating 943MB NAND size from real 1.21GB NAND
or
- That 2DS NAND is a fake 1.21GB and actually it's 943MB, only GW Launcher misrecognized it
@thaikhoa
I need your help.
If you have spare time, please perform a NAND backup with current version of EmuNAND9 and Decrypt9WIP on that "1.21GB" 2DS, to see the NAND backup size.
Thanks.

Don't want to sound blunt, but what you are trying will not work. If it worked one time, that is for reasons unknown. The emuNAND header is still missing. See, 943MB is the actual used size of the NAND flash memory, while 1.21GB is the actual size of the NAND flash memory. In fact, all NAND flash memories (O3DS / N3DS / 2DS) are bigger than their used size - 1.8GB flash memories are common on N3DS, while only 1.2GB is used, f.e. - probably because Nintendo gets these slightly too big chips a little cheaper than ones that would fit perfectly, so they're just leaving space unused.

That older version of Decrypt9WIP dumped the used data instead of the full data of the memory chip, otherwise the backup is identical. Fake memory sizes on 3DS consoles are very, very unlikely. And the dumped NAND size will be 1.21GB.

@mid-kid, @AlbertoSONIC, @Aurora Wright (and @Reisyukaku, although I know you only develop for N3DS) - do you have any idea why there is trouble loading the EmuNAND on these special 2DS consoles with a 1.21GB NAND chip (also see here)? How would one have to set up the EmuNAND for it to work?

 

[Aurora Wright]

Don't want to sound blunt, but what you are trying will not work. If it worked one time, that is for reasons unknown. The emuNAND header is still missing. See, 943MB is the actual used size of the NAND flash memory, while 1.21GB is the actual size of the NAND flash memory. In fact, all NAND flash memories (O3DS / N3DS / 2DS) are bigger than their used size - 1.8GB flash memories are common on N3DS, while only 1.2GB is used, f.e. - probably because Nintendo gets these slightly too big chips a little cheaper than ones that would fit perfectly, so they're just leaving space unused.

That older version of Decrypt9WIP dumped the used data instead of the full data of the memory chip, otherwise the backup is identical. Fake memory sizes on 3DS consoles are very, very unlikely. And the dumped NAND size will be 1.21GB.

@mid-kid, @AlbertoSONIC, @Aurora Wright (and @Reisyukaku, although I know you only develop for N3DS) - do you have any idea why there is trouble loading the EmuNAND on these special 2DS consoles with a 1.21GB NAND chip (also see here)? How would one have to set up the EmuNAND for it to work?

Rei's code for emuNAND (which I use in my fork) does this: it uses Normmatt's sdmmc library to calculate the total NAND sectors (not sure if it's able to handle 1.21 GB properly); then it uses this number to seek the following sector *on SD* to use as header. So a proper emuNAND for these consoles *should work* with my reiNAND fork. You only need to get a tool capable to actually create one.

 

[d0k3]

@MelonGx, I discussed with mid-kid, and we can try something: Setting the EmuNAND up as a RedNAND. Would your tester be willing to try this? If he is, I'll add that option to EmuNAND9 and give you a test build.

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

Rei's code for emuNAND (which I use in my fork) does this: it uses Normmatt's sdmmc library to calculate the total NAND sectors (not sure if it's able to handle 1.21 GB properly); then it uses this number to seek the following sector *on SD* to use as header. So a proper emuNAND for these consoles *should work* with my reiNAND fork. You only need to get a tool capable to actually create one.

EmuNAND9 does it exactly like that now, but the problem with these special 2DS consoles seems different.