In memory of Ben “bushing” Byer, who passed away on Monday, February 8th, 2016.

Difference between revisions of "Hardware/NAND"

From WiiBrew
Jump to navigation Jump to search
(documenting the NAND metadata format)
Line 1: Line 1:
 
The Wii contains 512 MiB of NAND flash storage, which is used to store "system software", channels (including Virtual Console titles), game saves, and system settings.
 
The Wii contains 512 MiB of NAND flash storage, which is used to store "system software", channels (including Virtual Console titles), game saves, and system settings.
  
 +
== Physical layout ==
 
The NAND flash device is divided into 4096 blocks of 8 clusters.  Each cluster is 8 pages.  Each page is 2048 bytes of data and 64 bytes of "spare data" (used for error-correction (ECC) data and HMAC signatures on individual clusters).
 
The NAND flash device is divided into 4096 blocks of 8 clusters.  Each cluster is 8 pages.  Each page is 2048 bytes of data and 64 bytes of "spare data" (used for error-correction (ECC) data and HMAC signatures on individual clusters).
  
Line 12: Line 13:
 
* Clusters 0x7F00-0x7FFF: Filesystem metadata (SFFS, unencrypted).  There are 16 superblocks contained therein -- one every 16 clusters.
 
* Clusters 0x7F00-0x7FFF: Filesystem metadata (SFFS, unencrypted).  There are 16 superblocks contained therein -- one every 16 clusters.
  
 +
== Metadata layout ==
 +
The authoritative source of information about the Wii's metadata layout is [http://git.infradead.org/users/segher/wii.git?a=blob;f=zestig.c Segher's zestig.c], but here is an attempt to describe that in English.
 +
 +
Each metadata "superblock" starts with the 4 magic bytes "SFFS", followed by a 4-byte "generation number" and another 4-byte number (always 0x10?).  When accessing the FS, IOS will choose the superblock with the highest generation number and use it; whenever it modifies the filesystem in any way, it will increment the generation number by 1 and write out an entirely new superblock in the next slot (in round-robin order).
 +
 +
The next 0x10000 bytes (bytes 0xc:0x1000c within the superblock) are 0x8000 2-byte cluster numbers, and comprise the FAT.  The FAT is followed by the FST -- the tree structure containing the directory hierarchy and (plaintext!) filenames.
 +
 +
=== FAT ===
 +
The FAT contains cluster chain / allocation information for the entire NAND chip, including parts of it which are not technically part of the filesystem!
 +
 +
The first 64 entries will always be 0xFFFC, which indicates that this cluster is "reserved".  These correspond to the first 64 clusters or 8 blocks -- which is where boot1 and boot2 are stored.
 +
 +
Special values include:
 +
* 0xFFFB - last cluster within a chain
 +
* 0xFFFC - reserved cluster
 +
* 0xFFFD
 +
* 0xFFFE
 +
 +
Otherwise, the value stored within a slot in the FAT for a given cluster points to the next cluster in the chain, similar to the FAT used in DOS.  Therefore, in order to figure out what clusters belong to what file, you must use the information in the FST to find the starting cluster for each file, and then follow each cluster chain.
 +
 +
=== FST ===
 +
Each entry in the FST is 0x20 bytes. Here is a typical entry for a leaf node (regular file):
 +
0000000: 4e41 4e44 424f 4f54 494e 464f fd00 2714  NANDBOOTINFO..'.
 +
0000010: 0035 0000 1020 0000 1000 0001 0000 0000  .5... ..........
 +
=== File structure ===
 +
{| class="wikitable"
 +
|-
 +
! Start
 +
! End
 +
! Length
 +
! Typical value
 +
! Description
 +
|-
 +
| 0x00
 +
| 0x0B
 +
| 0x0B
 +
| "NANDBOOTINFO"
 +
| Filename
 +
|-
 +
| 0x0C
 +
| 0x0C
 +
| 1
 +
| 0xfd
 +
| file access "mode"
 +
|-
 +
| 0x0D
 +
| 0x0D
 +
| 1
 +
| 0
 +
| file attributes
 +
|-
 +
| 0x0E
 +
| 0x0F
 +
| 2
 +
| 0x2714
 +
| "sub"
 +
|-
 +
| 0x10
 +
| 0x11
 +
| 2
 +
| 0x0035
 +
| "sib"
 +
|-
 +
| 0x12
 +
| 0x14
 +
| 4
 +
| 0x1020
 +
| filesize
 +
|-
 +
| 0x15
 +
| 0x16
 +
| 2
 +
| 0
 +
| unknown
 +
|-
 +
| 0x17
 +
| 0x18
 +
| 2
 +
| 0x1000
 +
| uid
 +
|-
 +
| 0x19
 +
| 0x1A
 +
| 2
 +
| 0x1
 +
| gid
 +
|-
 +
| 0x1B
 +
| 0x1F
 +
| 4
 +
| 0
 +
| unknown
 +
|-
 +
|}
 +
 +
== Supported chips ==
 
The NAND flash driver inside boot2 and IOS supports the following chip IDs:
 
The NAND flash driver inside boot2 and IOS supports the following chip IDs:
  
Line 17: Line 114:
 
  Samsung: ec 76 / ec f1 / ec da / ec dc (64M [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=158&partnum=K9F1208U0C K9F1208U0C] /128 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=159&partnum=K9F1G08U0B K9F1G08U0B]/256 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=159&partnum=K9F2G08U0A K9F2G08U0A]/512 = [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=159&partnum=K9F4G08U0A K9F4G08U0A])
 
  Samsung: ec 76 / ec f1 / ec da / ec dc (64M [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=158&partnum=K9F1208U0C K9F1208U0C] /128 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=159&partnum=K9F1G08U0B K9F1G08U0B]/256 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=159&partnum=K9F2G08U0A K9F2G08U0A]/512 = [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=159&partnum=K9F4G08U0A K9F4G08U0A])
 
  Toshiba: 98 76 / 98 f1 / 98 da (64/128 = TC58NVG0S3AFT05 or TC58NVG0S3ATG05 or TC58NVG0S3BFT00/256 = TC58NVG1D4BTG00 (?!))
 
  Toshiba: 98 76 / 98 f1 / 98 da (64/128 = TC58NVG0S3AFT05 or TC58NVG0S3ATG05 or TC58NVG0S3BFT00/256 = TC58NVG1D4BTG00 (?!))
 +
 +
It is not known why the IOS driver supports chips smaller than 512MB.
 
[[Category:Hardware]]
 
[[Category:Hardware]]
  

Revision as of 01:02, 10 August 2009

The Wii contains 512 MiB of NAND flash storage, which is used to store "system software", channels (including Virtual Console titles), game saves, and system settings.

Physical layout

The NAND flash device is divided into 4096 blocks of 8 clusters. Each cluster is 8 pages. Each page is 2048 bytes of data and 64 bytes of "spare data" (used for error-correction (ECC) data and HMAC signatures on individual clusters).

  • Block 0 (pages 0-0x3F): boot1
    • boot1 is the second-stage bootloader; it is decrypted by boot0, which resides on a read-only mask rom inside the Starlet coprocessor. Its primary function is to load and decrypt boot2.
    • Block 0 is guaranteed by the manufacturer to be valid, so there is no bad block map necessary.
  • Blocks 1-7 (Pages 0x40 - 0x1ff) : boot2 (two copies and blockmaps)
    • boot2 is the third-stage bootloader; it is stored in a modified WAD format, including a ticket that is encrypted with the common key and signed.
  • Block 8 / Cluster 0x40 / Page 0x200: beginning of per-console unique data
  • Clusters 0x40 - 0x7EFF: Encrypted filesystem data. Data is encrypted with a per-console AES key, and then signed with a (separate, per-console) HMAC key.
  • Clusters 0x7F00-0x7FFF: Filesystem metadata (SFFS, unencrypted). There are 16 superblocks contained therein -- one every 16 clusters.

Metadata layout

The authoritative source of information about the Wii's metadata layout is Segher's zestig.c, but here is an attempt to describe that in English.

Each metadata "superblock" starts with the 4 magic bytes "SFFS", followed by a 4-byte "generation number" and another 4-byte number (always 0x10?). When accessing the FS, IOS will choose the superblock with the highest generation number and use it; whenever it modifies the filesystem in any way, it will increment the generation number by 1 and write out an entirely new superblock in the next slot (in round-robin order).

The next 0x10000 bytes (bytes 0xc:0x1000c within the superblock) are 0x8000 2-byte cluster numbers, and comprise the FAT. The FAT is followed by the FST -- the tree structure containing the directory hierarchy and (plaintext!) filenames.

FAT

The FAT contains cluster chain / allocation information for the entire NAND chip, including parts of it which are not technically part of the filesystem!

The first 64 entries will always be 0xFFFC, which indicates that this cluster is "reserved". These correspond to the first 64 clusters or 8 blocks -- which is where boot1 and boot2 are stored.

Special values include:

  • 0xFFFB - last cluster within a chain
  • 0xFFFC - reserved cluster
  • 0xFFFD
  • 0xFFFE

Otherwise, the value stored within a slot in the FAT for a given cluster points to the next cluster in the chain, similar to the FAT used in DOS. Therefore, in order to figure out what clusters belong to what file, you must use the information in the FST to find the starting cluster for each file, and then follow each cluster chain.

FST

Each entry in the FST is 0x20 bytes. Here is a typical entry for a leaf node (regular file): 

0000000: 4e41 4e44 424f 4f54 494e 464f fd00 2714  NANDBOOTINFO..'.
0000010: 0035 0000 1020 0000 1000 0001 0000 0000  .5... ..........

File structure

Start End Length Typical value Description
0x00 0x0B 0x0B "NANDBOOTINFO" Filename
0x0C 0x0C 1 0xfd file access "mode"
0x0D 0x0D 1 0 file attributes
0x0E 0x0F 2 0x2714 "sub"
0x10 0x11 2 0x0035 "sib"
0x12 0x14 4 0x1020 filesize
0x15 0x16 2 0 unknown
0x17 0x18 2 0x1000 uid
0x19 0x1A 2 0x1 gid
0x1B 0x1F 4 0 unknown

Supported chips

The NAND flash driver inside boot2 and IOS supports the following chip IDs: 

Hynix: ad 76 / ad f1 / ad dc  (64MB = HY27US0812(1/2)B, 128MB = HY27UF081G2A, 512MB = HY27UF084G2M or HY27UG084G2M)
Samsung: ec 76 / ec f1 / ec da / ec dc (64M K9F1208U0C /128 K9F1G08U0B/256 K9F2G08U0A/512 = K9F4G08U0A)
Toshiba: 98 76 / 98 f1 / 98 da (64/128 = TC58NVG0S3AFT05 or TC58NVG0S3ATG05 or TC58NVG0S3BFT00/256 = TC58NVG1D4BTG00 (?!))

It is not known why the IOS driver supports chips smaller than 512MB.

[USEFUL LINKS @samsung]
http://www.datasheetcatalog.org/datasheets/700/389215_DS.pdf
http://www.samsung.com/global/system/business/semiconductor/family/2009/4/23/496729Nand_Flash.pdf

Retrieved from "https://wiibrew.org/w/index.php?title=Hardware/NAND&oldid=65029"