Wii:Boot Process: Difference between revisions

From ConsoleMods Wiki
Jump to navigation Jump to search
m (oops)
mNo edit summary
Line 28: Line 28:


fail0verflow (formally known as Team Twiizers) for their research on the Wii
fail0verflow (formally known as Team Twiizers) for their research on the Wii
[[Category:Wii]]

Revision as of 17:11, 7 June 2022

The Wii has 2 processors, a PowerPC chip codenamed the "Broadway" for running games and the system menu, and an ARM core that resides on the Hollywood (GPU) known as "Starlet". No code is actually ran on the Broadway until the System Menu is loaded. Boot0-2 and IOS runs on the Starlet. The boot process starts on the Starlet where boot0 is read from a One-Time Programmable ROM.

Boot0

Boot0 is about 1.5K of ROM. It's first actions are to read the area of NAND that Boot1 resides in, decrypts it, and hashes it. It compares the generated hash with a value hard-coded into the OTP ROM. If the hashes match, then the Starlet will load and execute Boot1. If the hashes for some reason do not match, such as the case in a low-level brick where boot1 is corrupt, then the Wii will halt, and the system will flash error codes through a debug port.

If the hash in OTP is all zeroes, then the Starlet will load Boot1 no matter what, this is for Devkits and possibly the manufacturing process.

Boot1

Boot1 has 96K of NAND reserved, but only uses about 17K. When Boot1 is loaded after being decrypted and verified by Boot0, it first initializes the external RAM of the Wii, then it decrypts Boot2 and performs RSA Verification. The first versions of the Wii had the signing bug present in Boot1, this allowed Boot2 to be fakesigned and replaced by something completely different, like BootMii. This bug was patched in Boot1 sometime in 2008, since then it's been impossible to replace any part of the Wii's Bootloader. Boot1 also attempts to detect downgrades of Boot2 by comparing the version of Boot2 with a value stored in the EEPROM. Boot1 will flash error codes across the debug port if an issue is encountered during the Boot2 loading process, such as corruption. If all goes well and Boot2 isn't corrupt, then Boot1 will load it.

Boot2

Once Boot2 has been loaded by Boot1, it loads the system menu's TMD and also loads the System Menu IOS, there is no signature checks or other verification for the System menu or it's IOS. This allows installing software such as Priiloader. Boot2 doesn't really do much as a bootloader, some say it's more so an IOS. Boot2 is even stored as a WAD, and has been updated in the 4.2 update which supposedly was a VERY buggy update that caused many Wii's to be low-level bricked.

System Menu IOS

The System Menu IOS is more of a complete operating system that oversees the Broadway and provides many IO functions such as USB, Networking, Security, etc. The System Menu IOS is still essential for booting a Wii and it being corrupt would render the Wii completely bricked, with only a certain number of Wiis being able to have software that fixes such brick. The IOS version that runs under System Menu 4.3 is IOS 80. The System Menu IOS loads the System Menu onto the Broadway and boots it. IOS can be swapped out with other versions in different slots, which is dependent on each individual title. WiiBrew is an excellent resource for reading more in depth about IOS.

The System Menu

The System Menu is the first visible user interface since it is the first thing that runs on the Broadway. It has higher privileges than most titles but itself is not an operating system, as IOS is still running underneath it and is doing most of the tasks an operating system does. When a game or other title is launched, the system menu is no longer running, and is only reloaded when a game or title is not in use.

References

Wiibrew for information about the boot process

fail0verflow (formally known as Team Twiizers) for their research on the Wii