Wii architecture overview

The Wii is a complicated and confusing piece of hardware for beginners to get to grips with - with equally confusing software. This short guide should allow you to get a better grasp of the Wii's functionality under the hood.

SDK and code sharing

The System Menu (aka Wii Menu) is ONLY the graphical interface between boot and starting a game or channel. No aspect of the System Menu is active when a game is started - everything that appears on your screen comes from the disc, as soon as you leave the System Menu, including the HOME Menu (which is why it behaves slightly differently in some games like Wii Fit - try pressing Reset in Wii Fit).

This does not mean that nothing is shared; internet-related menus such as EULA and rgnsel (country selection) are installed as hidden channels. This solves the problem the DS had with not being able to update the WiFi menu, but this solution was not available for the HOME Menu, as booting one of these shared menus requires the entire processor to reset.

NAND titles are also able to share more code; their TMD metadata allows them to put certain parts of themselves in /shared1 to save space on the internal flash memory. However, the shared entries are indexed by their hashes, so they cannot be updated.

Security

On a system where games have the entire processor, there is essentially no security once the user level has been compromised; this is what made the GameCube so easy to hack. BroadOn's solution was to add a second processor that runs operating systems known as IOSes.

IOSes are the software that control communications between the PPC and the Wii's hardware, via the ARM processor. To aid in backwards-compatibility, Nintendo decided that each IOS would have its own version number and be stored alongside all the other IOSes on the system. This means when they implement new functions into IOS, they don't have to test every game in existence - just roll out a new IOS. Each game, channel and System Menu chooses which IOS to run - if it is not installed, the Wii usually either crashes or returns to the system menu. This in practice is impossible without homebrew, as the system menu forces you to install updates from disc-based games before you can play them, and you can't access the shop channel without the latest update normally. This has obvious disadvantages that were many times exploited by homebrew - with so many IOSes, if a fatal bug is discovered in all of them, they take a long time to update, test, and deploy - and this has happened time and time again. Since homebrew can also reload into a different IOS version during runtime, a flaw in just one IOS can bring the entire system's security down. This also means that if somehow one IOS is expected but not installed, stuff will go wrong, including some games/channels not working, or bricking - these can only really happen by the cause of homebrew (mostly failpacks - see the next paragraph).

Common bugs from the distant past in IOSes that are constantly resurrected by very dangerous means (Wiibrew usually calls them failpacks, because they fail) to aid piracy include the Trucha bug and the ES_Identify bug - the first allows you to essentially bypass most of the Wii's signature checks (for example, so you can install any channel you want); the second allows you to become the "root user", "system administrator" or whatever you want to call it on the Wii. Nowadays, these are mostly used to aid piracy, but there are quite a few legitimate uses too - and so discussing and using these bugs is generally allowed, as long as you have the means to do it.

Nintendo and BroadOn eventually picked up a particularly nasty habit of "stubbing" IOSes no longer used - reducing them to a non-functional stub of what they used to be. This means that if you downgrade ONLY the System Menu without also downgrading its IOS, there is a strong chance of a brick.

Processors

The first thing you should know about the Wii in order to understand the rest of this guide is that it has two processors. The main one, the Broadway, is a PowerPC processor that does the job of running game code, and interfacing with all of the "legacy" hardware - basically everything the Gamecube has (with a few exceptions) are handled by the PowerPC. The Broadway is also called the PPC, because that is its architecture.

The other processor was kept quiet by Nintendo until Team Twiizers discovered it in their initial attempts at hacking into the Wii. It is physically located inside the Hollywood, the Wii's graphics chip - so it was nicknamed the Starlet. It is an ARM processor that communicates with the "new" hardware, as well as the DVD drive. The program that handles communication between the PPC and the hardware is known by everyone as IOS - see below. The Starlet is also called the ARM, because that is its architecture.

The reason for this dual-processor layout is security - before Wii Homebrew was possible, people still used Gamecube homebrew. However, Gamecube homebrew, because of this layout, could not access any of the Wii's hardware, as MIOS running on the ARM essentially locked down all of the Wii's hardware so it could not be used until a reboot occurred - it is thought to be impossible to break out of MIOS once it has started without also resetting the PPC, unless MIOS is patched.

NAND is term for the Wii's internal flash memory - it uses NAND flash, which is where the name comes from.

Boot loaders

Now after that brief introduction to Wii hardware, we come to the Wii software. First things first, we have the boot loaders. These are relatively simple to get your head around.

All three boot loaders are run on the ARM, way before anything actually appears on your screen - due to Nintendo's security, the ARM has no access to the screen at all.

boot0 is stored in ROM inside Hollywood - so it cannot easily be replaced. It is extremely simple, and its job is to check the hash of boot1 (a hash is code that "summarises" a particular binary - it is very easy to find the hash of a binary, but very difficult to find a binary that fits a certain hash), before booting boot1.

boot1 is stored in NAND, but its hash (checked by boot0, see above) is stored in OTP memory (one-time programmable) inside Hollywood, like boot0 - this essentially means that boot1 cannot be modified. Its job is to initialise the RAM, then perform a signature check of boot2 (see below). Making boot1 separate from boot2 allowed Nintendo to change the RAM of the Wii (which would then need slightly different initialisation) without changing Hollywood much - the OTP is programmed very late in Hollywood's production, as opposed to the ROM which is tightly ingrained into the chip.

boot2 is stored in NAND, as is its signature. It is a stripped down IOS. This is therefore responsible for initialising some of the Wii's hardware. It reads the System Menu's TMD (Title Metadata) to find out what IOS it needs, before booting that IOS.

System Menu

On boot, it is loaded by its own IOS as the first thing to run on the PPC. The System Menu is particularly prone to bricking - both relating to hardware and software. The following problems can brick the System Menu (which essentially bricks the Wii):

Bad or missing Bluetooth module, bad or missing WiFi module, bad DVD drive - cause a crash either before anything appears or just after the health warning starts to appear.
Channel with a corrupted banner installed - causes a crash on the Health and SAFETY screen (banner brick)
Region of the Wii changed without also installing the target region's system menu or vice versa (semibrick - displays an error message from Opera, either on boot or (if you're lucky) on the settings menu. Known on Korean Wiis to be displayed as a white screen with 3 black dots).
System menu or its IOS missing or damaged (black screen on boot - can be caused by installing an older system menu or a newer IOS)
Malicious bricking on Nintendo's part (the only known case is Error:003, which Korean Wiis display when they are running a non-korean System Menu 4.2 or newer - the system menu actively checks if it's a Korean Wii and crashes with this error if it is).
Large amount of mail (mail brick)

Signature checks

The IOS performs a signature check on any channel you are about to install, or boot2 when it is about to be booted. The Trucha Bug is the main way to work around this signature check - it has been exploited in the past for many things, and is exploited nowadays mainly to install BootMii as boot2.

BootMii, Priiloader and Custom IOSes

These three things have been touted as the custom firmware equivalent for the Wii. But what exactly are they?

BootMii replaces Nintendo's boot2, OR is installed as an IOS if this is not possible. It provides the following functions:

Full hardware access from the PPC via MINI
Backup and restore of Wii's NAND easily
(boot2 only) Easy way to access Homebrew Channel
(boot2 only) Virtually impenetrable brick protection

Priiloader moves the System menu, and installs itself where it used to be. It provides the following functions:

Easy way to access the Homebrew Channel or any other binary you may want to use
Easy way to patch the system menu with low chance of bricking - for example, to disable region checks or disc updates
Brick protection against a few of the bricks above (but not all)

Custom IOSes are IOSes with some extra functions enabled (eg USB 2.0 support), some unwanted security features disabled (for example, signature checks), or some features changed (for example, redirecting NAND access to an SD card). These are generally used for piracy and as such are not usually discussed on Wiibrew - although again, there are some legitimate uses.