Wii Boot Process

The Wii Boot Process is a 5-step process from the initial power-on of the Wii system, to initialization of the Wii System Menu (normally, the "Health & Safety" screen is displayed when the process is complete).

boot0

boot0 forms the initial phase of the Wii boot process. Boot0 is the Wii's "bootROM", a small piece of code physically burned into the Hollywood/Bollywood package. As such, the first instruction of boot0 is the first thing executed when the Wii is powered on, and since boot0 is burned into ROM, it can never be changed even with hardware modifications to the console. boot0, 1, 2, and IOS are ARM programs which run on the IOP.

Boot0's task is to decrypt the first block of the Wii's NAND (block 0, which normally contains boot1), verify that its contents are valid, and begin executing the binary stored there. It decrypts this block using a key read from the Wii's eFuses (unless boot0 is compiled to use a hardcoded key instead), then verifies it against a hash which is also stored in the eFuses.

If the stored hash matches that of the first block of NAND or if the stored hash is all zeroes (as is the case on non-production systems), boot1 will be executed; if there is a hash mismatch, boot0 will halt immediately, irrecoverably bricking the system unless a NAND image is available and can be flashed using a hardware programmer. This ensures that boot1 can never be modified on production systems once the Wii Factory Process is complete, as any modifications would invalidate the hash (unless a hash collision is found).

boot1

boot1 forms the second phase of the Wii boot process. While boot1 is stored in NAND and as such is theoretically updateable, due to the hash checking performed by boot0 it is only updateable on systems where the boot1 hash is not programmed into the eFuses. (Nintendo does actually use this capability to update boot1 on systems where it is possible, as certain SWUpdate packages for development units include a boot1 image.)

Boot1's purpose is either (depending on the version and 'debug boot' setting) to find boot2 on NAND and verify/load it, or to directly bootstrap the Broadway with a BS1 image.

If the running version of Boot1's purpose is loading boot2 from NAND, it will check the NAND's bad block map to determine which (if any) blocks to skip over, then start reading backwards from the end of the system area (the partition on NAND where boot1 and boot2 are stored) to find the first valid copy of boot2. A valid boot2 must be properly signed by Nintendo and have a greater or equal version number to that stored in the Wii's SEEPROM. If boot1 is unable to find a boot2 which meet these criteria, the system will halt.

Earlier versions of boot1 were vulnerable to the Trucha Bug, allowing for a self-signed boot2 to be inserted in place of the official one. This was patched along with the release of Bollywood.

boot2

boot2 forms the third phase of the Wii boot process. Boot2's purpose is to open the Wii System Menu (or whichever title is installed in the Wii System Menu's title ID "slot", 1-2)'s TMD and determine which version of IOP-OS (IOS) it requires, then reload into said version with instructions for it to bootstrap the Broadway and have it load the system menu title.

Earlier versions of boot2 were effectively merged with IOS, so rather than reloading into IOS, boot2 would begin bootstrapping the Broadway itself.

boot2 is the only part of the process which can be updated on production systems.

During the Wii Factory Process, a special boot2 known as "sd_boot" is used. This boot2 will verify and launch a BroadOn-format WAD from the SD card rather than continuing boot from NAND. sd_boot has an exploit in the SD reading code which allows for arbitrary code execution at coldboot with an SD card inserted, and as a retail signed sd_boot title is available which can be installed on any Wii (even Bollywood), this removes the previous restriction of not being able to run code (such as BootMii) as boot2 on newer Wiis.

IOS

IOS (referred to as "boot3" when being described as part of the boot process) forms the fourth phase of the Wii boot process. The loaded IOS depends on that which is specified by the System Menu title. All IOSes include a "ppcboot" functionality to bootstrap the Broadway with a set of instructions which allow it to load the System Menu.

In earlier versions of the Wii architecture, IOS was stored on the system area along with boot1 and boot2, as there was only one major version. However, IOS was later migrated to NAND and became a normal title like the System Menu and other installed titles.

System Menu

The final phase of the boot process is the Wii System Menu itself. This is the only phase of the process to run on the Broadway, and as such is the only one to produce video output (earlier phases can output via GPIOs and to the SD card, but not to the display device). The production System Menu will normally display the "Health & Safety" screen upon boot, although as any title can be installed as a system menu (such as the Startup Disc Menu or Devkit Boot Program), this is not consistent across all possible Wii configurations.

The production System Menu can also have different behaviours on boot, such as displaying the "Press A to continue" initial setup screen when a flag is not set in SYSCONF, or going into 'recovery mode' and displaying its version number on screen when a series of Waikiki commands are ran or all four directions are held down on the GameCube controller.

Once the user is past the initial Health & Safety screen, assuming that no further errors or discrepancies occur (such as the "System files are corrupted" error), the Wii is fully booted.