Valid EmuNAND backups made with rxTools are considered invalid
s0r00t opened this issue · comments
This was noticed with a (o3DS) 10.3 EmuNAND backup made with latest rxTools.
Trying to restore it with EmuNAND9 will output this error : "NAND dump has the wrong size!"
However, restoring it with EmuNAND tool on a Windows system worked.
The backup is ~988Mo/7910Mb.
This issue is already known. I can allow EmuNAND9 to inject this EmuNAND backup, but you have to know that the backup done by rxTools / injected by EmuNAND Tool actually contains invalid data at the end, because both of them dump too much data. Also, you should use EmuNAND9 to create the EmuNAND backup, not rxTools.
This is where this issue comes from:
GW Software (which was previously the only way of setting up an EmuNAND) reserves the maximum amount of memory when creating an EmuNAND - this can mean 600MB and more of wasted data. EmuNAND9 does handle this more intellegently by never reserving more than the actual SysNAND size.
If you ask me, I can make EmuNAND9 more liberal with backup sizes, at the cost of some safety (because size is now another factor to recognize proper backups). But the real issue is in EmuNAND Tool and in rxTools.
Maybe you could show a safety message when the dump is from rxTools/EmuNAND9.
(I've dumped the EmuNAND before even knowing that EmuNAND9 exists...)
I'll add the change, but it will take a day or two. I need to make sure that allowed sizes are at elast somewhat proper. In the meantime, know that you can also trim the backup yourself to reach the proper size. (the proper size is the size of a SysNAND / EmuNAND backup from EmuNAND9)
Not sure if the same issue, but I recently pulled an emuNAND I had originally made with EmuNAND9 using rxTools, and the rxTools dump ended up being 944 or 948 MB in size (sorry, I deleted the actual file before I thought to come here, I can try to re-create it). EmuNAND9 creates a file of size 954 MB. This is on an o3DS with firmware 10.3 emuNAND. When I tried to inject the emuNAND made by rxTools I had the same result as s0r00t. Makes sense since the size of the files made by rxTools and EmuNAND9 are not the same, yet I find it odd that rxTools makes something the wrong size...
Is there a way to check the real NAND size on a 3DS? According to this:
http://wiki.gbatemp.net/wiki/3DS_Flashcart_FAQ
there are two sysNAND sizes possible for o3DS, and the file sizes made by EmuNAND9 and rxTools in this case match (more or less) the known sizes of the two NAND chips in use.
Well, yes, there is a way to check the real size of the 3DS flash memory. EmuNAND9 uses it (it is 954MB in your case) and rxTools just guesses (I know that code in rxTools well). In fact, that should be fixed in rxTools, but, well that won't help you guys now.
Now, the actual used size of the NAND flash memory is smaller than that. You can pad (= add garbage data to the end) your backups yourself. And I will add something that automatically does that in EmuNAND9 in the next release.
OK. Good to know. I had my original backup made in EmuNAND9, so I'm still fine. I was just playing around with rxTools to see what it could do. I'll try compiling the latest rxTools and see how that behaves. If it is still weird for some reason, I may try to narrow down what's going on over there, but as you said, it should be fixed now. Thanks for the help!
Seeing that you're a developer yourself, I'll show you...
See this?
https://github.com/roxas75/rxTools/blob/f6427b769a413e10c8ccc43897d3d4bc280eba36/rxtools/source/features/NandDumper.c#L39
That's the hardcoded NAND size in rxTools. As you know, there are different NAND chips used and thus there's no one-size-fits-all.
Compare with this...
https://github.com/d0k3/EmuNAND9/blob/master/source/emunand9.c#L95
That's the correct way of doing it. It uses a system call that returns the exact number of sectors on the NAND flash chip.
Just checked it by compiling 3caedca. It works (the warning is a nice bonus). I think think you can mark this issue as being fixed.
Thanks for the links comparing EmuNAND9's size calculation with rxTools. Yeah, I see what you mean. Now I get why the original author of rxTools mentioned (IIRC) that he had no original plans to release rxTools to the public, and as a result there would be some kludges here and there. Took me a bit of searching to figure out where the mmcdevice structs were being initialized, but I eventually found it.
Thanks for testing! By the way, I have to correct myself for a bit. There are actually four different NAND chip sizes, two of them are used in O3DS, the other two in N3DS.
Closing this for now.