Changes

{{TOCright}}

{{TOCright}}

:''Not to be confused with Apple's iOS, which runs on the iPhone, which was released half a year after the Wii, or [https://wiiubrew.org/wiki/IOSU IOSU], which runs on the Wii U, sometimes referred to as IOS.''

:''Not to be confused with [https://wiiubrew.org/wiki/IOSU IOSU], which runs on the Wii U, sometimes referred to as IOS.''

'''IOS''' (presumably an initialism for Independent Operating System) is the operating system that runs on the [[Hardware/Starlet|Starlet]] (IOP) coprocessor ([https://wiiubrew.org/wiki/Hardware/Starbuck Starbuck] on the [[vWii]]) inside the [[Hollywood]] package. It provides services that are used by Wii code to access many system devices: USB, networking, security, app management, NAND flash storage, SD card, optical disc, and also WiiConnect24 features.

'''IOS''' (sometimes internally referred to as '''IOP''' - possibly "Input Output Proxy") is the operating system that runs on the [[Hardware/Starlet|Starlet]] (IOP) coprocessor ([https://wiiubrew.org/wiki/Hardware/Starbuck Starbuck] on the [[vWii]]) inside the [[Hollywood]] package. It provides services that are used by Wii code to access many system devices: USB, networking, security, app management, NAND flash storage, SD card, optical disc, and also WiiConnect24 features.

All software using the Wii SDK or [[libogc]] relies on a running IOS on the Starlet (with a few exceptions in the latter case - it is possible to shut down IOS services from libogc and work without it). Typically, the only times IOS is not in use is when running GameCube software (which uses [[MIOS]] instead - effectively a dummy IOS), or when [[BootMii]] and related software is in use (which uses [[mini]] instead).

All software using the Wii [[SDK]] or [[libogc]] relies on a running IOS on the Starlet (with a few exceptions in the latter case - it is possible to shut down IOS services from libogc and work without it). Typically, the only times IOS is not in use is when running GameCube software (which uses [[MIOS]] instead - effectively a dummy IOS), or when [[BootMii]] and related software is in use (which uses [[mini]] instead).

 

IOS is versioned in a somewhat unique way. Instead of there being a single canonical version of IOS, there are multiple branches, each typically corresponding to one or more versions of the Wii SDK. Each branch is apparently specified to have a completely frozen API, and old versions are only updated to patch bugs (often security bugs) - Nintendo at one point created an entirely new IOS branch that differed only in the default value for the TCP buffer size. A fully updated Wii contains one copy of the latest version of each branch of IOS. On a Wii, these are installed as separate titles, often called "IOS slots". Due to this design, it is generally considered safe to uninstall, reinstall, or patch an IOS or IOS module, as long as it is not the slot used by the System Menu - if anything goes wrong, the broken version can be safely uninstalled and a vanilla copy reinstalled. IOS slots have title IDs 1-3 through 1-255. Unused (high) IOS slots are often used to install patched versions of IOS or alternative Starlet software (e.g. [[BootMii]] as IOS is installed as IOS254, which when invoked will subsequently load armboot.bin from the SD card, typically [[mini]]). See [[IOS History]] for a comprehensive list of IOS slots and versions.

IOS is not a "hypervisor", as it runs on a dedicated, separate CPU. However, IOS does isolate its memory from access by the main [[Hardware/Broadway|Broadway]] CPU, has the ability to reboot (and hence bootstrap) it, and is designed to be secure if the PowerPC side is compromised (although in practice many exploits have been found). In that sense, IOS is higher in the security hierarchy than code running on the PowerPC.

IOS is not a "hypervisor", as it runs on a dedicated, separate CPU. However, IOS does isolate its memory from access by the main [[Hardware/Broadway|Broadway]] CPU, has the ability to reboot (and hence bootstrap) it, and is designed to be secure if the PowerPC side is compromised (although in practice many exploits have been found). In that sense, IOS is higher in the security hierarchy than code running on the PowerPC.

Since the IOS API is largely forwards-compatible, it is often possible (though not recommended) to run official software with an alternate IOS branch or slot. Homebrew software will often run under a relatively large range of IOS versions, sometimes constrained by requiring newer features (e.g. USB EHCI support).

Since the IOS API is largely forwards-compatible, it is often possible (though not recommended) to run official software with an alternate IOS branch or slot; [[BC-NAND]] takes advantage of this so that IOS does not need to be reloaded a second time every time a [[title]] is launched. Homebrew software will often run under a relatively large range of IOS versions, sometimes constrained by requiring newer features (e.g. USB EHCI support).

When the Wii is in WiiConnect24 standby mode (yellow LED), the main PowerPC CPU is off, but IOS is still running.

When the Wii is in WiiConnect24 standby mode (yellow LED), the main PowerPC CPU is off, but IOS is still running.

== See Also ==

== See Also ==

*[[Talk:IOS/QA|IOS - Questions and Answers]]

*[[Talk:IOS/QA|IOS - Questions and Answers]]

*[[IOS History]]

*[[IOS History]]

*[[IOS/Syscalls|IOS Syscalls]]

*[[IOS/Syscalls|IOS Syscalls]]

*[[IOS/Syscall IDAPython|Syscall IDAPython]]

*[[IOS/Syscall IDAPython|Syscall IDAPython]]

*[[ARM Binaries]]

*[[ARM Binaries]]

*[[/vWii IOS List|vWii IOS List]]

*[[/vWii IOS List|vWii IOS List]]

== Architecture ==

== Architecture ==

=== Kernel ===

=== Kernel ===

The kernel is the piece of code that is launched first; it consists of a small ELF-loader header followed by the ELF executable of the kernel proper. In addition to the core microkernel and the cryptography core, it contains the bare minimum set of processes/drivers necessary to load the rest of the modules from the NAND filesystem: FFS (Flash Filesystem), ES (E-Ticket Services), and IOSP (responsible for booting and managing the Broadway and its IPC interface). Older IOS versions (prior to [[IOS28]]) were monolithic and contained all modules inside the single main ELF kernel. [[boot2]] is essentially a standalone IOS kernel with no additional modules or drivers, whose sole purpose is to locate the [[System Menu]]'s IOS and launch it.

The kernel is the piece of code that is launched first; it consists of a small ELF-loader header followed by the ELF executable of the kernel proper. In addition to the core microkernel and the cryptography core, it contains the bare minimum set of processes/drivers necessary to load the rest of the modules from the NAND filesystem: FFS (Flash Filesystem), ES (E-Ticket Services), and IOSP (responsible for booting and managing the Broadway and its IPC interface). Older IOS versions (prior to [[IOS28]]) were monolithic and contained all modules inside the single main ELF kernel. [[boot2]] is essentially a standalone IOS kernel with no additional modules or drivers, whose sole purpose is to locate the [[System Menu]]'s IOS and launch it.

# ioctlv

# ioctlv

There is one more cmd value (8) that is used for messages that are automatically sent to an IOS queue when an asynchronous syscall completes.

There is also a cmd value (8) that is used for messages that are automatically sent to an IOS queue when an asynchronous syscall completes, and another cmd value (9) used internally by [[IOSP]] to indicate that a new unprocessed message has arrived.

  ipc struct size = 0x40, aligned to 0x20

  ipc struct size = 0x40, aligned to 0x20

  08:    fd      // file handle returned by open that is passed to other calls

  08:    fd      // file handle returned by open that is passed to other calls

  0c:    arg[5]  // see below

  0c:    arg[5]  // see below

   

   

  open:  fd = 0

  open:  fd = 0

|-

|-

! PID !! Name !! Notes

! PID !! Name !! Notes

|-

|-

| 0 || Kernel ||

| 0 || Kernel ||

| 14 || STM ||

| 14 || STM ||

|-

|-

| 15 || PPCBOOT || Requests from the PPC (via the IPC mechanism) appear to come from this process.  

| 15 || PPCBOOT || The IPC server runs under this PID, meaning requests from the PPC (via the IPC mechanism) appear to come from this process.

|-

|-

| 16 || SSL ||

| 16 || SSL ||

|}

|}

Each process has an associated UID and GID, which can be only changed by the kernel or ES (PID <= 1). This is notably used to enforce filesystem permissions for requests coming from the PPC (PID 15), or to keep some resource managers and ioctls/ioctlvs internal to IOS itself.

Each process has an associated UID and GID, which can be only changed by the kernel or ES (PID <= 1). This is notably used to enforce filesystem permissions for requests coming from the PPC (PID 15), or to keep some resource managers and ioctls/ioctlvs internal to IOS itself. The UID assigned to PPCBOOT is identical to that listed in [[:/sys/uid.sys]] for the active title.

Each process's UID and GID default to their PID.

Each process's UID and GID default to their PID.

* [[:/dev/sha]]

* [[:/dev/sha]]

==== FFS ====

==== [[FS (IOS)|FS]] ====

Flash Filesystem

Flash Filesystem

* [[:/dev/flash]]

* [[:/dev/flash]]

* [[:/dev/fs]]

* [[:/dev/fs]]

==== ES ====

==== ES ====