Wii Hardware/NAND: Difference between revisions
Jump to navigation
Jump to search
m improve image formatting |
Clean up NAND page |
||
| Line 3: | Line 3: | ||
The [[Wii]] contains a 4 Gigabit (512 Megabyte) NAND flash memory chip. The NAND is used to store, among other things, every IOS installed on the system, each stage past boot0 (which is stored in ROM) of the bootloader process as described on [[Wii Hardware/Starlet|Starlet]], your system menu and channels, and your game save files. | The [[Wii]] contains a 4 Gigabit (512 Megabyte) NAND flash memory chip. The NAND is used to store, among other things, every IOS installed on the system, each stage past boot0 (which is stored in ROM) of the bootloader process as described on [[Wii Hardware/Starlet|Starlet]], your system menu and channels, and your game save files. | ||
There is currently no way to read or write the NAND in [[Wii-Linux]] nor [[NetBSD]]. | There is currently no way to read or write the NAND in [[Wii-Linux]] nor [[NetBSD]], though [[NPLL]] can read the [[SFFS]] filesystem stored on it. | ||
== Data Sizes == | == Data Sizes == | ||
| Line 9: | Line 9: | ||
== Physical Data Layout == | == Physical Data Layout == | ||
* Block 0 contains boot1, which is the encrypted second stage | * Block 0 contains boot1, which is the encrypted second stage bootloader, loaded and decrypted by [[Wii Hardware/Starlet|Starlet]] during execution of boot0. There is currently no safe way to modify the contents of this block. | ||
* Blocks 1-7 contain 2 copies of boot2, with blockmaps. Boot2 is stored in a modified WAD format, with a ticket encrypted and signed using [[Nintendo]]'s common key. It is recommended to only modify this area when installing | * Blocks 1-7 contain 2 copies of boot2, with blockmaps. Boot2 is stored in a modified WAD format, with a ticket encrypted and signed using [[Nintendo]]'s common key. It is recommended to only modify this area when installing [[BootMii]] as boot2, and only when you have a vulnerable version of boot1. | ||
* Block 8 contains the start of per-console data, as well as the header metadata for the NAND filesystem. This and the next 4087 blocks are generally safe to modify, as long as you have | * Block 8 contains the start of per-console data, as well as the header metadata for the NAND filesystem (SFFS). This and the next 4087 blocks are generally safe to modify, as long as you have BootMii as boot2 and don't erase the FAT. This is the area that would be exposed with a filesystem by a driver, were one to be made. | ||
[[Category:Wii Hardware]] | [[Category:Wii Hardware]] | ||
Revision as of 12:32, 15 July 2026
- See also: [https://wiibrew.org/wiki/Hardware/NAND]
The Wii contains a 4 Gigabit (512 Megabyte) NAND flash memory chip. The NAND is used to store, among other things, every IOS installed on the system, each stage past boot0 (which is stored in ROM) of the bootloader process as described on Starlet, your system menu and channels, and your game save files. There is currently no way to read or write the NAND in Wii-Linux nor NetBSD, though NPLL can read the SFFS filesystem stored on it.
Data Sizes
The NAND is split into 4096 sections referred to as "Blocks". Each block contains 64 pages, and each page contains 2048 bytes of data with 64 bytes of error correction info.
Physical Data Layout
- Block 0 contains boot1, which is the encrypted second stage bootloader, loaded and decrypted by Starlet during execution of boot0. There is currently no safe way to modify the contents of this block.
- Blocks 1-7 contain 2 copies of boot2, with blockmaps. Boot2 is stored in a modified WAD format, with a ticket encrypted and signed using Nintendo's common key. It is recommended to only modify this area when installing BootMii as boot2, and only when you have a vulnerable version of boot1.
- Block 8 contains the start of per-console data, as well as the header metadata for the NAND filesystem (SFFS). This and the next 4087 blocks are generally safe to modify, as long as you have BootMii as boot2 and don't erase the FAT. This is the area that would be exposed with a filesystem by a driver, were one to be made.