242
edits
Changes
→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.
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.
First, there are 8 bytes whose purposes are currently unknown. Then comes the actual blockmap.
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).
The blockmap structure is simple:
First, there are 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 entry is simple:
<pre>
<pre>
struct header_entry {
struct blockmap_entry_v1 {
uint8_t phys_sec; // when bit7 is set, block has checksums, otherwise checksums are all zero
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 alloc_cnt;
uint8_t chksums[8];
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__));
} __attribute__((__packed__));
</pre>
</pre>
There's one entry per sector, counting from physical sector 1 (sector 0 contains the blockmap/journal).
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
<pre>
fn crc16(data: &[u8]) -> u16 {
let poly = 0xA001;
let mut crc = 0xFFFFu16;
for byte in data {
crc ^= <u16>::from(*byte);
for _ in 0..8 {
let b = crc & 1 != 0;
crc >>= 1;
if b {
crc ^= poly;
}
}
}
crc
}
</pre>
Then comes the journal.
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 0xFF
The journal structure is as follows:
The journal entry structure is as follows:
<pre>
<pre>
struct sector_entry {
struct journal_entry_half {
uint8_t virt_sec; // Mapped to sector
uint8_t virt_sec; // Mapped to sector
uint8_t prev_virt_sec; // Physical sector previously mapped to
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 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 virt_realloc_cnt; // Amount of times virtual sector has been remapped
uint8_t chksums[8];
uint8_t chksums[8]; // Unused & uninitialized for V2
} __attribute__((__packed__));
} __attribute__((__packed__));
struct long_sector_entry{
struct journal_entry{
struct sector_entry sector;
struct journal_entry_half entry;
struct sector_entry dupe;
struct journal_entry_half dupe; // same data as `entry`. No idea what this is used fore
uint32_t magic;
uint32_t uninitialized; // 0xFFFFFFFF in newer system
}__attribute__((__packed__));
}__attribute__((__packed__));
</pre>
</pre>
The checksums in the blockmap/journal entries work as follows:
The checksums in the blockmap/journal entries work as follows:
* each byte is the checksum of an encrypted 0x200 bytes large block
* each byte is the checksum of an encrypted 0x200 bytes large block
* to calculate the checksum, a CRC16 of the block (with starting value 0xFFFF) is calculated, and the two bytes of the CRC16 are XORed together to produce the 8bit checksum
* to calculate the checksum, a CRC16 of the block (same CRC16 algorithm as above) is calculated, and the two bytes of the CRC16 are XORed together to produce the 8bit checksum
== Initialization ==
== Initialization ==