search

roxas75 / rxTools

rxTools
http://www.rxtools.net/
GNU General Public License v2.0
266 stars 81 forks source link

Use the NAND size from sdmmc.s to determine emunand sector #208

Open b1l1s opened 9 years ago

b1l1s commented 9 years ago

A bit of an introduction to the issue. GW uses the actual NAND size when creating/booting emunand. rxTools and (previously)CakesFW boots these without issue, except for guys with 2DS with N3DS NANDs. The solution they came up with was to create a temporary emunand with o3ds and inject a trimmed down dump of their NAND gotten through Decrypt9.

(This is when taikhoa first reported the problem)

The problem now is those users now can't boot into CakesFW after we change to automatically detect NAND size ala GW.

My proposal is for you guys to change as well. Now you probably think that I'm being lazy (and that may be half true) but your users with exotic NAND sizes won't have to manually inject their dumps anymore.

To get NAND sector count using sdmc.s you'll have to get it from dword_80A6F20(the nand data struct) at offset 0x30.

I suggest using Normmatt's sdmmc.c though, since the structure is defined and the function to retrieve the struct is already exposed. There's a bug with the NAND size calculation which Normmatt has fixed, you can get the most updated version from CakesFW or CakeHax (Normmatt's sdmmc.c is dual-licensed under GPLv2 and MPL).

Here's the link to the issue in our repo: https://github.com/mid-kid/CakesForeveryWan/issues/8

AlbertoSONIC commented 9 years ago

N3DS nand on 2DS?! Didn't know that... Well then, we'll read the nand size as you do ;)

b1l1s commented 9 years ago

Great, thanks!

AlbertoSONIC commented 9 years ago

I'll be back on a wifi only in Sunday, when I'll go back home. My local rxtools clone contains experimental/wip code... I won't be able to download rxTools repo for applying changes till Sunday :(

If someone fix this for me it's ok, otherwise you'll have to wait Sunday ;)

d0k3 commented 9 years ago

Just for clarification... if a 2DS has a N3DS NAND, does that apply only to memory size or to the memory layout as well? There is not only a size difference between the O3DS / N3DS NAND total size, but also the CTRNAND FAT16 file system has a different size and a slightly different offset.

http://3dbrew.org/wiki/Flash_Filesystem

b1l1s commented 9 years ago

The layout is the same to normal 2DS I think, since the user was able to use the trimmed down version of his nand from Decrypt9 (943MB, CTR NAND ends much further than this in N3DS).

d0k3 commented 9 years ago

Alright, that's what I thought... So, the problem is that...

1.) GW detects actual NAND memory size for EmuNAND instead of just detecting the console type and use the known values for size. Because we don't want any incompatibilities (it's confusing enough for users already), every other EmuNAND solution does it the same as GW now.

2.) If the NAND backup size is different from the actual NAND memory size, because of 1), there is no possibility to create an EmuNAND from that or - even if we somehow managed to create the EmuNAND - boot the EmuNAND.

Is this correct?

b1l1s commented 9 years ago

You're right on both points.