Difference between revisions of "IOS"
DesktopMan (talk | contribs) m (Removed duplicate info) |
|||
Line 53: | Line 53: | ||
fd is a pointer to uncached memory where the string describing the device or file to be manipulated is stored. | fd is a pointer to uncached memory where the string describing the device or file to be manipulated is stored. | ||
+ | no, fd is just some random "cookie" 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:45, 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
{ segher's shit -- please edit }
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 pointer to uncached memory where the string describing the device or file to be manipulated is stored.
no, fd is just some random "cookie" 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