IOS: Difference between revisions
No edit summary |
DesktopMan (talk | contribs) m Fixed fd description thanks to segher |
||
| Line 14: | Line 14: | ||
Here is a sample implementation, not guaranteed to work: [[ipc.c]] | Here is a sample implementation, not guaranteed to work: [[ipc.c]] | ||
ipc struct size = 40, aligned to 20 | ipc struct size = 40, aligned to 20 | ||
| Line 52: | Line 50: | ||
arg3: pointer to # in plus # out pairs of (addr, len) | arg3: pointer to # in plus # out pairs of (addr, len) | ||
fd is a | fd is a handle you get back from ios on "open", and that you should pass back to all other calls --segher | ||
Most non-trivial operations are performed by opening one of the below resources, then calling ioctl or ioctlv on it. | Most non-trivial operations are performed by opening one of the below resources, then calling ioctl or ioctlv on it. | ||
Revision as of 03:00, 15 February 2008
IOS is the operating system that runs on the Starlet coprocessor inside the Hollywood package. It provides the services that are used by Wii code to access most of the system devices.
IPC
Communication with IOS from PPC code is done using an IPC mechanism. There are 7 calls that can be made using this system:
- open
- close
- read
- write
- seek
- ioctl
- ioctlv
Here is a sample implementation, not guaranteed to work: ipc.c
ipc struct size = 40, aligned to 20
00: cmd // 1=open 2=close 3=read 4=write 5=seek 6=ioctl 7=ioctlv
04: ret
08: fd
0c: arg[5]
20: async1
24: async2
28: 0
open: fd = 0
arg0, arg1: name, mode (1=read 2=write)
close: fd
read: fd
arg0, arg1: addr, len
write: fd
arg0, arg1: addr, len
seek: fd
arg0, arg1: where, whence
ioctl: fd
arg0: ioctl #
arg1, arg2: addr, len
arg3, arg4: addr, len
ioctlv: fd
arg0: ioctl #
arg1: # in
arg2: # out
arg3: pointer to # in plus # out pairs of (addr, len)
fd is a handle you get back from ios on "open", and that you should pass back to all other calls --segher
Most non-trivial operations are performed by opening one of the below resources, then calling ioctl or ioctlv on it.
The Starlet kernel hands these calls over to the individual drivers / processes within the Starlet. The processes register themselves to handle requests by creating one or more queues and assigning them to handle requests from a particular /dev device.
/dev tree
Known resources in the /dev tree:
- /dev/aes
- /dev/boot2
- /dev/di
- /dev/es
- /dev/flash
- /dev/fs
- /dev/listen
- /dev/net/ip/bottom
- /dev/net/ip/top - TCP/IP Socket operations
- /dev/net/kd/request
- /dev/net/kd/time
- /dev/net/ncd/manage
- /dev/net/ssl
- /dev/net/usbeth/top
- /dev/net/wd/command
- /dev/net/wd/top
- /dev/printserver
- /dev/sdio
- /dev/sdio/slot0
- /dev/sdio/slot1
- /dev/sha
- /dev/stm/eventhook
- /dev/stm/immediate
- /dev/usb
- /dev/usb/ehc
- /dev/usb/kbd
- /dev/usb/oh0
- /dev/usb/oh1
- /dev/wl0