Jump to navigation Jump to search
1,765 bytes added ,  17:06, 2 December 2019
→‎Gamecard wear leveling: Update info for wear leveling V2
The 3DS employs a wear leveling scheme on the savegame FLASH chips(only used for CARD1 gamecards). This is done through the usage of blockmaps and a journal. The blockmap is located at offset 0 of the flash chip, and is immediately followed by the journal. The initial state is dictated by the blockmap, and the journal is then applied to that.
There are two versions of wear leveling have been observed. V1 is used for 128KB and 512 KB CARD1 flash chips. V2 is used for 1MB CARD1 flash chips (uncommon. Pokemon Sun/Moon is an exampe). First, there are 8 bytes two 32-bit integers whose purposes are currently unknown. They generally increase the value as the savegame is written more times, so probably counter for how many times the journal became full and got flushed into the block map, and/or how many times <code>alloc_cnt</code> has wrapped around.  Then comes the actual blockmap. The block map contains entries of 10 bytes (V1) or 2 bytes (V2) with total number of <code>(flash_size / 0x1000 - 1)</code>.The blockmap structure entry is simple:
struct header_entry blockmap_entry_v1 { uint8_t phys_sec; // when bit7 is set, block is initialized and has checksums, otherwise checksums are all zero
uint8_t alloc_cnt;
uint8_t chksums[8];
} __attribute__((__packed__));
struct blockmap_entry_v2 {
// Note that the phys_sec and alloc_cnt field are swapped in v2,
// but the initialized bit is still on the first byte
uint8_t alloc_cnt; // when bit7 is set, block is initialized
uint8_t phys_sec;
// v2 has no chksums
} __attribute__((__packed__));
There's one entry per 0x1000-byte sector, counting from physical sector 1 (sector 0 contains the blockmap/journal). A 2-byte CRC16 follows the block map. For V1 it immediately follows the last block map entry. For V2 it is located at 0x3FE, and bytes before the CRC is padded with zero. The CRC16 checks all the bytes before it, including the two unknown integers, the block map, and the padding bytes for V2. The CRC standard used looks like CRC-16-IBM (modbus). Here is the code in Rust for it
The 2 bytes that follow the blockmap are the CRC16 <pre>fn crc16(with starting value 0xFFFF data: &[u8]) -> u16 { let poly = 0xA001; let mut crc = 0xFFFFu16; for byte in data { crc ^= <u16>::from(like modbus*byte)) of the first ; for _ in 0..8 bytes and the blockmap.{ let b = crc & 1 != 0; crc >>= 1; if b { crc ^= poly; } } } crc}</pre>
Then comes the journal.The journal contains entries that describes how sectors should be remapped. The rest bytes before 0x1000 after all journal entries are padded with 0xFFThe journal entry structure is as follows:
struct sector_entry journal_entry_half {
uint8_t virt_sec; // Mapped to sector
uint8_t prev_virt_sec; // Physical sector previously mapped to
uint8_t phys_realloc_cnt; // Amount of times physical sector has been remapped
uint8_t virt_realloc_cnt; // Amount of times virtual sector has been remapped
uint8_t chksums[8]; // Unused & uninitialized for V2
} __attribute__((__packed__));
struct long_sector_entryjournal_entry{ struct sector_entry sectorjournal_entry_half entry; struct sector_entry journal_entry_half dupe;// same data as `entry`. No idea what this is used fore uint32_t magicuninitialized; // 0xFFFFFFFF in newer system
With magic being a constant 0x080d6ce0.
The checksums in the blockmap/journal entries work as follows:
* each byte is the checksum of an encrypted 0x200 bytes large block
* to calculate the checksum, a CRC16 of the block (with starting value 0xFFFFsame CRC16 algorithm as above) is calculated, and the two bytes of the CRC16 are XORed together to produce the 8bit checksum
== Initialization ==


Navigation menu