EmuNAND/RedNAND technical implementation

Discussion in '3DS - Flashcards & Custom Firmwares' started by neobrain, Nov 3, 2015.

  1. neobrain
    OP

    neobrain -

    Member
    306
    472
    Apr 25, 2014
    Hi people,

    I've been looking occasionally into public EmuNAND and RedNAND solutions - it does seem like there are quite a few of those available. However, despite the amount of available options, there seems to be quite the lack of technical reference on the actual implementation of EmuNAND and RedNAND - that is, the actual layout of data on the SD card. Maybe I've just missed something even after a while of looking around. Either way, I'm sure there are some knowledgeable people who could clear this up easily, though, hence why I'm creating this thread.

    Basically, I'm curious about two things:
    - What is the actual layout of EmuNAND images on the SD card? How specifically is the NAND image injected onto the SD card storage? I've heard people talking about hidden FAT partitions and modifying the partition table, but all of this is hard to follow without an understanding of the firmware patches used to load the CFW in the first place.
    - What is different about RedNAND images?

    For reference, I will keep this thread updated with any information given to me, so that hopefully, people looking for the same information can find it more easily in the future.

    Thanks in advance for any suggestions!


    EDIT:
    Well, nevermind. Normmatt clearred most of it up on IRC (thanks!). Leaving the info out there, though. See the second post in this thread
     
    Last edited by neobrain, Nov 3, 2015
  2. neobrain
    OP

    neobrain -

    Member
    306
    472
    Apr 25, 2014
    Current information gathered:

    Say, NAND image is N bytes large.

    Background and general idea:
    - The first 512 bytes on the SD card are the MBR (Master Boot Record), which includes information of all partitions present on the SD card. In particular, it contains information about the offset of each filesystem on the storage device.
    - The "actual" SD filesystem can be shrinked and moved to make room for a full NAND image on the storage device.

    RedNAND:
    - The full NAND image is put onto the SD card at byte offset 512.
    - Following the NAND image, a standard FAT filesystem containing the "actual" SD data is stored at byte offset N+512.
    - The RedNAND implementation will offset all reads and writes to the NAND by 512 bytes.

    EmuNAND:
    - Bytes [512:N-1] of the NAND image are put onto the SD card at byte offset 512.
    - Bytes [0;511] of the NAND image are put onto the SD card at byte offset N.
    - Following the NAND image, a standard FAT filesystem containing the "actual" SD data is stored at byte offset N+512.
    - The EmuNAND implementation leaves almost all reads/writes unmodified. Accesses to the first 512 bytes need to be redirected, however.

    Bonus:
    - It's easily possible to hide the NAND image by simply not having any entry for it in the MBR. I'm not quite sure if this serves any actual purpose, though.

    I documented all of this on 3dbrew now.
     
    Last edited by neobrain, Nov 3, 2015
  3. jimmyleen

    jimmyleen GBAtemp Maniac

    Member
    1,161
    198
    Feb 28, 2016

    Now all we need is a guide on how to get this up and running on the N3DS.

    Edit: I will NOT use my 3ds as a Ginny pig
     
  4. urherenow

    urherenow GBAtemp Addict

    Member
    2,961
    877
    Mar 8, 2009
    United States
    Japan
    I still fail to see what makes RedNAND better. What is better about having to shift all reads and writes to emuNAND? What prevents something from messing up the hook, causing a corrupted emuNAND?
     
    fr3quency likes this.
  5. Dartz150

    Dartz150 GBATemp Official Lolicon Onii-chan™

    Member
    1,406
    844
    May 5, 2010
    Mexico
    On a Strange Journey
    I guess it benefits on speed, making it as fast as the sysNAND.

    I'm using sysnand with A9LH right now and he speed access is quite noticeable compared to emuNAND.
     
  6. Glix

    Glix GBAtemp Regular

    Member
    101
    29
    Jan 11, 2016
    You are way off the mark. This has nothing to do with making it as fast as sysnand (you can't, latency of sd's cards and the reader/writer slow it down).

    Translating into pictures:

    Rednand on SD:
    [mbr (512b)][SYSNAND converted into sdNAND][FAT user space]

    EmuNAND on SD:
    [mbr (512b)][512:Sysnand end (don't know why neo states -1 here, why lop it off?)][Sysnand beginning:511][FAT user space]

    I presume it's the redirecting and calculating layer that they want to bin in favour for just offsetting every call which would things cheaper in terms of the greater than operations on every call. But in real life, is the Arm really that slow that the user would see the performance gain?
     
    FenrirWolf likes this.
  7. Dartz150

    Dartz150 GBATemp Official Lolicon Onii-chan™

    Member
    1,406
    844
    May 5, 2010
    Mexico
    On a Strange Journey
    Oh, I see it clearly now, thank you.
     
  8. nintendowii

    nintendowii GBAtemp Regular

    Member
    117
    3
    Feb 28, 2011
    Germany
    I dont understand the technical details so much. Can anybody explain the pros and cons with easy words? What is the better choice?
     
  9. jakerman999

    jakerman999 Member

    Newcomer
    46
    4
    May 15, 2013
    Canada
    The -1 isn't lopping off the end of the emunand, N-1 is the end of the emunand. It's a zero indexed system. This means if it were 10 bytes long, the first byte would be 0 and the last byte would be 9.
     
    Glix likes this.
  10. Glix

    Glix GBAtemp Regular

    Member
    101
    29
    Jan 11, 2016
    Ah right, thanks, note to self, don't overthink it at 2:43am. :P
     
  11. jakerman999

    jakerman999 Member

    Newcomer
    46
    4
    May 15, 2013
    Canada
    No worries, I myself am no stranger to the general 3AM grogginess:wtf:
     
  12. GerbilSoft

    GerbilSoft GBAtemp Addict

    Member
    2,081
    2,304
    Mar 8, 2012
    United States
    From what I understand, RedNAND is a better choice for N3DSes with the Toshiba 1.8 GB NAND, since the CTRNAND partition is always sized for the 1.2 GB version. In this case, the extra 600 MB can be cut off from the end of the RedNAND without any issues. With GW-style EmuNAND, this isn't possible, since sector 0 is always located at the end of the EmuNAND area, which is determined by checking the SysNAND size.

    For other NAND types, it doesn't usually make much of a difference, though you obviously need to use GW EmuNAND if you want to use a Gateway card.
     
    DerpMC_Haxx and nintendowii like this.