Embedded Xinu - User contributions [en]

Systems Laboratory

2011-06-01T21:06:33Z

Jpintozz: /* Alumni */

== About the Systems Laboratory ==

[http://www.mu.edu/ Marquette]'s [[Systems Laboratory]], under the direction of [http://www.mscs.mu.edu/~brylow/ Dr. Dennis Brylow] in the [http://www.mscs.mu.edu/ Department of Mathematics, Statistics, and Computer Science], is housed on the third floor of Cudahy Hall.

The lab creates new tools and methods for building and studying complex computer systems. Our emphasis is on embedded, real-time, and network systems, with strong ties to the electrical and computer engineering community, and the computer science education community. Current projects include:

1. Experimental Embedded Networking Platform. Creation of laboratory infrastructure and software for research and education in the area of embedded networking appliances, particularly wireless routers and IP telephony. Collaboration with Cisco Systems Advanced Research Division.

2. Experimental Embedded Operating System Laboratory. Creation of laboratory infrastructure and software for research and education in area of embedded operating systems. Collaboration with University of Buffalo and University of Mississippi, with funding from the National Science Founcation.

3. Embedded Software Transactional Memory. Exploration of an innovative transactional memory model for guaranteeing process synchronization in embedded operating systems. Collaboration with Intel Research.

The Systems Lab will host three undergraduate [http://acm.mscs.mu.edu/reu REU] (Research Experience for Undergraduates) students in summer 2010, funded by the MU's College of Arts and Sciences. They will be working on ports of the Embedded Xinu operating system to new embedded platforms, embedded network emulation, and multicore embedded systems.

See the MSCS [http://www.mscs.mu.edu/mscs/faculty/research_labs.html Research Labs] page for more research laboratories in our department.

== Publications ==

=== Conference Proceedings and Journals ===
<li>Dennis Brylow and Kyle Thurow. Hands-on Networking Labs With Embedded Routers. In Proceedings of [http://www.sigcse.org/sigcse2011/ SIGCSE 2011]: The 42nd ACM Technical Symposium on Computer Science Education, pages 399-404, Dallas, Texas, March 2011.
[http://doi.acm.org/10.1145/1953163.1953283 (link)]

<li>Matt Netkow and Dennis Brylow. Xest: An Automated Framework for Regression Testing of Embedded Software. In Proceedings of [http://www.artist-embedded.org/artist/-WESE-10-.html WESE 2010]: 6th Workshop on Embedded Systems Education, pages 40-47, Scottsdale, Arizona, October 2010.
[http://www.artist-embedded.org/docs/Events/2010/WESE/Proceedings_WESE_2010.pdf (link)]

<li>Adam Mallen and Dennis Brylow. Compiler Construction With A Dash of Concurrency and An Embedded Twist. In Proceedings of [http://splashcon.org/ SPLASH 2010]: Systems, Programming, Languages, and Applications: Software for Humanity (formerly OOPSLA) Educators' and Trainers' Symposium, pages 161-168, Reno, Nevada, October 2010.
[http://dx.doi.org/10.1145/1869542.1869568 (link)]

<li>Dennis Brylow and Bina Ramamurthy. Nexos: A Next Generation Embedded
Systems Laboratory, In Proceedings of WESE 2008: 4th Workshop on Embedded
Systems Education, pages 10-17, Atlanta, Georgia, October 2008.
[http://www.lulu.com/content/3613764 (link)] 
Extended version in SIGBED Review, Volume 6, Number 1, January 2009.
[http://www.cs.virginia.edu/sigbed/archives/2009-01/j-7-wese-journal-p18-final-brylow.pdf (link)]

<li>Dennis Brylow. An Experimental Laboratory Environment for Teaching Embedded
Operating Systems, In Proceedings of [http://www.cs.duke.edu/sigcse08/ SIGCSE 2008]: The 39th ACM Technical Symposium on Computer Science Education, pages 192-196, Portland, Oregon, March 2008. [http://doi.acm.org/10.1145/1352322.1352201 (link)]

<li>Dennis Brylow. An Experimental Laboratory Environment for Teaching Embedded Hardware Systems, In Proceedings of
[http://www.ncsu.edu/wcae/ISCA2007/FinalProgram.html WCAE 2007]:
Workshop on Computer Architecture Education,
pages 44-51, San Diego, California, June 2007.
[http://www.mscs.mu.edu/~brylow/papers/Brylow-WCAE2007.pdf (link)]

=== Posters and Undergraduate Research ===

<li> Kyle Thurow and Dennis Brylow. A Network Emulator on Embedded Xinu.
Poster presentation and research talk presented at [http://www.sigcse.org/sigcse2010/ SIGCSE 2010]
[http://src.acm.org/ ACM Student Research Competition], undergraduate division, Milwaukee, Wisconsin, March 2010. Kyle placed in the top five and advanced to the semi-finals round.

<li> Gabe Van Eyck and Dennis Brylow. Xinu as a Multi-Core Operating
System on the PlayStation 3. Poster presentation at [http://www.sigcse.org/sigcse2010/ SIGCSE 2010]
[http://src.acm.org/ ACM Student Research Competition], undergraduate division, Milwaukee, Wisconsin, March 2010.

<li> Aaron Gember and Dennis Brylow. Real-Time TCP Extensions. Poster
presentation and research talk presented at [http://www.cs.arizona.edu/groups/sigcse09/ SIGCSE 2009]
[http://src.acm.org/ ACM Student Research Competition], undergraduate division, Chattanooga, Tennessee. Aaron advanced to
semi-finals, placed in top
three finalists, and advanced to the grand finals.

<li>Dennis Brylow. Experimental Operating System Lab On A Dime.
[http://www.cs.potsdam.edu/sigcse07/ SIGCSE 2007]: Technical Symposium on Computer Science Education, Covington, Kentucky,
March 2007. [http://www.mscs.mu.edu/~brylow/papers/Brylow-SIGCSE2007.pdf (link)].

=== Workshops ===

<li> Paul Ruth and Dennis Brylow. Teaching With Embedded Xinu. Workshop
accepted at [http://www.cs.olemiss.edu/acmse2010/Home.htm ACMSE 2010]:
The 48th ACM Southeast Conference, Oxford, Mississippi, April 2010.

<li>Dennis Brylow and Paul Ruth. Teaching With Embedded Xinu. Workshop
accepted at [http://www.sigcse.org/sigcse2010/ SIGCSE 2010]:
The 41st ACM Technical Symposium on Computer Science Education, Milwaukee,
Wisconsin, March 2010.

== Lab Equipment ==

The [[Systems Laboratory]] is populated with dual-headed Linux boxes running the latest version of [http://fedoraproject.org/ Fedora Linux].
Other workstations in the lab include a dual-core Apple G5 running OS X, and several multi-core boxes for higher-end computation.

The Xinu Laboratory component of the Systems Lab includes a pool of 24 WRT54GL wireless routers organized into a managed embedded
backend pool, as well as smaller quantities of half a dozen other router types. Embedded development kits available include
the Freescale/Motorola [http://www.evbplus.com/hcs12.html 68HC12 Dragon12] board,
the Atmel [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2717 AT91 Series ARM Thumb] AT91EB40A board,
the [http://www.atmel.com/products/AVR/butterfly ATmega169 Butterfly],
a Zilog [http://www.zilog.com/docs/z8/devtools/z86ccp01zem.pdf Z86 Emulator Z86CCP01ZEM],
and the Zilog [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=Z8F04A28100KIT Z8 Encore XP Dev Kit Z8F04A28100KIT-C].

The Systems Lab includes both a private research network with our own gateway and firewall, and connections to each of the MSCS department production networks.
The Lab also hosts Subversion, Trac, and Web service for the Marquette Student [http://acm.mscs.mu.edu/ ACM Chapter], the
[http://mulug.mscs.mu.edu/ Marquette University Linux Users Group], and a stratum 2 NTP server for campus.

== Lab Personnel ==

=== Current Students ===

[[File:XINU-summer2009.png|800px|thumb]] The Xinu Team in Summer 2009.

From left,
Kyle Thurow, [http://www.mscs.mu.edu/~dmahoney/ Dan Mahoney],
[http://www.gemberdesign.com/ Aaron Gember],
[http://www.mscs.mu.edu/~mschul/ Mike Schultz],
[http://www.zacintosh.com/ Zachary Lund],
[http://www.mscs.mu.edu/~brylow/ Dr. Dennis Brylow],
[http://www.mscs.mu.edu/~rberg/ Ryan Berg], and
[http://pintozzi.com/ Joe Pintozzi].
Not pictured:
[http://www.mscs.mu.edu/~akoehler/ Adam Koehler] and
Paul Spillane.

=== Alumni ===

[http://phinze.com Paul Hinze], B.S. 2008. Currently works as a developer for [http://braintreepayments.com Braintree].

[http://research.engineering.wustl.edu/~schultzm/ Mike Schultz], M.S. 2009. Now at [http://cse.wustl.edu/Pages/default.aspx Washington University in St. Louis] doctoral program.

Tim Blattner, B.S. 2009. Now at [http://www.cs.umbc.edu/ University of Maryland - Baltimore County] doctoral program.

[http://www.gemberdesign.com/ Aaron Gember], B.S. 2009. Now at [http://www.cs.wisc.edu/ University of Wisconsin-Madison] doctoral program.

[http://netkow.com/ Matt Netkow], B.S. 2009. Now works as a developer for [http://www.savogroup.com/ The SAVO Group].

Adam Mallen, B.S. 2009. Now at [http://www.marquette.edu/mscs/ Marquette University] doctoral program in Computational Sciences with an emphasis in Math.

Adam Koehler, M.S. 2010. Now at [http://www1.cs.ucr.edu/index.php University of California Riverside] doctoral program.

Joseph Pintozzi, B.S. 2010. Now works as a developer for [http://core-apps.com/ Core-Apps, LLC].

File:Xinu-Wiggler.png

2009-08-24T21:52:52Z

Jpintozz: uploaded a new version of "File:Xinu-Wiggler.png": Updated again

Schematic for the modified Wiggler that we are using. Designed in XCircuit.

File:Xinu-Wiggler.png

2009-08-24T21:15:33Z

Jpintozz: uploaded a new version of "File:Xinu-Wiggler.png": Updated Wiggler screenshot

Schematic for the modified Wiggler that we are using. Designed in XCircuit.

EJTAG

2009-08-13T19:32:38Z

Jpintozz: /* Probes */

EJTAG is a MIPS-specific extension of IEEE 1149.1, the Joint Test Action Group.
Allows interfacing with additional logic in SoC
* direct control of processor for step-by-step debugging
* access to busses and registers
** aids in debugging
** possible usage as additional peripheral data bus
** direct writing to flash for firmware updates (and de-bricking)

== Debugging ==
Attempting to use GNU debugger: http://www.gnu.org/software/gdb. GDP uses its own Remote Serial Protocol (RDB) to communicate to remote targets. This protocol could be used to communicate with the XINU backends through the current serial connection. Although, this would require additions to XINU: communication with the GDB host; altering of exception handler to allow GDB to take control of target processor.

The use of the EJTAG port on the WRT54-series routers gives the user hardware control of the processor, avoiding the need for strategically placed breakpoints and XINU interrupt subsystem modification. Additionally, requests by the debugger for specicfic data can be aquired directly from registers. The trick to this operation is software that can interpret commands from RDB into EJTAG signals to be sent through the host parallel port, and vice-versa. An implementation of this interpreter can be found at http://www.totalembedded.com/open_source/jtag/mips32_ejtag.php.

== Specific Implementations ==
So far, development has focused exclusively on the WRT54GL. For anyone investigating the capabilities of the WRT54GL EJTAG system, note the instruction register size is a full 8 bits, not the 5 bits required by specification. Believing the 54GL CP0 Debug Program Counter register to be returning erroneous addresses, headers are being added to a 54G v.8, and a 350N v.1. For IDCODEs and implementation register values check [[EJTAG ID Codes and Implementation Registers]].

== Probes ==
Images are of three variant EJTAG connections. The first two buffered by active line drivers, the last passive. Xinu research is currently using an active probe similar to the OpenWRT "Wiggler" clone; although, the parallel port pinouts match the unbuffered cable diagram.
Note that the unbuffered cable at the bottom of this page is only proven by xinu research functional in writing to the Test Access Port. It may not read data back from the target device. Additionally, rumor claims that the cable can be no longer than 6" (not 6'). This is partially substantiated by photographs "out there" of similar 6 inch cables used with a variety of devices.

[[Image:Te_jtag_cable.png|thumb|900px|center|Total Embedded buffered cable]]
[[Image:Wiggler.png|thumb|700px|center|"wiggler" clone from OpenWRT]]
[[Image:JTAGunbuffered.png|thumb|400px|center|unbuffered cable from OpenWRT; used by de-brick utility]]
[[Image:Xinu-Wiggler.png|thumb|700px|center|Our current buffer/wiggler setup]]

== See also ==
* [[EJTAG ID Codes and Implementation Registers]]

File:Xinu-Wiggler.png

2009-08-13T19:30:57Z

Jpintozz: Schematic for the modified Wiggler that we are using. Designed in XCircuit.

Schematic for the modified Wiggler that we are using. Designed in XCircuit.

Talk:Flash driver/Original

2009-05-20T11:41:09Z

Jpintozz: "driver" was misspelt

[[Image:Flash-design.png|450px|right]]
The [[WRT54GL]] has a 4MB Intel Flash chip which is able to store [[CFE]], [[NVRAM|NVRAM settings]], an operating system (like [[OpenWRT]] or LinkSys' operating system (or even [[XINU]]), and optionally a file system. Currently the bleeding edge version of XINU in the flashmem branch has a working Flash driver, though it is not the one on this page and will be replaced with the driver described in this document. GL-series routers have 2 erase-block regions (8-8KB and 63-64KB).

Flash memory remains minimally tested on the [[WRT54G]]. XINU reports that the G-series has 2MB of Flash memory, separated into 4 regioins of varying erase-block sizes (1-16KB, 2-8KB, 1-32KB, and 31-64KB).

== Terminology ==

Flash is bounded by the rule that to program the software may only change a 1-bit to a 0-bit and cannot change from a 0 to a 1. Because of this, it is often necesary to erase a block of memory (setting all bits in the block to 1) and then write data to it. This is known as an "erasae-block". The majority of these seem to be in the 64 kilobyte range, with the smallest being a massive 8 kilobyte erase-block. This causes a problem as most file systems work in 512 byte blocks or 2048 byte blocks, both of which are substantially smaller than the smallest erase-block. The [[Flash driver#Logical Flash Interface|logical flash interface]] attempts to solve this problem by presenting standard 512 byte blocks to the higher layers while maintaining erase-block regions within physical flash memory.

== Physical Flash ==

The base location of physical Flash is stored in a flash structure and for both series of routers is 0xBC000000.

As stated above physical Flash is seperated into erase-blocks which are the smallest writable unit on Flash memory. The GL-series and the G-series have differing Flash sizes and erase-block layouts. The 4MB GLs have 2 erase-block regions with the first having 8-8 kilobyte erase-blocks and the second having 63-64 kilobyte erase-blocks. The 2MB Gs have 4 erase-block regions, the first having 1-16 kilobyte erase-block, followed by 2-8 kilobyte erase-blocks, then 1-32 kilobyte erase-block, and finally 31-64 kilobyte erase-blocks.

Because of these inconsistencies, this driver will use the Logical Flash Interface to provide a standard view of Flash memory with a fixed block size throughout.

== Logical Flash Interface ==

The logical Flash interface will do the bulk of the work needed for accessing flash memory. It will enforce the rules for what memory can be changed, present standard 512 byte block sizes to the upper layers, ensure that erase-blocks are not incorrectly modified (writing 512 bytes to a much larger erase-block would destroy most the data in the erase-block), and also provide an interface into the NVRAM settings of flash memory.

When a 512 byte logical block is requested the logical Flash interface will read the entire erase-block into memory and pass the proper logical block through to the requester. When attempting to write the same logical block back the interface will recognize that the erase-block is in memory, overwrite the block, and write the erase-block back to Flash. Although the last portion could be modified to only write back to disk when a synchronization is requested, thus the Flash interface could maintain a collection of erase-blocks only writing them to Flash when too many exist or upon a synchronization request.

== Lower Driver (Optional) ==

== Upper Driver ==

The upper driver can communicate directly with the logical Flash interface or use a lower driver if desired with slight code modification. The purpose of the upper driver is to present a simple interface to the rest of the operating system for all Flash input/output. The API is as follows:

read(FLASH, unsigned char *buffer, ulong block)

This call will read into a buffer (which should be a pointer to a 512 byte region of memory) the specified block. For the 4MB Flash there are (4*1024*1024 / DISK_BLOCK_SIZE) blocks. It is up to the file system or programmer to know what block to request (although some blocks are off-limits, this is handeled by the logical Flash interface). This will return OK on a successful read and SYSERR on any error.

write(FLASH, unsigned char *buffer, ulong block)

Similar to <code>read()</code>, this will write the contents of buffer to the specified block. Again the logical Flash interface will know legal and illegal positions to write. This will return OK on a successful write and SYSERR on any error.

seek(FLASH, ulong block)

Seek will simply take the given block and return the position relative to Flash (Flash beginning at 0x00000000). So calling <code>seek(FLASH, 100)</code> will return the position of the 100th block of Flash (100 * DISK_BLOCK_SIZE). Instead of just performing the multiplication in the code, using <code>seek()</code> will provide a type of pre-check, if the block being seek'd to is outside of the range of Flash or if the logical Flash interface deems that block protected (in CFE's memory or NVRAM settings), it will return SYSERR.

User:Jpintozz

2009-05-18T21:12:15Z

Jpintozz: In the begining....

Hey,

This is my page. I will add more later.