Embedded Xinu - User contributions [en]

Coding style

2013-09-12T03:21:38Z

Ebiggers: Created page as redirect to Kernel Normal Form

#REDIRECT [[Kernel Normal Form]]

Mipsel-qemu

2013-09-12T02:59:53Z

Ebiggers: Say "virtual environment", not "emulation environment"

[[Embedded Xinu]] has been ported to the MIPSel virtual environment provided by [http://wiki.qemu.org/Main_Page QEMU]. This provides an easy way to run a basic Embedded Xinu environment on a RISC architecture without devoting "real" hardware.

== Building ==

[[Build Xinu|Compile Embedded Xinu]] with <code>PLATFORM=mipsel-qemu</code>. This will produce the file <code>xinu.boot</code> in the <code>compile/</code> directory.

== Running ==

qemu-system-mipsel -M mips -m 16M -kernel xinu.boot -nographic

== Notes ==

The mipsel-qemu platform does not yet support networking.

Qemu

2013-09-12T02:59:38Z

Ebiggers: Say "virtual environment", not "emulation environment"

[[Embedded Xinu]] has been ported to the following virtual environments provided by [http://wiki.qemu.org/Main_Page QEMU]:

* [[mipsel-qemu]] (Little-endian MIPS)

These platforms provide an easy way to run Embedded Xinu without devoting real hardware.

Mipsel-qemu

2013-09-12T02:58:02Z

Ebiggers: mipsel-qemu, not qemu-mipsel

[[Embedded Xinu]] has been ported to the MIPSel emulation environment provided by [http://wiki.qemu.org/Main_Page QEMU]. This provides an easy way to run a basic Embedded Xinu environment on a RISC architecture without devoting "real" hardware.

== Building ==

[[Build Xinu|Compile Embedded Xinu]] with <code>PLATFORM=mipsel-qemu</code>. This will produce the file <code>xinu.boot</code> in the <code>compile/</code> directory.

== Running ==

qemu-system-mipsel -M mips -m 16M -kernel xinu.boot -nographic

== Notes ==

The mipsel-qemu platform does not yet support networking.

List of supported platforms

2013-09-12T02:57:11Z

Ebiggers: mipsel-qemu, not qemu-mipsel

== Summary ==
This page lists the platforms currently supported by the Embedded Xinu operating system (or at least in development).

== Supported Platforms ==
{|border="1" cellpadding="5" cellspacing="0"
|-
!width="18%"|Platform
!width="15%"|Status
!Comments
|-
|[[WRT54GL|Linksys WRT54GL]] [http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1133202177241&pagename=Linksys%2FCommon%2FVisitorWrapper]
|Supported
|This is our primary development platform, on which Xinu has been tested thoroughly.
|-
|[[WRT54G|Linksys WRT54G]] v8 [http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1149562300349&pagename=Linksys%2FCommon%2FVisitorWrapper]
|Supported
|Tested and running at the Embedded Xinu Lab.
|-
|[[WRT54G|Linksys WRT54G]] v4 [http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1149562300349&pagename=Linksys%2FCommon%2FVisitorWrapper]
|Probably Supported
|The v4 is apparently the version on which WRT54GL is based, and so although the Embedded Xinu Lab has not explicitly tested it, it probably works.
|-
|[[WRT350N|Linksys WRT350N]] [http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1162354643512&pagename=Linksys%2FCommon%2FVisitorWrapper]
|Under Development
|Currently the synchronous [[UART Driver]] works.
|-
|[[WRT160NL|Linksys WRT160NL]] [http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1149562300349&pagename=Linksys%2FCommon%2FVisitorWrapper]
|Supported
|Newer model of router. Full O/S teaching core functioning, including wired network interface.
|-
|[[mipsel-qemu]] [http://www.qemu.org/]
|Supported
|Full O/S teaching core functioning, network support in progress.
|-
|[[Raspberry Pi]] [http://www.raspberrypi.org]
|Under Development
|Core operating system including wired networking is functional. Some new features are still being worked on, and the full documentation (e.g. for a laboratory setup) hasn't been completed yet.
|}

Qemu

2013-09-12T02:56:34Z

Ebiggers: mipsel-qemu, not qemu-mipsel

[[Embedded Xinu]] has been ported to the following emulation environments provided by [http://wiki.qemu.org/Main_Page QEMU]:

* [[mipsel-qemu]] (Little-endian MIPS)

These platforms provide an easy way to run Embedded Xinu without devoting real hardware.

Qemu-mipsel

2013-09-12T02:56:07Z

Ebiggers: Redirect to mipsel-qemu (platform name used in code)

#REDIRECT [[mipsel-qemu]]

Mipsel-qemu

2013-09-12T02:55:31Z

Ebiggers: Created page

[[Embedded Xinu]] has been ported to the MIPSel emulation environment provided by [http://wiki.qemu.org/Main_Page QEMU]. This provides an easy way to run a basic Embedded Xinu environment on a RISC architecture without devoting "real" hardware.

== Building ==

[[Build Xinu|Compile Embedded Xinu]] with <code>PLATFORM=qemu-mipsel</code>. This will produce the file <code>xinu.boot</code> in the <code>compile/</code> directory.

== Running ==

qemu-system-mipsel -M mips -m 16M -kernel xinu.boot -nographic

== Notes ==

The qemu-mipsel platform does not yet support networking.

Main Page

2013-09-12T02:55:01Z

Ebiggers: Link to mipsel-qemu

'''Embedded Xinu''' is an ongoing research and implementation project in the area of Operating Systems and Embedded Systems. Its original goal was to re-implement and port the [[Xinu|Xinu Operating System]] to several embedded MIPS platforms, such as the Linksys [[WRT54GL]] router. Since then, Embedded Xinu has been ported to other platforms, such as the [[mipsel-qemu|QEMU MIPSel virtual environment]] and the [[Raspberry Pi]]; see the [[list of supported platforms]]. Although Embedded Xinu is still being developed and ported to new platforms, a laboratory environment and curriculum materials are already in use for courses in Operating Systems, Hardware Systems, Embedded Systems, Networking, and Compilers at Marquette University and other colleges/universities.

The Embedded Xinu project was conceived and is supervised by [http://www.mscs.mu.edu/~brylow/ Dr. Dennis Brylow] and is being conducted by both graduate and undergraduate students in the [[Systems Laboratory]] in the [http://www.mscs.mu.edu/ Math, Statistics, & Computer Science] department of [http://www.mu.edu/ Marquette University] in Milwaukee, Wisconsin. The first major phase of work on Embedded Xinu began in the Summer of 2006.

Our project partners include [http://www.cse.buffalo.edu/~bina/ Dr. Bina Ramamurthy] at University of Buffalo (with whom we shared an [http://www.nsf.gov/pubs/2009/nsf09529/nsf09529.html NSF CCLI] grant), [http://cs.olemiss.edu/~ruth/wiki/doku.php Dr. Paul Ruth] at University of Mississippi, and [http://www.cs.purdue.edu/people/comer Dr. Doug Comer] (father of Xinu) at Purdue University.

== Teaching With Embedded Xinu ==

* For curriculum guidance on adopting or adapting Embedded Xinu for undergraduate coursework, see [[Teaching With Xinu]].
* Workshops have been held regarding teaching with Embedded Xinu. For example, the [http://www.cs.olemiss.edu/acmse2010/pdf/xinu.pdf Teaching With Embedded Xinu Workshop] at [http://www.cs.olemiss.edu/acmse2010/Home.htm ACMSE 2010] in Oxford, Mississippi (Ole Miss campus) shared ready-made curriculum resources that have been used successfully to teach hardware systems, operating systems, realtime/embedded systems, networking, and compilers with the Embedded Xinu platform at several colleges/universities.

== Building an Embedded Xinu Laboratory ==

In this section we are developing instructions so that other groups can benefit from the work we are doing. These guides can be followed more or less in order to create a relatively inexpensive platform for a custom operating system. As our work develops further, there will be more Xinu-specific information.

# Obtain a [[List of supported platforms|supported platform]].
# [[HOWTO:Modify the Linksys hardware|Modify the Linksys hardware]] or [[HOWTO:Modify the ASUS hardware|Modify the ASUS hardware]]
# [[HOWTO:Connect to a modified router|Connect to a modified router]]
# [[HOWTO:Build Xinu|Build Xinu]]
# [[HOWTO:Deploy Xinu|Deploy Xinu]]
# (Optional) [[HOWTO:Build Backend Pool|Build a pool of backends]]
# (Recommended) [[HOWTO:Backup your router|Backup your router's factory configuration]]

== Other Embedded Xinu Information ==

* MIPS [[processor]]
* Main [[memory]]
* [[Exception and Interrupt Handling]]
* [[UART driver]]
* [[TTY driver]]
* [[Switch driver]]
* [[Networking]]
* [[Flash memory]]
* [[Flashing firmware]]
* [[EJTAG|Enhanced Joint Test Action Group]] debugger
* [[Standard library]]
* [[XinuPhone]] Internet telephony
* [[Router Recovery]] aka "Debricking"
* [[Development]]
* [[Contributors]]

----

The Xinu Lab is brought to you in part by [[XMMS|M&M's]].
__NOTOC____NOEDITSECTION__

Qemu-mipsel

2013-09-12T02:52:59Z

Ebiggers: Wikify

[[Embedded Xinu]] has been ported to the MIPSel emulation environment provided by [http://wiki.qemu.org/Main_Page QEMU]. This provides an easy way to run a basic Embedded Xinu environment on a RISC architecture without devoting "real" hardware.

== Building ==

[[Build Xinu|Compile Embedded Xinu]] with <code>PLATFORM=qemu-mipsel</code>. This will produce the file <code>xinu.boot</code> in the <code>compile/</code> directory.

== Running ==

qemu-system-mipsel -M mips -m 16M -kernel xinu.boot -nographic

== Notes ==

The qemu-mipsel platform does not yet support networking.

List of supported platforms

2013-09-12T02:52:33Z

Ebiggers: Link to qemu-mipsel, not qemu

== Summary ==
This page lists the platforms currently supported by the Embedded Xinu operating system (or at least in development).

== Supported Platforms ==
{|border="1" cellpadding="5" cellspacing="0"
|-
!width="18%"|Platform
!width="15%"|Status
!Comments
|-
|[[WRT54GL|Linksys WRT54GL]] [http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1133202177241&pagename=Linksys%2FCommon%2FVisitorWrapper]
|Supported
|This is our primary development platform, on which Xinu has been tested thoroughly.
|-
|[[WRT54G|Linksys WRT54G]] v8 [http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1149562300349&pagename=Linksys%2FCommon%2FVisitorWrapper]
|Supported
|Tested and running at the Embedded Xinu Lab.
|-
|[[WRT54G|Linksys WRT54G]] v4 [http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1149562300349&pagename=Linksys%2FCommon%2FVisitorWrapper]
|Probably Supported
|The v4 is apparently the version on which WRT54GL is based, and so although the Embedded Xinu Lab has not explicitly tested it, it probably works.
|-
|[[WRT350N|Linksys WRT350N]] [http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1162354643512&pagename=Linksys%2FCommon%2FVisitorWrapper]
|Under Development
|Currently the synchronous [[UART Driver]] works.
|-
|[[WRT160NL|Linksys WRT160NL]] [http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1149562300349&pagename=Linksys%2FCommon%2FVisitorWrapper]
|Supported
|Newer model of router. Full O/S teaching core functioning, including wired network interface.
|-
|[[Qemu-mipsel]] [http://www.qemu.org/]
|Supported
|Full O/S teaching core functioning, network support in progress.
|-
|[[Raspberry Pi]] [http://www.raspberrypi.org]
|Under Development
|Core operating system including wired networking is functional. Some new features are still being worked on, and the full documentation (e.g. for a laboratory setup) hasn't been completed yet.
|}

Qemu

2013-09-12T02:51:52Z

Ebiggers:

[[Embedded Xinu]] has been ported to the following emulation environments provided by [http://wiki.qemu.org/Main_Page QEMU]:

* [[qemu-mipsel]] (Little-endian MIPS)

These platforms provide an easy way to run Embedded Xinu without devoting real hardware.

Qemu-mipsel

2013-09-12T02:50:10Z

Ebiggers: Created page with content from Qemu

Embedded Xinu has been ported to the MIPSel emulation environment provided by [http://wiki.qemu.org/Main_Page QEMU]. This provides an easy way to run a basic Embedded Xinu environment on a RISC architecture without devoting "real" hardware.

== Building ==

[[Build Xinu|Compile Embedded Xinu]] with <code>PLATFORM=qemu-mipsel</code>. This will produce the file <code>xinu.boot</code> in the <code>compile/</code> directory.

== Running ==

qemu-system-mipsel -M mips -m 16M -kernel xinu.boot -nographic

== Notes ==

The qemu-mipsel platform does not yet support networking.

Qemu

2013-09-12T02:49:04Z

Ebiggers: Created page

Networking

2013-09-12T02:41:51Z

Ebiggers: Link to TFTP and DHCP pages

= XINU Networking Features =
* [[TCP]]
* [[UDP]]
* [[ARP]]
* [[Routing]]
* [[ICMP]]
* [[TFTP client]] (development version only)
* [[DHCP client]] (development version only)

= Design =
The new network stack design does not have a NET device. The read and write device function paradigm does not map well to the network stack. TCP, UDP, and RAW sockets do not read from a network device, rather a network receive thread calls a chain of receive functions to process the packet at each layer in the network stack. A write function does not work well for sending a packet since the final destination of the packet is not known until the IP and/or ARP layers. The write device function assumes the thread calling write knows exactly which device to which the data should be written. A table of netif structures (separate from devtab, the table of devices) is still maintained to store configuration and accounting information for each underlying device (ETH, etc.) with which the network stack is receiving and sending packets.

A network interface is setup using the netUp command. An underlying device, IP address, mask, and gateway must be provided when calling netUp. DHCP functions as a separate process which runs before and netUp is called; DHCP interacts directly with the underlying device (ETH, etc.) without using the network stack.

Network receive threads continually read incoming packets from an underlying device. Each network interface has one or more network receive threads running. The netRecv function includes an infinite loop which reads a packet from the underlying device and calls ipRecv or arpRecv depending on the type of the packet. The packet is read into a buffer declared as a local variable within the netRecv function. At the IP layer ipRecv calls tcpRecv, udpRecv, rawRecv, or passes the packet to a routing thread. No sending of packets should ever occur under a network receive thread. For protocols in which an incoming packet may generate the need to send a reply packet, the protocol must have a separate thread for sending. For example, if an incoming TCP packet contains data which needs to be acknowledge, and tcpRecv should set a flag or send a message to a TCP monitor thread which will proceed to send the acknowledgement.

A global buffer pool is allocated for storing outgoing packets. One pool exists for use by all network interfaces. When sending a packet, the sending function (ex. tcpSend) obtains a buffer from the pool, calls the appropriate lower-level send function (ex. ipSend), and, after the function returns, returns the buffer to the pool.

The network stack is designed to treat the Xinu backend as both a router and a multi-homed host. Packets received on any of a backend's network interfaces may be destined for the backend or may need to be routed to another network destination. The network layer (IP layer) determines how to handle incoming packets. In the function ipRecv, the destination of an IP packet is compared against the IP address and broadcast address for every active network interface. If the destination address of the IP packet matches the IP address of the interface on which it was received or the IP address of any other network interface, the packet is passed to the appropriate transport layer receive function (udpRecv, tcpRecv, etc.). IP packets whose destination does not match with one of the active network interfaces are passed to the routing module of the network stack, i.e. the function rteRecv is called. In rteRecv the packet is copied into a buffer from the global buffer pool and placed on a queue for a routing thread to process. Currently, the network stack does not use a selective drop algorithm when the router is overloaded; once the queue of packets to route is full, all subsequent packets which require routing are dropped. A routing thread processes each packet on the routing queue. If no route is known, the packet is dropped; otherwise the TTL is decrement, the checksum is recalculated and the netSend function is called. Packets being sent from the transport layer (udpSend, tcpSend, etc) are not passed to the routing thread. The transport layer calls ipSend which performs a route table lookup, sets up the IP packet header and calls netSend.

== Network Graphic ==
* [[Media:XINUNetStack-Screen.jpeg]]
* [[Media:XINUNetStack-Print.jpeg]]
* [[Media:XINUNetStack.pdf]]
[[File:XINUNetStack-Screen.jpeg|border|500px]]

TFTP

2013-09-12T02:38:32Z

Ebiggers: Adjust external link

'''TFTP''' ('''Trivial File Transfer Protocol''') support has been added to [[Embedded Xinu]]. Currently, only client support--- that is, downloading files with TFTP Get requests--- is supported. The code is located in {{SourceFile|network/tftp/}}. The API includes the header {{SourceFile|include/tftp.h}} declaring <code>tftpGet()</code> and <code>tftpGetIntoBuffer()</code>. See the API documentation for more information.

Note that this page refers specifically to the TFTP client support built into [[Embedded Xinu]], which is completely separate from the TFTP support included in [[CFE]], which is third-party firmware.

== External Links ==

* [http://tools.ietf.org/html/rfc1350 RFC 1350: The TFTP Protocol (Revision 2)]

DHCP client

2013-09-12T02:37:30Z

Ebiggers: Created page as redirect to DHCP

#REDIRECT [[DHCP]]

DHCP

2013-09-12T02:37:10Z

Ebiggers: Created page

'''DHCP''' ('''Dynamic Host Configuration Protocol''') support has been added to Embedded Xinu. Currently, only IPv4 client support--- that is, acquiring IPv4 address information--- is supported. The code is located in {{SourceFile|network/dhcpc/}}. The API includes the header {{SourceFile|include/dhcpc.h}} declaring <code>dhcpClient()</code>. See the API documentation for more information.

Note that this page refers specifically to the DHCP client support built into Embedded Xinu, which is completely separate from the DHCP support included in CFE, which is third-party firmware.

== External links ==

* [http://www.ietf.org/rfc/rfc2131.txt RFC 2131: Dynamic Host Configuration Protocol]

TFTP

2013-09-12T02:33:35Z

Ebiggers:

TFTP client

2013-09-12T02:31:22Z

Ebiggers: Created page as redirect

#REDIRECT [[TFTP]]

TFTP

2013-09-12T02:30:57Z

Ebiggers: Created page

'''TFTP''' ('''Trivial File Transfer Protocol''') support has been added to Embedded Xinu. Currently, only client support--- that is, downloading files with TFTP Get requests--- is supported. The code is located in {{SourceFile|network/tftp/}}. The external interface includes the header {{SourceFile|include/tftp.h}} declaring <code>tftpGet()</code> and <code>tftpGetIntoBuffer()</code>. See the API documentation for more information.

== External Links ==

* http://tools.ietf.org/html/rfc1350

Main Page

2013-09-12T02:20:11Z

Ebiggers: Add link to contributors page

'''Embedded Xinu''' is an ongoing research and implementation project in the area of Operating Systems and Embedded Systems. Its original goal was to re-implement and port the [[Xinu|Xinu Operating System]] to several embedded MIPS platforms, such as the Linksys [[WRT54GL]] router. Since then, Embedded Xinu has been ported to other platforms, such as the QEMU-MIPSel virtual machine and the [[Raspberry Pi]]; see the [[list of supported platforms]]. Although Embedded Xinu is still being developed and ported to new platforms, a laboratory environment and curriculum materials are already in use for courses in Operating Systems, Hardware Systems, Embedded Systems, Networking, and Compilers at Marquette University and other colleges/universities.

The Embedded Xinu project was conceived and is supervised by [http://www.mscs.mu.edu/~brylow/ Dr. Dennis Brylow] and is being conducted by both graduate and undergraduate students in the [[Systems Laboratory]] in the [http://www.mscs.mu.edu/ Math, Statistics, & Computer Science] department of [http://www.mu.edu/ Marquette University] in Milwaukee, Wisconsin. The first major phase of work on Embedded Xinu began in the Summer of 2006.

Our project partners include [http://www.cse.buffalo.edu/~bina/ Dr. Bina Ramamurthy] at University of Buffalo (with whom we shared an [http://www.nsf.gov/pubs/2009/nsf09529/nsf09529.html NSF CCLI] grant), [http://cs.olemiss.edu/~ruth/wiki/doku.php Dr. Paul Ruth] at University of Mississippi, and [http://www.cs.purdue.edu/people/comer Dr. Doug Comer] (father of Xinu) at Purdue University.

== Teaching With Embedded Xinu ==

* For curriculum guidance on adopting or adapting Embedded Xinu for undergraduate coursework, see [[Teaching With Xinu]].
* Workshops have been held regarding teaching with Embedded Xinu. For example, the [http://www.cs.olemiss.edu/acmse2010/pdf/xinu.pdf Teaching With Embedded Xinu Workshop] at [http://www.cs.olemiss.edu/acmse2010/Home.htm ACMSE 2010] in Oxford, Mississippi (Ole Miss campus) shared ready-made curriculum resources that have been used successfully to teach hardware systems, operating systems, realtime/embedded systems, networking, and compilers with the Embedded Xinu platform at several colleges/universities.

== Building an Embedded Xinu Laboratory ==

In this section we are developing instructions so that other groups can benefit from the work we are doing. These guides can be followed more or less in order to create a relatively inexpensive platform for a custom operating system. As our work develops further, there will be more Xinu-specific information.

# Obtain a [[List of supported platforms|supported platform]].
# [[HOWTO:Modify the Linksys hardware|Modify the Linksys hardware]] or [[HOWTO:Modify the ASUS hardware|Modify the ASUS hardware]]
# [[HOWTO:Connect to a modified router|Connect to a modified router]]
# [[HOWTO:Build Xinu|Build Xinu]]
# [[HOWTO:Deploy Xinu|Deploy Xinu]]
# (Optional) [[HOWTO:Build Backend Pool|Build a pool of backends]]
# (Recommended) [[HOWTO:Backup your router|Backup your router's factory configuration]]

== Other Embedded Xinu Information ==

* MIPS [[processor]]
* Main [[memory]]
* [[Exception and Interrupt Handling]]
* [[UART driver]]
* [[TTY driver]]
* [[Switch driver]]
* [[Networking]]
* [[Flash memory]]
* [[Flashing firmware]]
* [[EJTAG|Enhanced Joint Test Action Group]] debugger
* [[Standard library]]
* [[XinuPhone]] Internet telephony
* [[Router Recovery]] aka "Debricking"
* [[Development]]
* [[Contributors]]

----

The Xinu Lab is brought to you in part by [[XMMS|M&M's]].
__NOTOC____NOEDITSECTION__

Embedded Xinu

2013-09-12T02:19:09Z

Ebiggers: Redirect to main page; no need to have "Embedded Xinu" page in wiki that is itself about Embedded Xinu (IMO)

#REDIRECT [[Main Page]]

Contributors

2013-09-12T02:18:28Z

Ebiggers: Created page (originally from "Embedded Xinu")

The following people are some of the contributors to [[Embedded Xinu]]:

* Dennis Brylow
* Paul Hinze
* Michael Schultz
* Justin Rawson
* Steve Luppi
* Anthony Stassi
* Mohammad "Meraj" Molla
* Aaron Gember
* Justin Picotte
* Adam Koehler
* Tyler Much
* Farzeen Harunani
* Eric Biggers

Xinupi

2013-09-12T02:13:27Z

Ebiggers: Redirect to XinuPi, not Raspberry Pi

#REDIRECT [[XinuPi]]

XinuPi

2013-09-12T02:08:00Z

Ebiggers:

'''XinuPi''' is the port of [[Embedded Xinu]] to the [[Raspberry Pi]]. XinuPi provides a simple, lightweight operating system for the Raspberry Pi that contains several orders of magnitude fewer lines of code than the Linux-based software stacks that normally run on the device. Its purpose is to provide an inexpensive, convenient platform for various areas of computer science education at a University level, including operating systems, embedded systems, networking, and programming languages. Another goal of XinuPi is to document some of the Raspberry Pi's hardware that has, until this point, been poorly documented or even undocumented. This includes the documentation on this Wiki as well as the XinuPi source code and the documentation generated from comments in it.

== Acquiring hardware ==

See [[Raspberry Pi]] for information about the hardware itself.

== Downloading and compiling ==

XinuPi is currently only available in source code form and only in the [[git|Embedded Xinu git repository]]. To obtain the code, install [http://git-scm.com/ git] and run:

git clone https://github.com/xinu-os/xinu
cd xinu

Note that this in fact the code for "Embedded Xinu" and not for "XinuPi" specifically. That is, the Raspberry Pi is one of several platforms that Embedded Xinu supports (and builds targeting it are referred to as "XinuPi").

To compile XinuPi, run:

make -C compile PLATFORM=arm-rpi

PLATFORM=arm-rpi is necessary to instruct the build system to target the Raspberry Pi. Additional arguments can be passed to ''make'', such as the COMPILER_ROOT to specify the location of a GCC compiler targeting ARM (defaults to "arm-none-eabi-", meaning that no explicit setting is needed if "arm-none-eabi-gcc" and the corresponding binutils are already on the shell $PATH). See {{SourceFile|compile/README.compiling}} for more details; for example, details about cross compilers.

The compilation process produces a file "compile/xinu.boot", which can be copied to "kernel.img" on the SD card of a Raspberry Pi to run it (see [[Raspberry Pi#Booting]]).

XinuPi is licensed under a BSD-style license; see the copyright information in the source distribution for more details.

== Features and implementation ==

* The core of XinuPi provides a preemptive multitasking operating system for the Raspberry Pi. See [[Preemptive multitasking (ARM)]] for more details about how Embedded Xinu implements preemptive multitasking on ARM-based platforms such as the Raspberry Pi; this includes information about thread creation and context switching. Also see [[BCM2835 System Timer]] for the timer on the Raspberry Pi that XinuPi uses to implement preemptive multitasking.
* Interrupt handling on the Raspberry Pi, required for the timer interrupt as well as many other devices, is described in [[Interrupt handling (Raspberry Pi)]].
* USB support was added to Embedded Xinu partly because of its important role in the Raspberry Pi, including to attach the Ethernet Controller on the Raspberry Pi Model B. See [[USB]] for general information about USB, or [[Synopsys DesignWare High-Speed USB 2.0 On-The-Go Controller]] for information specifically about the USB controller the Raspberry Pi provides.
* See [[SMSC LAN9512]] for information about the built-in USB Ethernet Adapter on the Raspberry Pi Model B, and XinuPi's driver for it.

TODO: sound, graphics, keyboard support

Preemptive Multitasking (ARM)

2013-09-12T02:01:09Z

Ebiggers:

This page documents how [[Embedded Xinu]] implements [[Preemptive multitasking|preemptive multitasking]] on [http://en.wikipedia.org/wiki/ARM_Architecture ARM-architecture] platforms that it has been ported to, such as the [[Raspberry Pi]].

== Thread context ==

The format and size of the [[Preemptive_multitasking#Multiple_threads|thread context]] used for ARM ports of Embedded Xinu rests on two factors: the registers available on the ARM architecture, and the standard ARM calling convention<ref>http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf</ref>:

* ARM processors have 16 "general-purpose" registers numbered r0-r15, as well as the Current Program Status Register (cpsr). However, despite being considered "general-purpose" registers, r13-r15 actually have special purposes; namely, r13 is used as the stack pointer (sp), r14 is used as the link register (lr), and r15 is used as the program counter (pc).

* The standard ARM calling convention specifies which registers are callee-save (r4-r11, r13-r14) and which are caller-save (r0-r3, r11), as well as how arguments are passed to procedures (up to four arguments in r0-r3; additional arguments spill onto stack).

The thread context we chose is 15 words long and is the following:

TODO

The ARM version of <code>ctxsw()</code> is implemented in {{SourceFile|system/arch/arm/ctxsw.S}} and contains a detailed explanation that will not be replicated here.

== Preemption ==

The means of generating a timer interrupt for [[Preemptive_multitasking#Preemption|preemption]] is not standard to the ARM architecture; instead, software must make use of a board-specific or chip-specific device such as the [[BCM2835 System Timer]].

== Notes ==

<references />

Preemptive multitasking

2013-09-12T01:57:15Z

Ebiggers:

Like virtually all modern operating systems, [[Embedded Xinu]] supports '''preemptive multitasking''', which makes it appear that multiple threads are executing at the same time on the same processor. Support for preemptive multitasking consists of support for multiple threads combined with a preemption mechanism.

== Multiple threads ==

Embedded Xinu supports multiple threads, but only one can execute at a time. A '''thread context''' refers to the saved state of a thread, primarily CPU registers. Embedded Xinu platforms must implement two functions to allow creating new threads and switching between threads using their thread contexts:

* <code>arch_setup_stack()</code>, which is responsible for setting up the stack of a new thread to include an initial thread context and procedure arguments. This routine is typically implemented in C. It is called internally by <code>create()</code>, located in {{SourceFile|system/create.c}}. For an example, see {{SourceFile|system/arch/mips/arch_setup_stack.c}}.
* <code>ctxsw()</code>, which is responsible for switching between threads. More specifically, this routine must save the thread context of the current thread and restore the thread context of the new thread. This routine is always implemented in assembly language. For an example, see {{SourceFile|system/arch/mips/ctxsw.S}}.

Since different CPU architectures use different registers and calling conventions,
the size and format of a thread context varies depending on the CPU architecture.
Note that since thread contexts are created in both <code>arch_setup_stack()</code> and <code>ctxsw()</code>, these two routines must create contexts that are compatible, at least to the extent that <code>ctxsw()</code> can either start a new thread or resume an existing thread.

Other articles describe this in more detail for specific architectures:

* [[Preemptive multitasking (ARM)]]
* [[Preemptive multitasking (MIPS)]]

== Preemption ==

Preemption occurs when the timer interrupt occurs and Embedded Xinu attempts to reschedule the currently executing thread, which results in a call to <code>ctxsw()</code>, described above, that may switch to a different thread context. (We say ''may'' because the code is written such that <code>ctxsw()</code> is called when the same thread is rescheduled to itself, in which case <code>ctxsw()</code> restores the saved context immediately and is a no-op.) The means of generating a timer interrupt is platform-dependent and may even differ among platforms that share the same CPU architecture. For an example, see [[BCM2835 System Timer]], which is used in the [[Raspberry Pi]], an ARM-based platform.

USB

2013-09-12T01:53:35Z

Ebiggers:

'''USB (Universal Serial Bus)''' is a standard for connecting devices to a computer system. It supports an immense range of devices, including (but not limited to) keyboards, mice, flash drives, microphones, and network adapters.

Although USB is ubiquitous in modern computer systems, even in some "embedded" devices, it is very challenging to implement software support for USB. This is primarily a result of the high complexity of USB, which arises from several factors, including support for virtually any arbitrary device, support for dynamic device attachment and detachment, backwards compatibility with multiple versions of the USB specification, and multiple supported speeds and transfer types. The USB 2.0 specification is 650 pages long, yet only covers a fraction of the information needed to implement, from scratch, a USB software stack and a driver controlling a specific USB device.

Due to the high complexity of USB, this article cannot fully explain USB, nor can it even fully explain Embedded Xinu's implementation of USB. Instead, it gives an overview of USB in the context of Embedded Xinu's implementation. For full details about USB, the reader will inevitably need to read the USB specification itself, as well as other relevant specifications and webpages. For full details specifically about Embedded Xinu's implementation, the reader will inevitably need to read the source code.

== Bus Topology ==

Fundamentally, USB is just a way to connect devices to a computer system. A USB bus accomplishes this by arranging devices in a tree. Each node of the tree is a '''USB device'''. There are two fundamental types of USB devices: '''hubs''' and '''functions'''. USB hubs can have "child" devices in the tree, while functions cannot. Hubs can be "children" of other hubs, up to a depth of 7 levels.

The root node of the tree is the '''root hub''', and every USB bus has one (although it may be faked by the Host Controller Driver, described later).

A USB hub provides a fixed number of attachment points for additional devices called '''ports'''. A USB port may be either completely internal or exposed to the "outside" as a place to plug in a USB cable. From the user's point of view there is certainly a difference between these two manifestations of a USB port, but from the software's point of view there is no difference. On a similar note, it is also possible that a single physical package, which a naive user might refer to as a "USB device", actually contains an integrated USB hub onto which one or more USB devices (as defined above) are attached. Such physical packages are referred to as '''compound devices'''. An example of a compound device is one of Apple's USB keyboards that provides a USB port to attach a mouse.

Since USB is a dynamic bus, USB devices can be attached or detached from the USB at any arbitrary time. Detaching a hub implies detaching all child devices.

For its part, Embedded Xinu's USB implementation fully supports the dynamic tree topology of a USB bus.

== Devices ==

Due to the generality of USB a USB device that is not a hub can be virtually anything at all. This is made possible in part by a highly nested design:

* A USB device has one or more '''configurations'''.
* A configuration has one or more '''interfaces'''.
* An interface has one or more '''alternate settings'''.
* An alternate setting has one or more '''endpoints'''.

Every device, configuration, interface, and endpoint has a corresponding '''descriptor''' that can be read by the USB software to retrieve information about the described entity in a standard format.

Although this format allows for highly complex devices, most devices are relatively simple and have just one configuration. Furthermore, common devices only have one interface. In fact, as of this writing, Embedded Xinu's USB subsystem aims to support the common case only; it therefore always sets the device to its first listed configuration, then attempts to bind a device driver to the entire device rather than examining individual interfaces to see if they need separate "interface drivers".

== Host Controllers ==

USB is a polled bus, so all transfers over the USB are initiated by the '''host'''. The term "host" in this context means the USB software as well as the USB Host Controller, which is the hardware responsible for actually sending and receiving data over the USB and maintaining the root hub. This is actually one of the trickier parts of USB. Since the USB specification itself does not standardize the exact division of tasks between software and hardware, it's often not clear who is responsible when the specification says "host".

The essential thing to know is that the place where the USB software directly meets the USB hardware is in the USB Host Controller Driver, which operates the USB Host Controller. Some USB Host Controllers present standard interfaces (such as UHCI, OHCI, or EHCI--- all defined in specifications separate from the USB specification itself) to software. Others do not present a standard interface, but instead have vendor-provided documentation and/or a vendor-provided driver; an example of this is the [[Synopsys DesignWare High-Speed USB 2.0 On-The-Go Controller]] used on the [[Raspberry Pi]]. Obviously, a standard interface is highly preferred when independently implementing a Host Controller Driver.

== Transfers ==

To communicate with USB devices, the host sends and receives data over the USB using USB transfers. A USB transfer occurs to or from a particular endpoint on a particular device. Every endpoint is associated with a specific type of USB transfer, which can be one of the following:

* '''Control''' transfers. These are typically used for device configuration. There are two main unique features of these transfers. First, a special packet called SETUP is always sent over the USB before the actual data of the control transfer, and software needs to specify the contents of this packet. Second, every device has an endpoint over which control transfers in either direction can be made, and this endpoint is never explicitly listed in the endpoint descriptors.
* '''Interrupt''' transfers. These are used for time-bounded transmission of small quantities of data (e.g. data from a keyboard or mouse).
* '''Bulk''' transfers. These are used for reliable (with error detection) transmission of large quantities of data with no particular time guarantees (e.g. reading and writing data on mass storage devices).
* '''Isochronous''' transfers. These are used for regular transmission of data with no error detecting (e.g. video capture).

Embedded Xinu currently supports control, interrupt, and bulk transfers. Isochronous transfers have not yet been tested. Although currently functional, interrupt transfers may require some more work to guarantee, in all cases, the time-bounded transmission required by the USB specification.

== Speeds ==

USB supports multiple transfer speeds:

* 1.5 Mbit/s (Low Speed) (USB 1+)
* 12 Mbit/s (Full Speed) (USB 1+)
* 480 Mbit/s (High Speed) (USB 2.0+)
* 5000 Mbit/s (Super Speed) (USB 3.0+)

Yes, Full Speed is in fact the second lowest speed. Well I think we all know that 12 Mbit/s ought to be enough for anyone. But anyway, due to the need to maintain backwards compatibility with legacy devices, the USB software (mainly the host controller driver) unfortunately needs to take into account transfer speeds. At minimum, it must be aware that transfers to or from devices attached at Low Speed or Full Speed are performed as a series of '''split transactions''', which allow Low Speed or Full Speed transfers to occur without significantly slowing down the portion of the USB bus operating at a higher speed.

As of this writing, Embedded Xinu's USB subsystem supports USB 2.0, so it supports devices operating at Low Speed, Full Speed, or High Speed. USB 3.0 Super Speed is not supported.

== Software Architecture ==

Now that some general information about USB has been presented, it should be easier to understand the basic design of a USB software stack. The description that follows is certainly not the only way to organize the code, but it is the way that is used in most operating systems and makes the most sense based on how USB was designed. In terms of Embedded Xinu, perhaps the main question is why USB devices and/or the USB controller do not show up as device(s) in 'devtab' like other Embedded Xinu devices. The reasons are that USB is a dynamic bus, so it cannot be described by a static table, and also because the highly nested structure of USB devices, as well as multiple supported transfer types, is too complicated for the simple "read() and write() from a device" paradigm.

* The '''USB Host Controller Driver''' is responsible for actually sending and receiving data over the USB by making use of the platform-dependent host controller hardware. The purpose of this driver is to isolate differences in USB host controllers from all other code dealing with USB. In Embedded Xinu, USB Host Controller Drivers must implement the interface declared in {{SourceFile|include/usb_hcdi.h}}. However, as of this writing, there is only one Host USB Controller Driver implemented and it controls the [[Synopsys DesignWare High-Speed USB 2.0 On-The-Go Controller]] used on the [[Raspberry Pi]]).
* The '''USB Core Driver''' is responsible for maintaining the USB device model, including the tree structure, and providing a framework in which USB device drivers can be written. It provides many convenience functions that simplify USB device driver development over using the Host Controller Driver directly; this can be viewed as an attempt to isolate the platform-dependent Host Controller Driver as much as possible. It also handles configuration that is common to all USB devices, such as setting a device configuration and address, and reading descriptors. In Embedded Xinu, the USB Core Driver can be found in {{SourceFile|device/usb/usbcore.c}}.
* '''USB device drivers''' are responsible for controlling specific USB devices. Since USB is a dynamic bus, USB device drivers are bound to actual USB devices at runtime with the help of USB Core Driver. A very important USB device driver that must always be implemented in any USB software stack is the '''USB hub driver''', which is responsible for monitoring the status of a USB hub and reporting to the USB Core Driver when devices have been attached or detached. Embedded Xinu's USB hub driver can be found in {{SourceFile|device/usb/usbhub.c}}. Other USB device drivers can be found in {{SourceFile|device/}}; e.g. {{SourceFile|device/smsc9512/}}.

Note: more complete (and complicated) USB software stacks, such as Linux's, also support '''USB interface drivers''', which are associated with USB interfaces rather than USB devices.

== Further reading ==

* USB 2.0 Specification. [http://www.usb.org/developers/docs/].
* USB 3.1 Specification. [http://www.usb.org/developers/docs/].
* Embedded Xinu USB 2.0 subsystem. (device/usb).
* Embedded Xinu USB device drivers. (Example: {{SourceFile|device/smsc9512}}).
* Embedded Xinu USB host controller drivers. (Example: {{SourceFile|system/platforms/arm-rpi/usb_dwc_hcd.c}}).

Synopsys DesignWare High-Speed USB 2.0 On-The-Go Controller

2013-09-12T01:50:24Z

Ebiggers:

The '''Synopsys DesignWare High-Speed USB 2.0 On-The-Go Controller''' is the [[USB]] controller used on the [[Raspberry Pi]]. This hardware is notorious for having no official documentation available to end users<ref>http://www.raspberrypi.org/phpBB3/viewtopic.php?f=72&t=27695</ref> and for having an extremely complicated, poorly written Linux driver. According to Greg Kroah-Hartman, the maintainer of Linux's USB subsystem<ref>http://lxr.linux.no/linux/MAINTAINERS</ref>:
<blockquote>
" ... it's just a really bad USB controller chip, combined with a
sad way to hook it up to the processor, combined with with a truly
horrible driver make for the fact that USB works at all on this board a
total miracle."<ref>http://lists.infradead.org/pipermail/linux-rpi-kernel/2012-September/000214.html</ref>
</blockquote>

This page attempts to explain this hardware in the context of the USB Host Controller Driver we wrote for it as part of the project to port Embedded Xinu to the Raspberry Pi. Unfortunately, it is not intended to ''fully'' document the hardware, since Embedded Xinu's driver is a relatively simple, stripped-down driver that does not support many features of the Linux driver.

== Overview of Embedded Xinu's driver ==

As mentioned, there is no documentation available for this USB Controller; therefore, it obviously was difficult to implement a driver for it. Since there was no other option, we had to gleam the relevant hardware details from other drivers, mainly the Linux driver<ref>See drivers/usb/host/dwc_otg/ in Raspberry Pi ports of Linux.</ref>, but also other drivers written for the controller, such as the CSUD driver<ref>https://github.com/Chadderz121/csud</ref> and the Plan 9 driver<ref>See 9/bcm/usbdwc.c in the Plan 9 sources</ref>. Our code, however, is a new implementation that is intended to be simple and well-documented, and appropriate (to the extent possible for USB and for this hardware) to include in a simple educational operating system.

Embedded Xinu's driver supports control, interrupt, and bulk transfers. As a Host Controller Driver, it implements the interface declared in {{SourceFile|include/usb_hcdi.h}}. For simplicity, Embedded Xinu's driver '''does not''' support some features of the Linux driver, including but not limited to the following:

* Device mode. The "On-The-Go" portion of the hardware's name means it supports the [https://en.wikipedia.org/wiki/USB_On-The-Go|USB On-The-Go protocol], which is an extension to the main USB specification that allows the USB hardware to operate in either "host" or "device" mode. However, in our driver we are only concerned with host mode.
* Isochronous transfers
* Support for instantiations of the silicon other than the one used on the Raspberry Pi
* Advanced transaction scheduling that takes into account special properties of periodic transfers
* Various module parameters to configure the driver
* Power management, including suspend and hibernation
* Slave or Descriptor DMA modes

== More details ==

More details about the device and the registers may eventually be added here. For now, see the source code ({{SourceFile|system/platforms/arm-rpi/usb_dwc_hcd.c}} and {{SourceFile|system/platforms/arm-rpi/usb_dwc_regs.h}}), which is intended to be easy to read and well documented. There is obviously a limit to how "easy to read" it can be, though, since [[USB]] itself is very complicated.

== Notes ==

<references />

BCM2835 System Timer

2013-09-12T01:48:52Z

Ebiggers:

The '''BCM2835 System Timer''' is a memory-mapped peripheral available on the [[BCM2835|BCM2835 System-on-a-Chip]] used in the [[Raspberry Pi]]. It features a 64-bit free-running counter that runs at 1 MHz and four separate "output compare registers" that can be used to schedule interrupts. However, two output compare registers are already used by the VideoCore GPU, leaving only two available for the ARM CPU to use.

== Hardware details ==

The interface to the BCM2835 System Timer is a set of 32-bit memory-mapped registers beginning at physical address 0x20003000.

{| class="wikitable"
|-
! Offset !! Name !! Description
|-
| +0x00 || CS || System Timer Control and Status
|-
| +0x04 || CLO || System Timer Counter Lower 32 bits
|-
| +0x08 || CHI || System Timer Counter Upper 32 bits
|- style="background: gray"
| +0x0C || C0 || System Timer Compare 0; corresponds to IRQ line 0.
|-
| +0x10 || C1 || System Timer Compare 1; corresponds to IRQ line 1.
|- style="background: gray"
| +0x14 || C2 || System Timer Compare 2; corresponds to IRQ line 2.
|-
| +0x18 || C3 || System Timer Compare 3; corresponds to IRQ line 3.
|-
|}

CLO and CHI form a 64-bit free-running counter, which increases by itself at a rate of 1 MHz, that software can read to get the current number of timer ticks. There are, however, two caveats:

* Appropriate [[BCM2835 Memory Barriers|memory barriers]] should be inserted to guarantee that read data is not re-ordered with that from a different peripheral.
* Reading CLO can be done in a single 32-bit access. However, we are not currently aware of a way to read CLO and CHI together atomically. To work around this when the full 64-bit time is desired, software can read CHI, then CLO, then read CHI and retry if CHI changed.

To schedule an interrupt using the System Timer, software can write the value of CLO at which an interrupt will be generated into one of the System Timer Compare registers. However, the CPU actually only use C1 and C3, since C0 and C2 are used by the GPU. Also, to actually receive the scheduled interrupt, the software must have previously enabled the corresponding IRQ line using the [[BCM2835 Interrupt Controller]]. To clear the interrupt, software must write 1 to the bit in CS that has the index the same as that of the System Timer Compare register. That is, to clear an interrupt set in C1, software must write 0x20 to CS, and to clear an interrupt set in C3, software must write 0x80 to CS.

== Use in Embedded Xinu ==

In the [[Raspberry Pi]] port of [[Embedded Xinu]], or [[XinuPi]], the BCM2835 System Timer is used to implement [[Preemptive_Multitasking_(ARM)|preemptive multitasking]] and keep the system time. The code can be found in {{SourceFile|system/platforms/arm-rpi/timer.c}} and is fairly simple, as it only needs to implement <code>clkcount()</code> and <code>clkupdate()</code>.

BCM2835 Interrupt Controller

2013-09-12T01:47:14Z

Ebiggers: Refer to XinuPi

The '''BCM2835 Interrupt Controller''' is a memory-mapped peripheral available on the [[BCM2835|BCM2835 System-on-a-Chip]] used in the [[Raspberry Pi]]. It allows software to enable or disable specific IRQs (interrupt requests). Each IRQ usually corresponds to some sort of device available on the chip.

== Hardware Details ==

It is important to understand that on the BCM2835, some IRQs are shared between the ARM CPU and VideoCore GPU. This interrupt controller controls ''both'' these shared IRQs as well as a few ARM-specific IRQs, and the layout of the registers reflects this separation. Some of the shared IRQs are already enabled by the GPU and therefore should not be enabled. However, this interrupt controller is only used by the ARM to control which interrupts actually get routed to the ARM; the GPU most likely has its own interrupt controller.

The BCM2835 Interrupt Controller is a memory-mapped peripheral available at physical memory address 0x2000B000. The following table describes the registers, each of which is 32 bits. '''Note that the offsets start at 0x200, not 0. We do this for consistency with Broadcom's documentation. To be completely clear, IRQ_basic_pending is located at physical memory address 0x2000B200.'''

{| class="wikitable"
|+ BCM2835 Interrupt Controller registers
|-
! Offset !! Name !! Description
|-
| 0x200 || IRQ_basic_pending || Bitmask of pending ARM-specific IRQs, as well as additional bits (not currently used by Embedded Xinu) to accelerate interrupt handling.
|-
| 0x204 || IRQ_pending_1 || Bitmask of pending shared IRQs 0-31
|-
| 0x208 || IRQ_pending_2 || Bitmask of pending shared IRQs 32-63
|-
| 0x20C || FIQ_control || TODO
|-
| 0x210 || Enable_IRQs_1 || Write 1 to the corresponding bit(s) to enable one or more shared IRQs in the range 0-31
|-
| 0x214 || Enable_IRQs_2 || Write 1 to the corresponding bit(s) to enable one or more shared IRQs in the range 32-63
|-
| 0x218 || Enable_Basic_IRQs || Write 1 to the corresponding bit(s) to enable one or more ARM-specific IRQs
|-
| 0x21C || Disable_IRQs_1 || Write 1 to the corresponding bit(s) to disable one or more shared IRQs in the range 0-31
|-
| 0x220 || Disable_IRQs_2 || Write 1 to the corresponding bit(s) to disable one or more shared IRQs in the range 32-63
|-
| 0x224 || Disable_Basic_IRQs || Write 1 to the corresponding bit(s) to disable one or more ARM-specific IRQs
|-
|}

For this interrupt controller to actually be of any use, the mapping of IRQs to devices must be known. The following table is an ''incomplete'' list that documents the IRQs we have tested in our work with Embedded Xinu. The full list can be found [https://github.com/raspberrypi/linux/blob/rpi-3.6.y/arch/arm/mach-bcm2708/include/mach/platform.h declared in a Linux header]. Below we use the numbering scheme used by both Embedded Xinu and Linux, where the shared IRQs are numbered 0-63, and ARM-specific IRQs are numbered starting at 64.

{| class="wikitable"
|+ Incomplete list of BCM2835 IRQs.
|-
! IRQ !! Device !! Notes
|-
| 0
| System Timer Compare Register 0
| Do ''not'' enable this IRQ; it's already used by the GPU.
|-
| 1
| System Timer Compare Register 1
| See [[BCM2835 System Timer]].
|-
| 2
| System Timer Compare Register 2
| Do ''not'' enable this IRQ; it's already used by the GPU.
|-
| 3
| System Timer Compare Register 3
| See [[BCM2835 System Timer]].
|-
| 9
| USB Controller
| This is the ''only'' USB IRQ because all communication with USB devices happens through the USB Controller. See [[Synopsys DesignWare High-Speed USB 2.0 On-The-Go Controller]].
|-
| 55
| PCM Audio
|
|-
| 57
| PL011 UART
| See [[PL011 UART]].
|-
| 62
| SD Host Controller
|
|}

Notes:

* Software cannot "clear" interrupts using the interrupt controller. Instead, interrupts must be cleared in a device-specific way.
* Although some shared interrupts appear in the IRQ_Basic_Pending register as well as in the IRQ_Pending_1 or IRQ_Pending_2 registers, they cannot be enabled or disabled in Enable_Basic_IRQs or Disable_Basic_IRQs.

== Use in Embedded Xinu ==

Embedded Xinu (that, is [[XinuPi]]) uses the BCM2835 Interrupt Controller to implement <code>enable_irq()</code> and <code>disable_irq()</code>. The code is in {{SourceFile|system/platforms/arm-rpi/dispatch.c}}. These functions simply are passed the number of the IRQ to enable or disable. Shared IRQs are numbered 0-63, while ARM-specific IRQs (currently not actually used) are numbered starting at 64. Also in this file you will find <code>dispatch()</code>, which is called from the assembly language IRQ handler in {{SourceFile|system/arch/arm/irq_handler.S}} to handle an interrupt. The point of <code>dispatch()</code> is to figure out which number IRQs are actually pending, then call the registered interrupt handler for each.

== External Links ==

* [http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf BCM2835 ARM Peripherals datasheet by Broadcom]. The interrupt controller is documented in Section 7 (p. 109-118). Compared to some of the Raspberry Pi hardware, this is one of the better documented components. Beware, though, that Broadcom's docs don't mention some of the important IRQ numbers, such as 0-3 (System Timer) and 9 (USB Controller).

BCM2835 Interrupt Controller

2013-09-12T01:46:23Z

Ebiggers: Use SourceFile template

The '''BCM2835 Interrupt Controller''' is a memory-mapped peripheral available on the [[BCM2835|BCM2835 System-on-a-Chip]] used in the [[Raspberry Pi]]. It allows software to enable or disable specific IRQs (interrupt requests). Each IRQ usually corresponds to some sort of device available on the chip.

== Hardware Details ==

It is important to understand that on the BCM2835, some IRQs are shared between the ARM CPU and VideoCore GPU. This interrupt controller controls ''both'' these shared IRQs as well as a few ARM-specific IRQs, and the layout of the registers reflects this separation. Some of the shared IRQs are already enabled by the GPU and therefore should not be enabled. However, this interrupt controller is only used by the ARM to control which interrupts actually get routed to the ARM; the GPU most likely has its own interrupt controller.

The BCM2835 Interrupt Controller is a memory-mapped peripheral available at physical memory address 0x2000B000. The following table describes the registers, each of which is 32 bits. '''Note that the offsets start at 0x200, not 0. We do this for consistency with Broadcom's documentation. To be completely clear, IRQ_basic_pending is located at physical memory address 0x2000B200.'''

{| class="wikitable"
|+ BCM2835 Interrupt Controller registers
|-
! Offset !! Name !! Description
|-
| 0x200 || IRQ_basic_pending || Bitmask of pending ARM-specific IRQs, as well as additional bits (not currently used by Embedded Xinu) to accelerate interrupt handling.
|-
| 0x204 || IRQ_pending_1 || Bitmask of pending shared IRQs 0-31
|-
| 0x208 || IRQ_pending_2 || Bitmask of pending shared IRQs 32-63
|-
| 0x20C || FIQ_control || TODO
|-
| 0x210 || Enable_IRQs_1 || Write 1 to the corresponding bit(s) to enable one or more shared IRQs in the range 0-31
|-
| 0x214 || Enable_IRQs_2 || Write 1 to the corresponding bit(s) to enable one or more shared IRQs in the range 32-63
|-
| 0x218 || Enable_Basic_IRQs || Write 1 to the corresponding bit(s) to enable one or more ARM-specific IRQs
|-
| 0x21C || Disable_IRQs_1 || Write 1 to the corresponding bit(s) to disable one or more shared IRQs in the range 0-31
|-
| 0x220 || Disable_IRQs_2 || Write 1 to the corresponding bit(s) to disable one or more shared IRQs in the range 32-63
|-
| 0x224 || Disable_Basic_IRQs || Write 1 to the corresponding bit(s) to disable one or more ARM-specific IRQs
|-
|}

For this interrupt controller to actually be of any use, the mapping of IRQs to devices must be known. The following table is an ''incomplete'' list that documents the IRQs we have tested in our work with Embedded Xinu. The full list can be found [https://github.com/raspberrypi/linux/blob/rpi-3.6.y/arch/arm/mach-bcm2708/include/mach/platform.h declared in a Linux header]. Below we use the numbering scheme used by both Embedded Xinu and Linux, where the shared IRQs are numbered 0-63, and ARM-specific IRQs are numbered starting at 64.

{| class="wikitable"
|+ Incomplete list of BCM2835 IRQs.
|-
! IRQ !! Device !! Notes
|-
| 0
| System Timer Compare Register 0
| Do ''not'' enable this IRQ; it's already used by the GPU.
|-
| 1
| System Timer Compare Register 1
| See [[BCM2835 System Timer]].
|-
| 2
| System Timer Compare Register 2
| Do ''not'' enable this IRQ; it's already used by the GPU.
|-
| 3
| System Timer Compare Register 3
| See [[BCM2835 System Timer]].
|-
| 9
| USB Controller
| This is the ''only'' USB IRQ because all communication with USB devices happens through the USB Controller. See [[Synopsys DesignWare High-Speed USB 2.0 On-The-Go Controller]].
|-
| 55
| PCM Audio
|
|-
| 57
| PL011 UART
| See [[PL011 UART]].
|-
| 62
| SD Host Controller
|
|}

Notes:

* Software cannot "clear" interrupts using the interrupt controller. Instead, interrupts must be cleared in a device-specific way.
* Although some shared interrupts appear in the IRQ_Basic_Pending register as well as in the IRQ_Pending_1 or IRQ_Pending_2 registers, they cannot be enabled or disabled in Enable_Basic_IRQs or Disable_Basic_IRQs.

== Use in Embedded Xinu ==

Embedded Xinu uses the BCM2835 Interrupt Controller to implement <code>enable_irq()</code> and <code>disable_irq()</code>. The code is in {{SourceFile|system/platforms/arm-rpi/dispatch.c}}. These functions simply are passed the number of the IRQ to enable or disable. Shared IRQs are numbered 0-63, while ARM-specific IRQs (currently not actually used) are numbered starting at 64. Also in this file you will find <code>dispatch()</code>, which is called from the assembly language IRQ handler in {{SourceFile|system/arch/arm/irq_handler.S}} to handle an interrupt. The point of <code>dispatch()</code> is to figure out which number IRQs are actually pending, then call the registered interrupt handler for each.

== External Links ==

* [http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf BCM2835 ARM Peripherals datasheet by Broadcom]. The interrupt controller is documented in Section 7 (p. 109-118). Compared to some of the Raspberry Pi hardware, this is one of the better documented components. Beware, though, that Broadcom's docs don't mention some of the important IRQ numbers, such as 0-3 (System Timer) and 9 (USB Controller).

Interrupt handling (ARM)

2013-09-12T01:44:06Z

Ebiggers: Use SourceFile template

This page provides an overview of how [[Embedded Xinu]] performs interrupt handling on [http://en.wikipedia.org/wiki/ARM_architecture ARM architectures]. This only concerns ARM-specific details; in particular it must be understood that the actual meaning prescribed to interrupts is determined using a board-specific mechanism, such as the [[BCM2835 Interrupt Controller]] on the [[Raspberry Pi]]. Furthermore, note that the ARM architecture and its exception/interrupt handling mechanisms are well documented by ARM Ltd., especially in various versions of the ''ARM Architecture Reference Manual''<ref>http://infocenter.arm.com/help/index.jsp</ref>. This page is only intended to give an overview of relevant details in the context of Embedded Xinu.

== IRQs and FIQs ==

=== Overview ===

ARM processors define two types of "interrupts":

* '''IRQs''' (Interrupt Requests). These are the "normal" type of interrupt.
* '''FIQs''' (Fast Interrupt Requests). These are an feature that software can optionally use to increase the speed and/or priority of interrupts from a specific source. For simplicity, Embedded Xinu does '''not''' use FIQs. However, FIQs could be useful for those looking to design real-time and embedded software on top of or instead of the base Embedded Xinu kernel.

Both IRQs and FIQs are examples of '''exceptions''' supported by the ARM. Beware that the term "IRQ" is often used generically, whereas here it specifically refers to the ARM-architecture IRQ exception.

=== Receiving an IRQ or FIQ ===

When the ARM receives an IRQ, it will enter a special '''IRQ mode''' and, by default, begin execution at physical memory address <code>0x18</code>. Similarly, when the ARM receives a FIQ, it will enter a special '''FIQ mode''' and, by default, begin execution at physical memory address <code>0x1C</code>. Before enabling IRQs or FIQs, software is expected to copy ARM instructions to the appropriate address. In the case of IRQs, there is only room for one ARM instruction, so it needs to be a branch instruction to a place where the full handler is stored. In Embedded Xinu, these special "glue" instructions, or '''exception vectors''', are set in {{SourceFile|loader/platforms/arm-rpi/start.S}}. The "full" IRQ handler is located in {{SourceFile|system/arch/arm/irq_handler.S}}.

=== Banked registers ===

In IRQ mode and FIQ modes, some registers are '''banked''', meaning that their contents are dependent on the current processor mode. The advantage of such registers is that their original values do not need to be explicitly saved by the interrupt handling code. FIQ mode banks more registers than IRQ mode, but both IRQ mode and FIQ mode bank the stack pointer (sp), which essentially means that each mode can use its own stack. However, for simplicity and consistency with other CPU architectures, Embedded Xinu does '''not''' use this capability. Instead, the interrupt handling code immediately switches the processor from IRQ mode to "System" mode, which is the mode in which Embedded Xinu normally operates the ARM CPU. This means that the interrupt handling code uses the stack of the currently executing thread, so perhaps the main disadvantage of this approach is that it increases the stack size required by each thread.

== Managing interrupts ==

The ARM responds to IRQs and FIQs if and only if bits 7 and 6, respectively, of the Current Program Status Register (<code>cpsr</code>) are 0. By default (after reset) these bits are both 1, so software must initially set them to 0 to enable IRQs and FIQs. Similarly, software can set them to 1 if it needs to disable IRQs and FIQs. However, software does not necessarily need to explicitly manipulate these bits because an alternate instruction named <code>cps</code> (Change Program State) is available that can handle changing these bits, as well as changing processor modes.

Below we explain the <code>enable()</code>, <code>disable()</code>, and <code>restore()</code> functions used by Embedded Xinu to manage interrupts. These are all implemented in the ARM assembly language file {{SourceFile|system/arch/arm/intutils.S}}.

=== <code>enable()</code> ===

<code>enable()</code> allows the processor to receive IRQ exceptions.

<nowiki>
enable:
cpsie i
mov pc, lr</nowiki>

<code>enable()</code> executes the <code>cpsie</code> ("Change Program State Interrupt Enable") instruction to enable IRQs. (Recall that FIQs are not used by Embedded Xinu.) It then overwrites the program counter (<code>pc</code>) with the link register (<code>lr</code>) to return from the function. Note that since the second instruction is merely overhead of a function call, <code>enable()</code> could instead be efficiently implemented as an inline function containing inline assembly.

=== <code>disable()</code> ===

<code>disable()</code> blocks IRQ exceptions and returns a value that can be passed to <code>restore()</code> to restore the previous state. The previous state may be either IRQs disabled or IRQs enabled. Note that an IRQ exception received during a region of code where interrupts are <code>disable()</code>d is not lost; instead, it remains pending until IRQs are re-enabled.

<nowiki>
disable:
mrs r0, cpsr
cpsid i
mov pc, lr</nowiki>

<code>disable()</code> copies the <code>cpsr</code> (Current Program Status Register) into <code>r0</code>, which as per the ARM calling convention<ref>http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf</ref> is the return value of the function. Therefore, the <code>cpsr</code> is treated as the value that can be passed to <code>restore()</code> to restore the previous interrupt state. The code then executes the <code>cpsid</code> (Change Program State Interrupt Disable) instruction to actually disable the IRQ exception.

=== <code>restore()</code> ===

<code>restore()</code> restores the IRQ exceptions disabled/enabled state to the state before a previous call to <code>disable()</code>.

<nowiki>
restore:
msr cpsr_c, r0
mov pc, lr</nowiki>

As per the ARM calling convention<ref>http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf</ref>, the argument to <code>restore()</code> (the previous state value--- in the code this is often stored in a variable named <code>im</code>, for "interrupt mask") is passed in <code>r0</code>. <code>r0</code> is then copied to the <code>cpsr</code> (Current Program Status Register), which is the opposite of what <code>disable()</code> does. <code>restore()</code> then overwrites the program counter with the link register to return from the function. Note that since the second instruction is merely overhead of a function call, <code>restore()</code> could instead be efficiently implemented as an inline function containing inline assembly.

== Further reading ==

As mentioned in the introduction, this page deals with ARM-architecture details only and therefore does not provide a full explanation of interrupt handling on any specific platform, which typically requires the use of some interrupt controller to actually assign meaning to IRQ exceptions.

* The interrupt controller on the [[Raspberry Pi]] is the [[BCM2835 Interrupt Controller]].

== Notes ==

<references />

Template:SourceFile

2013-09-12T01:41:23Z

Ebiggers: Created template

[https://github.com/xinu-os/xinu/tree/master/{{{1}}} {{{1}}}]

Git

2013-09-12T01:36:27Z

Ebiggers:

Embedded Xinu previously used a [[Subversion]] repository, but in 2013 switched to [http://git-scm.com/ git] as the preferred method of development.

The official public repository is hosted on Github. To get the code, install git and run:

git clone <nowiki>https://github.com/xinu-os/xinu</nowiki>

This will generate the directory <code>xinu/</code> containing a local copy of the repository. Note that this is a standalone repository that can be used without Internet access to the Github repository. This constitutes a difference from Subversion, which is more centralized.

Git is documented extensively in many locations, for example in the [http://git-scm.com/book "Pro Git" book]. But briefly, a very basic workflow is to modify files, use <code>git add</code> and <code>git commit</code> or <code>git commit -a</code> to commit the changes to the repository, then use <code>git push</code> to push changes to a remote repository.

Branches in git are fast and easy to use, so please develop experimental features in their own branches. Code pushed to the "master" branch should not be broken.

XinuPi

2013-09-11T22:48:30Z

Ebiggers: Fix broken link

'''XinuPi''' is the port of [[Embedded Xinu]] to the [[Raspberry Pi]]. XinuPi provides a simple, lightweight operating system for the Raspberry Pi that contains several orders of magnitude fewer lines of code than the Linux-based software stacks that normally run on the device. Its purpose is to provide an inexpensive, convenient platform for various areas of computer science education at a University level, including operating systems, embedded systems, networking, and programming languages. Another goal of XinuPi is to document some of the Raspberry Pi's hardware that has, until this point, been poorly documented or even undocumented. This includes the documentation on this Wiki as well as the XinuPi source code and the documentation generated from comments in it.

== Acquiring hardware ==

See [[Raspberry Pi]] for information about the hardware itself.

== Downloading and compiling ==

XinuPi is currently only available in source code form and only in the [[git|Embedded Xinu git repository]]. To obtain the code, install [http://git-scm.com/ git] and run:

git clone https://github.com/xinu-os/xinu
cd xinu

Note that this in fact the code for "Embedded Xinu" and not for "XinuPi" specifically. That is, the Raspberry Pi is one of several platforms that Embedded Xinu supports (and builds targeting it are referred to as "XinuPi").

To compile XinuPi, run:

make -C compile PLATFORM=arm-rpi

PLATFORM=arm-rpi is necessary to instruct the build system to target the Raspberry Pi. Additional arguments can be passed to ''make'', such as the COMPILER_ROOT to specify the location of a GCC compiler targeting ARM (defaults to "arm-none-eabi-", meaning that no explicit setting is needed if "arm-none-eabi-gcc" and the corresponding binutils are already on the shell $PATH). See compile/README.compiling for more details; for example, details about cross compilers.

The compilation process produces a file "compile/xinu.boot", which can be copied to "kernel.img" on the SD card of a Raspberry Pi to run it (see [[Raspberry Pi#Booting]]).

XinuPi is licensed under a BSD-style license; see the copyright information in the source distribution for more details.

== Features and implementation ==

* The core of XinuPi provides a preemptive multitasking operating system for the Raspberry Pi. See [[Preemptive multitasking (ARM)]] for more details about how Embedded Xinu implements preemptive multitasking on ARM-based platforms such as the Raspberry Pi; this includes information about thread creation and context switching. Also see [[BCM2835 System Timer]] for the timer on the Raspberry Pi that XinuPi uses to implement preemptive multitasking.
* Interrupt handling on the Raspberry Pi, required for the timer interrupt as well as many other devices, is described in [[Interrupt handling (Raspberry Pi)]].
* USB support was added to Embedded Xinu partly because of its important role in the Raspberry Pi, including to attach the Ethernet Controller on the Raspberry Pi Model B. See [[USB]] for general information about USB, or [[Synopsys DesignWare High-Speed USB 2.0 On-The-Go Controller]] for information specifically about the USB controller the Raspberry Pi provides.
* See [[SMSC LAN9512]] for information about the built-in USB Ethernet Adapter on the Raspberry Pi Model B, and XinuPi's driver for it.

TODO: sound, graphics, keyboard support

Xinu

2013-09-11T22:45:40Z

Ebiggers: Bold words; make Embedded Xinu goals more accurate

'''Xinu''' ('''"Xinu is not unix"''') is a small, academic operating system to teach the concepts of operating systems to students. Developed at Purdue University by Dr. Douglas E. Comer in the early 1980s for the LSI-11 platform, it has now been ported to a variety of platforms.

'''Embedded Xinu''' is an update of this project which attempts to modernize the code base and port the system to modern architectures such as MIPS, while keeping the original goals of teaching operating system concepts to students.

Main Page

2013-09-11T22:40:52Z

Ebiggers: Be more specific in intro

'''Embedded Xinu''' is an ongoing research and implementation project in the area of Operating Systems and Embedded Systems. Its original goal was to re-implement and port the [[Xinu|Xinu Operating System]] to several embedded MIPS platforms, such as the Linksys [[WRT54GL]] router. Since then, Embedded Xinu has been ported to other platforms, such as the QEMU-MIPSel virtual machine and the [[Raspberry Pi]]; see the [[list of supported platforms]]. Although Embedded Xinu is still being developed and ported to new platforms, a laboratory environment and curriculum materials are already in use for courses in Operating Systems, Hardware Systems, Embedded Systems, Networking, and Compilers at Marquette University and other colleges/universities.

The Embedded Xinu project was conceived and is supervised by [http://www.mscs.mu.edu/~brylow/ Dr. Dennis Brylow] and is being conducted by both graduate and undergraduate students in the [[Systems Laboratory]] in the [http://www.mscs.mu.edu/ Math, Statistics, & Computer Science] department of [http://www.mu.edu/ Marquette University] in Milwaukee, Wisconsin. The first major phase of work on Embedded Xinu began in the Summer of 2006.

Our project partners include [http://www.cse.buffalo.edu/~bina/ Dr. Bina Ramamurthy] at University of Buffalo (with whom we shared an [http://www.nsf.gov/pubs/2009/nsf09529/nsf09529.html NSF CCLI] grant), [http://cs.olemiss.edu/~ruth/wiki/doku.php Dr. Paul Ruth] at University of Mississippi, and [http://www.cs.purdue.edu/people/comer Dr. Doug Comer] (father of Xinu) at Purdue University.

== Teaching With Embedded Xinu ==

* For curriculum guidance on adopting or adapting Embedded Xinu for undergraduate coursework, see [[Teaching With Xinu]].
* Workshops have been held regarding teaching with Embedded Xinu. For example, the [http://www.cs.olemiss.edu/acmse2010/pdf/xinu.pdf Teaching With Embedded Xinu Workshop] at [http://www.cs.olemiss.edu/acmse2010/Home.htm ACMSE 2010] in Oxford, Mississippi (Ole Miss campus) shared ready-made curriculum resources that have been used successfully to teach hardware systems, operating systems, realtime/embedded systems, networking, and compilers with the Embedded Xinu platform at several colleges/universities.

== Building an Embedded Xinu Laboratory ==

In this section we are developing instructions so that other groups can benefit from the work we are doing. These guides can be followed more or less in order to create a relatively inexpensive platform for a custom operating system. As our work develops further, there will be more Xinu-specific information.

# Obtain a [[List of supported platforms|supported platform]].
# [[HOWTO:Modify the Linksys hardware|Modify the Linksys hardware]] or [[HOWTO:Modify the ASUS hardware|Modify the ASUS hardware]]
# [[HOWTO:Connect to a modified router|Connect to a modified router]]
# [[HOWTO:Build Xinu|Build Xinu]]
# [[HOWTO:Deploy Xinu|Deploy Xinu]]
# (Optional) [[HOWTO:Build Backend Pool|Build a pool of backends]]
# (Recommended) [[HOWTO:Backup your router|Backup your router's factory configuration]]

== Other Embedded Xinu Information ==

* MIPS [[processor]]
* Main [[memory]]
* [[Exception and Interrupt Handling]]
* [[UART driver]]
* [[TTY driver]]
* [[Switch driver]]
* [[Networking]]
* [[Flash memory]]
* [[Flashing firmware]]
* [[EJTAG|Enhanced Joint Test Action Group]] debugger
* [[Standard library]]
* [[XinuPhone]] Internet telephony
* [[Router Recovery]] aka "Debricking"
* [[Development]]

----

The Xinu Lab is brought to you in part by [[XMMS|M&M's]].
__NOTOC____NOEDITSECTION__

Main Page

2013-09-11T22:39:52Z

Ebiggers: Don't have ugly red link on main page

'''Embedded Xinu''' is an ongoing research and implementation project in the area of Operating Systems and Embedded Systems. Its original goal was to re-implement and port the [[Xinu|Xinu Operating System]] to several embedded MIPS platforms, such as the Linksys [[WRT54GL]] router. Since then, Embedded Xinu has been ported to other platforms, such as the QEMU-MIPSel virtual machine and the [[Raspberry Pi]]; see the [[list of supported platforms]]. Although Embedded Xinu is still being developed and ported to new platforms, a laboratory environment and curriculum materials are already in use for courses in Operating Systems, Hardware Systems, Embedded Systems, Networking, and Compilers at Marquette University and other locations.

The Embedded Xinu project was conceived and is supervised by [http://www.mscs.mu.edu/~brylow/ Dr. Dennis Brylow] and is being conducted by both graduate and undergraduate students in the [[Systems Laboratory]] in the [http://www.mscs.mu.edu/ Math, Statistics, & Computer Science] department of [http://www.mu.edu/ Marquette University] in Milwaukee, Wisconsin. The first major phase of work on Embedded Xinu began in the Summer of 2006.

Our project partners include [http://www.cse.buffalo.edu/~bina/ Dr. Bina Ramamurthy] at University of Buffalo (with whom we shared an [http://www.nsf.gov/pubs/2009/nsf09529/nsf09529.html NSF CCLI] grant), [http://cs.olemiss.edu/~ruth/wiki/doku.php Dr. Paul Ruth] at University of Mississippi, and [http://www.cs.purdue.edu/people/comer Dr. Doug Comer] (father of Xinu) at Purdue University.

== Teaching With Embedded Xinu ==

* For curriculum guidance on adopting or adapting Embedded Xinu for undergraduate coursework, see [[Teaching With Xinu]].
* Workshops have been held regarding teaching with Embedded Xinu. For example, the [http://www.cs.olemiss.edu/acmse2010/pdf/xinu.pdf Teaching With Embedded Xinu Workshop] at [http://www.cs.olemiss.edu/acmse2010/Home.htm ACMSE 2010] in Oxford, Mississippi (Ole Miss campus) shared ready-made curriculum resources that have been used successfully to teach hardware systems, operating systems, realtime/embedded systems, networking, and compilers with the Embedded Xinu platform at several colleges/universities.

== Building an Embedded Xinu Laboratory ==

In this section we are developing instructions so that other groups can benefit from the work we are doing. These guides can be followed more or less in order to create a relatively inexpensive platform for a custom operating system. As our work develops further, there will be more Xinu-specific information.

# Obtain a [[List of supported platforms|supported platform]].
# [[HOWTO:Modify the Linksys hardware|Modify the Linksys hardware]] or [[HOWTO:Modify the ASUS hardware|Modify the ASUS hardware]]
# [[HOWTO:Connect to a modified router|Connect to a modified router]]
# [[HOWTO:Build Xinu|Build Xinu]]
# [[HOWTO:Deploy Xinu|Deploy Xinu]]
# (Optional) [[HOWTO:Build Backend Pool|Build a pool of backends]]
# (Recommended) [[HOWTO:Backup your router|Backup your router's factory configuration]]

== Other Embedded Xinu Information ==

* MIPS [[processor]]
* Main [[memory]]
* [[Exception and Interrupt Handling]]
* [[UART driver]]
* [[TTY driver]]
* [[Switch driver]]
* [[Networking]]
* [[Flash memory]]
* [[Flashing firmware]]
* [[EJTAG|Enhanced Joint Test Action Group]] debugger
* [[Standard library]]
* [[XinuPhone]] Internet telephony
* [[Router Recovery]] aka "Debricking"
* [[Development]]

----

The Xinu Lab is brought to you in part by [[XMMS|M&M's]].
__NOTOC____NOEDITSECTION__

XinuPi

2013-09-11T22:38:41Z

Ebiggers: /* Downloading and compiling */

'''XinuPi''' is the port of [[Embedded Xinu]] to the [[Raspberry Pi]]. XinuPi provides a simple, lightweight operating system for the Raspberry Pi that contains several orders of magnitude fewer lines of code than the Linux-based software stacks that normally run on the device. Its purpose is to provide an inexpensive, convenient platform for various areas of computer science education at a University level, including operating systems, embedded systems, networking, and programming languages. Another goal of XinuPi is to document some of the Raspberry Pi's hardware that has, until this point, been poorly documented or even undocumented. This includes the documentation on this Wiki as well as the XinuPi source code and the documentation generated from comments in it.

== Acquiring hardware ==

See [[Raspberry Pi]] for information about the hardware itself.

== Downloading and compiling ==

XinuPi is currently only available in source code form and only in the [[git|Embedded Xinu git repository]]. To obtain the code, install [http://git-scm.com/ git] and run:

git clone https://github.com/xinu-os/xinu
cd xinu

Note that this in fact the code for "Embedded Xinu" and not for "XinuPi" specifically. That is, the Raspberry Pi is one of several platforms that Embedded Xinu supports (and builds targeting it are referred to as "XinuPi").

To compile XinuPi, run:

make -C compile PLATFORM=arm-rpi

PLATFORM=arm-rpi is necessary to instruct the build system to target the Raspberry Pi. Additional arguments can be passed to ''make'', such as the COMPILER_ROOT to specify the location of a GCC compiler targeting ARM (defaults to "arm-none-eabi-", meaning that no explicit setting is needed if "arm-none-eabi-gcc" and the corresponding binutils are already on the shell $PATH). See compile/README.compiling for more details; for example, details about cross compilers.

The compilation process produces a file "compile/xinu.boot", which can be copied to "kernel.img" on the SD card of a Raspberry Pi to run it (see [[#Booting]]).

XinuPi is licensed under a BSD-style license; see the copyright information in the source distribution for more details.

== Features and implementation ==

* The core of XinuPi provides a preemptive multitasking operating system for the Raspberry Pi. See [[Preemptive multitasking (ARM)]] for more details about how Embedded Xinu implements preemptive multitasking on ARM-based platforms such as the Raspberry Pi; this includes information about thread creation and context switching. Also see [[BCM2835 System Timer]] for the timer on the Raspberry Pi that XinuPi uses to implement preemptive multitasking.
* Interrupt handling on the Raspberry Pi, required for the timer interrupt as well as many other devices, is described in [[Interrupt handling (Raspberry Pi)]].
* USB support was added to Embedded Xinu partly because of its important role in the Raspberry Pi, including to attach the Ethernet Controller on the Raspberry Pi Model B. See [[USB]] for general information about USB, or [[Synopsys DesignWare High-Speed USB 2.0 On-The-Go Controller]] for information specifically about the USB controller the Raspberry Pi provides.
* See [[SMSC LAN9512]] for information about the built-in USB Ethernet Adapter on the Raspberry Pi Model B, and XinuPi's driver for it.

TODO: sound, graphics, keyboard support

Raspberry Pi

2013-09-11T22:37:33Z

Ebiggers:

[[File:RaspberryPi.jpg|200px|right|thumb|A freshly unpacked Raspberry Pi with additional SDHC card.]]
The '''Raspberry Pi''' is an inexpensive credit-card sized computer designed for educational use. This page provides information about the Raspberry Pi in the context of those looking to run [[XinuPi]] on it. Readers unfamiliar with the Raspberry Pi are advised to also see other sources such as the [http://www.raspberrypi.org/ Raspberry Pi foundation's website].

== Acquiring the hardware ==

=== Model A vs. Model B ===

The Raspberry Pi Model A costs $25, whereas the Raspberry Pi Model B costs $35. We generally recommend the Model B because it includes an Ethernet port and 2 USB ports, as opposed to the Model A which merely has 1 USB port. Also, currently the Model B has more memory (512 MiB) than the Model A (256 MiB), but since [[XinuPi]] is very lightweight and only uses a small amount of the available memory, the difference in memory is mostly irrelevant.

=== Hardware accessories ===

One way the cost of the Raspberry Pi was kept down was increasing modularity. A consequence of this is that a Raspberry Pi board by itself is useless until at least two additional components have been added:

* SD card. To boot, the Raspberry Pi requires an appropriately formatted SD card containing certain boot files as well as the operating system or kernel to run. Note: as of this writing, [[XinuPi]] has no SD card driver; therefore, when running [[XinuPi]] the SD card is only used for booting. Useful tip: Since the SD card can easily be removed, it is trivial to have different SD cards and swap them out when needed. This trick can be used to easily use the same Raspberry Pis for different purposes.
* Power source. The Raspberry Pi requires 700 mA at 5V, delivered either through the microUSB port or through the GPIO pins. For the microUSB port, most cell phone chargers should work. For the GPIO pins, a useful trick is that a USB to TTL Serial converter, such as [http://www.adafruit.com/products/954 this one], can double as a power source as well as a serial connection to the Raspberry Pi over which the console runs. We have primarily used the latter method while developing [[XinuPi]].

Other useful hardware and accessories include the following:

* Serial cable for text input/output to/from the Raspberry Pi, such as [http://www.adafruit.com/products/954 this one]. This is very important for [[XinuPi]] because this is its primary way to interact with a human. Furthermore, as noted above, such a serial cable can double as a power source. However, eventually a keyboard-and-monitor setup will be supported as well, providing an alternative to a serial cable when human interaction with the system is desired.
* Monitor or TV to display graphics output from the Raspberry Pi. While important for Linux, this is less important for [[XinuPi]], which is primarily intended to produce text output over a serial connection as described above. However, [[XinuPi]] does support a framebuffer console and a turtle graphics application for those interested.
* [[USB]] devices can be plugged in and recognized, but the device driver support for specific devices is extremely limited at this point. Support for USB keyboards as an input method is in development.
* Ethernet cable to take advantage of the networking support.
* Case to enclose the Raspberry Pi in. This protects the board and adds aesthetic value; otherwise it has no purpose.

[[File:Raspberry Pi in case with USB and Ethernet cables.jpg|thumb|Raspberry Pi Model B in a case with USB and Ethernet cables attached.]]
[[File:RaspberryPi in case with Ethernet cable.jpg|thumb|Another shot of a Raspberry Pi Model B in a case.]]

== Booting ==

The Raspberry Pi can only boot from its SD card, not from any external devices, and it requires several files in order to do so. Several boot files, which are not distributed with [[XinuPi]], must be placed in the root directory of a FAT-formatted partition of the SD card.

The following binary blobs (created by Broadcom, but freely distributable, at least when using them on Raspberry Pis) must exist:

* "bootcode.bin" is a first-stage bootloader. [[https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin Download link]].
* "loader.bin" is a second-stage bootloader. Apparently, this file is no longer required.
* "start.elf" is the GPU firmware.[[https://github.com/raspberrypi/firmware/raw/master/boot/start.elf Download link]].

The following text files are optional:

* "config.txt" is parsed by the GPU firmware and is used to set various hardware parameters. [[XinuPi]] runs fine with the default parameters, so "config.txt" need not exist.
* "cmdline.txt" is used to pass a command line to the Linux kernel. This file need not exist for the [[XinuPi]] kernel, which does not take command line parameters.

Finally, the actual kernel:

* "kernel.img" must exist and is loaded as raw data at physical memory address 0x8000 by the GPU firmware. The ARM begins execution at the very first instruction in this loaded image. "kernel.img" can be a [[XinuPi]] kernel (rename "xinu.boot" to "kernel.img"), a Linux kernel, or other bare-metal code such as the "raspbootin" bootloader. "raspbootin" has been helpful in developing [[XinuPi]]; see [https://github.com/mrvn/raspbootin/blob/master/README.md its documentation] for more information.

There are a couple ways you can actually achieve the final result of a properly set up SD card:

* Follow the installation instructions for a Linux distribution supported on the Raspberry Pi, such as Raspbian or Arch Linux ARM. This will leave the appropriate boot files. To switch to [[XinuPi]], simply replace "kernel.img" on the FAT partition with "xinu.boot". (Perhaps rename "kernel.img" to "linux.img" to save a backup first.)
* Manually partition the SD card and create a FAT filesystem, then copy the boot files to the filesystem. The binary blobs can be downloaded using the links provided above.

Raspberry Pi

2013-09-11T22:35:25Z

Ebiggers: Wikify

[[File:RaspberryPi.jpg|200px|right|thumb|A freshly unpacked Raspberry Pi with additional SDHC card.]]
The '''Raspberry Pi''' is an inexpensive credit-card sized computer designed for educational use. This page provides information about the Raspberry Pi in the context of those looking to run [[XinuPi]] on it. Readers unfamiliar with the Raspberry Pi are advised to also see other sources such as the [http://www.raspberrypi.org/ Raspberry Pi foundation's website].

== Acquiring the hardware ==

=== Model A vs. Model B ===

The Raspberry Pi Model A costs $25, whereas the Raspberry Pi Model B costs $35. We generally recommend the Model B because it includes an Ethernet port and 2 USB ports, as opposed to the Model A which merely has 1 USB port. Also, currently the Model B has more memory (512 MiB) than the Model A (256 MiB), but since Embedded Xinu is very lightweight and only uses a small amount of the available memory, the difference in memory is mostly irrelevant.

=== Hardware accessories ===

One way the cost of the Raspberry Pi was kept down was increasing modularity. A consequence of this is that a Raspberry Pi board by itself is useless until at least two additional components have been added:

* SD card. To boot, the Raspberry Pi requires an appropriately formatted SD card containing certain boot files as well as the operating system or kernel to run. Note: as of this writing, Embedded Xinu has no SD card driver; therefore, when running Embedded Xinu the SD card is only used for booting. Useful tip: Since the SD card can easily be removed, it is trivial to have different SD cards and swap them out when needed. This trick can be used to easily use the same Raspberry Pis for different purposes.
* Power source. The Raspberry Pi requires 700 mA at 5V, delivered either through the microUSB port or through the GPIO pins. For the microUSB port, most cell phone chargers should work. For the GPIO pins, a useful trick is that a USB to TTL Serial converter, such as [http://www.adafruit.com/products/954 this one], can double as a power source as well as a serial connection to the Raspberry Pi over which the console runs. We have primarily used the latter method while developing [[XinuPi]].

Other useful hardware and accessories include the following:

* Serial cable for text input/output to/from the Raspberry Pi, such as [http://www.adafruit.com/products/954 this one]. This is very important for [[XinuPi]] because this is its primary way to interact with a human. Furthermore, as noted above, such a serial cable can double as a power source. However, eventually a keyboard-and-monitor setup will be supported as well, providing an alternative to a serial cable when human interaction with the system is desired.
* Monitor or TV to display graphics output from the Raspberry Pi. While important for Linux, this is less important for [[XinuPi]], which is primarily intended to produce text output over a serial connection as described above. However, [[XinuPi]] does support a framebuffer console and a turtle graphics application for those interested.
* [[USB]] devices can be plugged in and recognized, but the device driver support for specific devices is extremely limited at this point. Support for USB keyboards as an input method is in development.
* Ethernet cable to take advantage of the networking support.
* Case to enclose the Raspberry Pi in. This protects the board and adds aesthetic value; otherwise it has no purpose.

[[File:Raspberry Pi in case with USB and Ethernet cables.jpg|thumb|Raspberry Pi Model B in a case with USB and Ethernet cables attached.]]
[[File:RaspberryPi in case with Ethernet cable.jpg|thumb|Another shot of a Raspberry Pi Model B in a case.]]

== Booting ==

The Raspberry Pi can only boot from its SD card, not from any external devices, and it requires several files in order to do so. Several boot files, which are not distributed with [[XinuPi]], must be placed in the root directory of a FAT-formatted partition of the SD card.

The following binary blobs (created by Broadcom, but freely distributable, at least when using them on Raspberry Pis) must exist:

* "bootcode.bin" is a first-stage bootloader. [[https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin Download link]].
* "loader.bin" is a second-stage bootloader. Apparently, this file is no longer required.
* "start.elf" is the GPU firmware.[[https://github.com/raspberrypi/firmware/raw/master/boot/start.elf Download link]].

The following text files are optional:

* "config.txt" is parsed by the GPU firmware and is used to set various hardware parameters. [[XinuPi]] runs fine with the default parameters, so "config.txt" need not exist.
* "cmdline.txt" is used to pass a command line to the Linux kernel. This file need not exist for the [[XinuPi]] kernel, which does not take command line parameters.

Finally, the actual kernel:

* "kernel.img" must exist and is loaded as raw data at physical memory address 0x8000 by the GPU firmware. The ARM begins execution at the very first instruction in this loaded image. "kernel.img" can be a [[XinuPi]] kernel (rename "xinu.boot" to "kernel.img"), a Linux kernel, or other bare-metal code such as the "raspbootin" bootloader. "raspbootin" has been helpful in developing [[XinuPi]]; see [https://github.com/mrvn/raspbootin/blob/master/README.md its documentation] for more information.

There are a couple ways you can actually achieve the final result of a properly set up SD card:

* Follow the installation instructions for a Linux distribution supported on the Raspberry Pi, such as Raspbian or Arch Linux ARM. This will leave the appropriate boot files. To switch to [[XinuPi]], simply replace "kernel.img" on the FAT partition with "xinu.boot". (Perhaps rename "kernel.img" to "linux.img" to save a backup first.)
* Manually partition the SD card and create a FAT filesystem, then copy the boot files to the filesystem. The binary blobs can be downloaded using the links provided above.

XinuPi

2013-09-11T22:34:00Z

Ebiggers: Created page with content from "Raspberry Pi"

'''XinuPi''' is the port of [[Embedded Xinu]] to the [[Raspberry Pi]]. XinuPi provides a simple, lightweight operating system for the Raspberry Pi that contains several orders of magnitude fewer lines of code than the Linux-based software stacks that normally run on the device. Its purpose is to provide an inexpensive, convenient platform for various areas of computer science education at a University level, including operating systems, embedded systems, networking, and programming languages. Another goal of XinuPi is to document some of the Raspberry Pi's hardware that has, until this point, been poorly documented or even undocumented. This includes the documentation on this Wiki as well as the XinuPi source code and the documentation generated from comments in it.

== Acquiring hardware ==

See [[Raspberry Pi]] for information about the hardware itself.

== Downloading and compiling ==

XinuPi is currently only available in source code form and only in the [http://github.com/xinu-os/xinu Embedded Xinu git repository]. To obtain the code, install [http://git-scm.com/ git] and run:

git clone https://github.com/xinu-os/xinu
cd xinu

Note that this in fact the code for "Embedded Xinu" and not for "XinuPi" specifically. That is, the Raspberry Pi is one of several platforms that Embedded Xinu supports (and builds targeting it are referred to as "XinuPi").

To compile XinuPi, run:

make -C compile PLATFORM=arm-rpi

PLATFORM=arm-rpi is necessary to instruct the build system to target the Raspberry Pi. Additional arguments can be passed to ''make'', such as the COMPILER_ROOT to specify the location of a GCC compiler targeting ARM (defaults to "arm-none-eabi-", meaning that no explicit setting is needed if "arm-none-eabi-gcc" and the corresponding binutils are already on the shell $PATH). See compile/README.compiling for more details; for example, details about cross compilers.

The compilation process produces a file "compile/xinu.boot", which can be copied to "kernel.img" on the SD card of a Raspberry Pi to run it (see [[#Booting]]).

XinuPi is licensed under a BSD-style license; see the copyright information in the source distribution for more details.

== Features and implementation ==

* The core of XinuPi provides a preemptive multitasking operating system for the Raspberry Pi. See [[Preemptive multitasking (ARM)]] for more details about how Embedded Xinu implements preemptive multitasking on ARM-based platforms such as the Raspberry Pi; this includes information about thread creation and context switching. Also see [[BCM2835 System Timer]] for the timer on the Raspberry Pi that XinuPi uses to implement preemptive multitasking.
* Interrupt handling on the Raspberry Pi, required for the timer interrupt as well as many other devices, is described in [[Interrupt handling (Raspberry Pi)]].
* USB support was added to Embedded Xinu partly because of its important role in the Raspberry Pi, including to attach the Ethernet Controller on the Raspberry Pi Model B. See [[USB]] for general information about USB, or [[Synopsys DesignWare High-Speed USB 2.0 On-The-Go Controller]] for information specifically about the USB controller the Raspberry Pi provides.
* See [[SMSC LAN9512]] for information about the built-in USB Ethernet Adapter on the Raspberry Pi Model B, and XinuPi's driver for it.

TODO: sound, graphics, keyboard support

Raspberry Pi

2013-09-11T22:33:35Z

Ebiggers: Moving XinuPi info to external page

[[File:RaspberryPi.jpg|200px|right|thumb|A freshly unpacked Raspberry Pi with additional SDHC card.]]
The '''Raspberry Pi''' is an inexpensive credit-card sized computer designed for educational use. This page provides information about the Raspberry Pi in the context of those looking to run [[XinuPi]] on it. Readers unfamiliar with the Raspberry Pi are advised to also see other sources such as the [http://www.raspberrypi.org/ Raspberry Pi foundation's website].

== Acquiring the hardware ==

=== Model A vs. Model B ===

The Raspberry Pi Model A costs $25, whereas the Raspberry Pi Model B costs $35. We generally recommend the Model B because it includes an Ethernet port and 2 USB ports, as opposed to the Model A which merely has 1 USB port. Also, currently the Model B has more memory (512 MiB) than the Model A (256 MiB), but since Embedded Xinu is very lightweight and only uses a small amount of the available memory, the difference in memory is mostly irrelevant.

=== Hardware accessories ===

One way the cost of the Raspberry Pi was kept down was increasing modularity. A consequence of this is that a Raspberry Pi board by itself is useless until at least two additional components have been added:

* SD card. To boot, the Raspberry Pi requires an appropriately formatted SD card containing certain boot files as well as the operating system or kernel to run. Note: as of this writing, Embedded Xinu has no SD card driver; therefore, when running Embedded Xinu the SD card is only used for booting. Useful tip: Since the SD card can easily be removed, it is trivial to have different SD cards and swap them out when needed. This trick can be used to easily use the same Raspberry Pis for different purposes.
* Power source. The Raspberry Pi requires 700 mA at 5V, delivered either through the microUSB port or through the GPIO pins. For the microUSB port, most cell phone chargers should work. For the GPIO pins, a useful trick is that a USB to TTL Serial converter, such as [http://www.adafruit.com/products/954 this one], can double as a power source as well as a serial connection to the Raspberry Pi over which the console runs. We have primarily used the latter method while developing XinuPi.

Other useful hardware and accessories include the following:

* Serial cable for text input/output to/from the Raspberry Pi, such as [http://www.adafruit.com/products/954 this one]. This is very important for XinuPi because this is its primary way to interact with a human. Furthermore, as noted above, such a serial cable can double as a power source. However, eventually a keyboard-and-monitor setup will be supported as well, providing an alternative to a serial cable when human interaction with the system is desired.
* Monitor or TV to display graphics output from the Raspberry Pi. While important for Linux, this is less important for XinuPi, which is primarily intended to produce text output over a serial connection as described above. However, XinuPi does support a framebuffer console and a turtle graphics application for those interested.
* USB devices can be plugged in and recognized, but the device driver support for specific devices is extremely limited at this point. Support for USB keyboards as an input method is in development.
* Ethernet cable to take advantage of the networking support.
* Case to enclose the Raspberry Pi in. This protects the board and adds aesthetic value; otherwise it has no purpose.

[[File:Raspberry Pi in case with USB and Ethernet cables.jpg|thumb|Raspberry Pi Model B in a case with USB and Ethernet cables attached.]]
[[File:RaspberryPi in case with Ethernet cable.jpg|thumb|Another shot of a Raspberry Pi Model B in a case.]]

== Booting ==

The Raspberry Pi can only boot from its SD card, not from any external devices, and it requires several files in order to do so. Several boot files, which are not distributed with XinuPi, must be placed in the root directory of a FAT-formatted partition of the SD card.

The following binary blobs (created by Broadcom, but freely distributable, at least when using them on Raspberry Pis) must exist:

* "bootcode.bin" is a first-stage bootloader. [[https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin Download link]].
* "loader.bin" is a second-stage bootloader. Apparently, this file is no longer required.
* "start.elf" is the GPU firmware.[[https://github.com/raspberrypi/firmware/raw/master/boot/start.elf Download link]].

The following text files are optional:

* "config.txt" is parsed by the GPU firmware and is used to set various hardware parameters. XinuPi runs fine with the default parameters, so "config.txt" need not exist.
* "cmdline.txt" is used to pass a command line to the Linux kernel. This file need not exist for the XinuPi kernel, which does not take command line parameters.

Finally, the actual kernel:

* "kernel.img" must exist and is loaded as raw data at physical memory address 0x8000 by the GPU firmware. The ARM begins execution at the very first instruction in this loaded image. "kernel.img" can be a XinuPi kernel (rename "xinu.boot" to "kernel.img"), a Linux kernel, or other bare-metal code such as the "raspbootin" bootloader. "raspbootin" has been helpful in developing XinuPi; see [https://github.com/mrvn/raspbootin/blob/master/README.md its documentation] for more information.

There are a couple ways you can actually achieve the final result of a properly set up SD card:

* Follow the installation instructions for a Linux distribution supported on the Raspberry Pi, such as Raspbian or Arch Linux ARM. This will leave the appropriate boot files. To switch to XinuPi, simply replace "kernel.img" on the FAT partition with "xinu.boot". (Perhaps rename "kernel.img" to "linux.img" to save a backup first.)
* Manually partition the SD card and create a FAT filesystem, then copy the boot files to the filesystem. The binary blobs can be downloaded using the links provided above.

Netaa

2013-09-11T22:23:20Z

Ebiggers:

{{Historical}}

=Team Members=
''(All emails are @mu.edu)''
*Aaron Gember: aaron.gember, (414) 550-5820
*Adam Koehler: adam.koehler
*Brian Smith: brian.smith
*Cathy Vuong: catherine.vuong
*Kyle Jackson: kyle.jackson
*Tim Blattner: timothy.blattner

Team email list:
agember-es{at}mscs{dot}mu{dot}edu

=Documentation=
[[Image:Netaa_network_daemons_plan.pdf]]

[[Image:Netaa_network_send_plan.pdf]]

=Timeline=
===Thursday, February 14: Meeting===
*6pm in Cudahy 310

*Adam, Tim, and Kyle are researching ICMP. Aaron, Brian, and Cathy are researching ARP.
*Extra shell commands will be assigned at next meeting.

===Monday, February 18: ICMP Subgroup Meeting===
*3:45pm in Cudahy 310
*Meeting before class to go over questions or concerns on implementation.

===Thursday, February 21: Meeting===
*6pm in Cudahy 310
*Meeting to ensure progress and to assign the remaining pieces of the project.

===<strike>Wednesday, February 27</strike> Sunday, March 2: Part 1 Deadline===
*ARP (Address Resolution Protocol) '''[completed February 29, 2008]'''
**<strike>send</strike> [completed February 28, 2008]
**<strike>receive</strike> [completed February 22, 2008]
**<strike>receiveDaemon</strike> [completed February 27, 2008]
**<strike>arpTimer - cache timeout</strike> [completed February 29, 2008]
**<strike>shell command (arp)</strike> [completed February 28, 2008]
*ICMP (Internet Control Message Protocol) '''[completed February 28, 2008]'''
**<strike>echo request</strike> [completed February 22, 2008]
**<strike>echo reply</strike> [completed February 28, 2008]
**<strike>daemon</strike> [completed February 22, 2008]
**<strike>shell command (ping)</strike> [completed February 27, 2008]
*Shell commands '''[completed February 28, 2008]'''
**<strike>snoop (packet sniffer)</strike> [completed February 26, 2008]
**<strike>ethstat</strike> [completed February 28, 2008]
**<strike>guesswho</strike> [completed February 23, 2008]
*Other '''[completed February 27, 2008]'''
**<strike>netSend</strike> [completed February 26, 2008]
**<strike>chkSum</strike> [completed February 27, 2008]

===Monday, March 3: Project Team Meeting===
*Discuss part two of the project, all team members should read up on all parts of the second stage before the meeting occurs.

===Wednesday, April 2: Part 2 Deadline [completed April 2, 2008]===
*<strike>DHCP (Dynamic Host Configuration Protocol)</strike> -- Aaron & Cathy [completed April 1, 2008]
**[http://tools.ietf.org/html/rfc2131 RFC]
**[http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol Wikipedia Page]
*<strike>Traceroute</strike> -- Adam & Kyle [completed April 2, 2008]
**[http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol ICMP Wiki Page]
**[http://en.wikipedia.org/wiki/Traceroute Wikipedia Page]
**<strike>Request</strike> [completed April 2, 2008]
**<strike>Reply</strike> [completed March 26, 2008]
**<strike>Shell command</strike>
*<strike>Rdate -- Tim & Brian </strike> [completed April 3, 2008]
**[http://www.faqs.org/rfcs/rfc868.html Time Protocol]
**[http://www.linuxcommand.org/man_pages/rdate1.html man page]
*<strike>UDP</strike> -- Aaron & Adam [completed March 28, 2008]
**[http://www.faqs.org/rfcs/rfc768.html UDP RFC]
**<strike>UDP Daemon</strike> [completed March 24, 2008]
**<strike>UDP ports device</strike> [completed March 28, 2008]
**<strike>Shell command udpstat</strike> [completed March 24, 2008]

===Monday, May 5: TCP Deadline===
*Research
**[http://www.faqs.org/rfcs/rfc793.html TCP RFC]
**[[Image:TCPIP_State_Transition_Diagram.pdf]]
===Future Development===
*X11
**[http://en.wikipedia.org/wiki/X11 Wikipedia]
**[http://en.wikipedia.org/wiki/X11 Wikipedia]
**[http://toastytech.com/guis/remotex11.html Other implementation]
**[http://proquest.safaribooksonline.com/0789723727 Book: X Window Programming from Scratch by J. Robert Brown]
**[http://www.faqs.org/rfcs/rfc1013.html X11 RFC]
**[http://www.x.org/wiki/ X.org]

=Cautions=
#Be aware of critical sections, you may need to disable and restore interrupts.

=Known Bugs=
#Sporadically receive PDE errors, running etherClose seems to fix things.
#Memory fragmentation occurs when packets are received and processed.

Development

2013-09-11T22:18:23Z

Ebiggers: Remove link to redundant / obsolete page

Development tasks

2013-09-11T22:14:00Z

Ebiggers: Update page

This page catalogs tasks for the [[Embedded Xinu]] project. Feel free to add new tasks and change existing tasks as you see fit.

== Pending ==

=== Active ===

* USB HID (e.g. keyboard) support
* SD card support
* File System/[[Flash driver|Flash disk driver]]/TTY disk driver
* [[EJTAG]] interface for debugging, on platforms supporting it
* Improvements to testsuite (Internal/External Testing and Completion)
* Memory protection (on some platforms)

== Future ==

=== Software ===
* Wireless networking
* Robo-switch
* Watchdog timer

=== Hardware ===
* External sensors
* Poke around [[WRT54G]] and [[WRT350N]]

=== Meta ===
* Windows port of xinu-console tools
* Rebooter daemon

== Completed ==

=== Fall 2005 ===
* Complete port of ancient-XINU (Pentium) to modern processor (PPC)

=== Summer 2006 ===
* Hardware modifications for WRT54GLs
* Communicate over serial port (MIPS)
* Write loader for MIPS port

=== Fall 2006 ===
* Complete port of PPC-XINU to MIPS-XINU
* Interrupt subsystem

=== Spring 2007 ===
* Initial asynchronous UART driver (TTY driver)
* Initial file system (via the second TTY)

=== Summer 2007 ===
* Basic [[Shell]] (port from x86)
* Improvements to the [[UART Driver]] and [[TTY Driver]]
* Code Audits
** Including the startup process, [[UART Driver]], [[TTY Driver]], [[Standard library|libxc]], Interprocess Communication (now mailboxes), memory, interrupts, and other important XINU subsystems
* Hardware modifications for EJTAG port
** Successfully wrote Flash memory via [[EJTAG]] interface

=== Fall 2007 - Spring 2013 ===
* No one bothered to update this page, apparently.

=== Summer 2013 ===
* Ported to Raspberry Pi
* Rewrote C library
* Added USB support
* Added TFTP and DHCP clients
* Reduced code duplication

Subversion

2013-09-11T22:00:33Z

Ebiggers: Marked page as historical (due to switch to git)

{{Historical}}

A [http://acm.mscs.mu.edu/wiki/Subversion general use guide] is now available on the [http://acm.mscs.mu.edu/ Student ACM Wiki]. Also there is a posting of commands in the Cudahy 310 Computer Lab.

Xinu specific information about the repository is available in the [[trac:Subversion|trac wiki]].

Git

2013-09-11T21:57:07Z

Ebiggers: Created page

Embedded Xinu previously used a [[Subversion]] repository, but in 2013 switched to [http://git-scm.com/ git] as the preferred method of development.

The official public repository is hosted on Github. To get the code, install git and run:

<code>
git clone https://github.com/xinu-os/xinu
</code>

This will generate the directory "xinu" containing a local copy of the repository. Note that this is a standalone repository that can be used without access to the Github repository. This constitutes a difference from Subversion, which is more centralized.

Git is documented extensively in many locations, for example in the [http://git-scm.com/book "Pro Git" book]. But in one sentence, a very basic workflow is to modify files, use "git add" and "git commit" or "git commit -a" to commit the changes to the repository, then use "git push" to push changes to a remote repository.

Branches in git are fast and easy to use, so please develop experimental features in their own branches. Code pushed to the "master" branch should not be broken.