https://xinu.cs.mu.edu/api.php?action=feedcontributions&user=Jpicotte&feedformat=atomEmbedded Xinu - User contributions [en]2024-03-28T14:40:15ZUser contributionsMediaWiki 1.34.2https://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=2909Serial adapter diagrams2008-09-30T23:58:35Z<p>Jpicotte: </p>
<hr />
<div>== RJ45/DB9 adapters ==<br />
Below are diagrams for RJ45 to DB9 adapters allowing connection between an [[HOWTO:Build Backend Pool|Etherlite serial bay and XINU backends]] in a pool. The first diagram is for UART 0 (DTE). The second diagram is for the platform-dependent UART 1 (DCE).<br />
[[Image:DB9M.png|thumb|400px|left|UART 0, DTE]]<br clear="all" /><br />
[[Image:NullModem.png|thumb|400px|left|UART 1, DCE]]<br clear="all" /><br />
== Null Modem ==<br />
The null modem adapter is required to make connections between available UART 1 ports on two machines. The above UART 1 diagram functions as a null modem when connecting directly to other backends, as well as to the EtherLite serial bay.<br />
<br />
== EtherLite to Baytech ==<br />
The third diagram represents a connection between the between a Baytech serial-controlled power strip and the EtherLite terminal annex. The final two diagrams are the Baytech/Etherlite diagram broken into two parts, representing the mating of two individual RJ45/DB9 adapters.<br />
[[Image:BaytechWiring.png|thumb|500px|left|Wiring diagram for Baytech to Etherlite connection]]<br />
<br clear="all" /><br />
[[Image:DB9M.png|thumb|300px|left|same as UART 0 diagram above]]<br clear="all" /><br />
[[Image:baytech.png|thumb|300px|left|Baytech RJ45 to DB9F]]<br />
<br clear="all" /></div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=File:Baytech.png&diff=2908File:Baytech.png2008-09-30T23:55:57Z<p>Jpicotte: baytech to db9f adapter</p>
<hr />
<div>baytech to db9f adapter</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=File:NullModem.png&diff=2907File:NullModem.png2008-09-30T23:32:17Z<p>Jpicotte: uploaded a new version of "Image:NullModem.png"</p>
<hr />
<div>RJ45/DB9 Null modem adapter</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=File:DB9M.png&diff=2906File:DB9M.png2008-09-30T23:29:25Z<p>Jpicotte: RJ45/DB9M adapter</p>
<hr />
<div>RJ45/DB9M adapter</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=File:DTE.png&diff=2905File:DTE.png2008-09-30T23:26:15Z<p>Jpicotte: uploaded a new version of "Image:DTE.png"</p>
<hr />
<div>RJ45/DB9 adapter diagram</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=EJTAG_ID_Codes_and_Implementation_Registers&diff=2200EJTAG ID Codes and Implementation Registers2007-10-04T16:35:12Z<p>Jpicotte: </p>
<hr />
<div>When an EJTAG system is reset, the data register is automatically filled with the result of an IDCODE instruction. This code usually includes the processor and the manufacturer, although it is not a standard. The important part of the IDCODE is using it to determine if your host hardware is communicating with your target. Whether or not the host speaks fluent jtag, if it can navigate to the data register and shift out the contents, one can see if the electrical connection is sound.<br />
<br />
'''IDCODEs'''<br />
<br />
WT54GLv1.1 : 0x0535217F<br />
<br />
WRT54Gv8 : 0x1535417F<br />
<br />
WRT350Nv1.0 : 0x0478517F<br />
<br />
<br />
The implementation code instruction returns an indication of features on the particular platform. Below is the information from the MIPS EJTAG Specification, document #MD00047.<br />
<br />
'''IMPCODEs'''<br />
<br />
WT54GLv1.1 : 0x00800904<br />
<br />
WRT54Gv8 : 0x00810904<br />
<br />
WRT350Nv1.0 : 0x00810904<br />
<br />
[[Image:impcode.png]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=EJTAG_ID_Codes_and_Implementation_Registers&diff=2199EJTAG ID Codes and Implementation Registers2007-10-04T16:34:32Z<p>Jpicotte: </p>
<hr />
<div>When an EJTAG system is reset, the data register is automatically filled with the result of an IDCODE instruction. This code usually includes the processor and the manufacturer, although it is not a standard. The important part of the IDCODE is using it to determine if your host hardware is communicating with your target. Whether or not the host speaks fluent jtag, if it can navigate to the data register and shift out the contents, one can see if the electrical connection is sound.<br />
<br />
'''IDCODEs'''<br />
<br />
WT54GLv1.1 : 0x0535217F<br />
<br />
WRT54Gv8 : 0x1535417F<br />
<br />
WRT350Nv1.0 : 0x0478517F<br />
<br />
<br />
The implementation code instruction returns an indication of features on the particular platform. Below is the information from the MIPS EJTAG Specification, document #MD00047.<br />
<br />
'''IMPCODEs'''<br />
<br />
WT54GLv1.1 : 0x00800904<br />
<br />
WRT54Gv8 : 0x00810904<br />
<br />
WRT350Nv1.0 : 0x00810904<br />
<br />
[[Image:impcode.png]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=File:Impcode.png&diff=2198File:Impcode.png2007-10-04T16:15:44Z<p>Jpicotte: MIPS EJTAG Specification description of implementation code register contents</p>
<hr />
<div>MIPS EJTAG Specification description of implementation code register contents</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=EJTAG_ID_Codes_and_Implementation_Registers&diff=2197EJTAG ID Codes and Implementation Registers2007-10-04T16:14:46Z<p>Jpicotte: </p>
<hr />
<div>When an EJTAG system is reset, the data register is automatically filled with the result of an IDCODE instruction. This code usually includes the processor and the manufacturer, although it is not a standard. The important part of the IDCODE is using it to determine if your host hardware is communicating with your target. Whether or not the host speaks fluent jtag, if it can navigate to the data register and shift out the contents, one can see if the electrical connection is sound.<br />
<br />
'''IDCODEs'''<br />
<br />
WT54GLv1.1 :<br />
<br />
WRT54Gv8 :<br />
<br />
WRT350Nv1.0 : 0x0478517F<br />
<br />
<br />
The implementation code instruction returns an indication of features on the particular platform. Below is the information from the MIPS EJTAG Specification, document #MD00047.<br />
<br />
'''IMPCODEs'''<br />
<br />
WT54GLv1.1 : 0x00800904<br />
<br />
WRT54Gv8 :<br />
<br />
WRT350Nv1.0 : 0x00810904<br />
<br />
[[Image:impcode.png]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=EJTAG_ID_Codes_and_Implementation_Registers&diff=2196EJTAG ID Codes and Implementation Registers2007-10-04T16:13:56Z<p>Jpicotte: New page: When an EJTAG system is reset, the data register is automatically filled with the result of an IDCODE instruction. This code usually includes the processor and the manufacturer, although ...</p>
<hr />
<div>When an EJTAG system is reset, the data register is automatically filled with the result of an IDCODE instruction. This code usually includes the processor and the manufacturer, although it is not a standard. The important part of the IDCODE is using it to determine if your host hardware is communicating with your target. Whether or not the host speaks fluent jtag, if it can navigate to the data register and shift out the contents, one can see if the electrical connection is sound.<br />
<br />
'''IDCODEs'''<br />
WT54GLv1.1 :<br />
WRT54Gv8 :<br />
WRT350Nv1.0 : 0x0478517F<br />
<br />
The implementation code instruction returns an indication of features on the particular platform. Below is the information from the MIPS EJTAG Specification, document #MD00047.<br />
<br />
'''IMPCODEs'''<br />
WT54GLv1.1 : 0x00800904<br />
WRT54Gv8 :<br />
WRT350Nv1.0 : 0x00810904<br />
[[Image:impcode.png]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=EJTAG&diff=2195EJTAG2007-10-04T15:43:01Z<p>Jpicotte: </p>
<hr />
<div>EJTAG is a MIPS-specific extension of IEEE 1149.1, the Joint Test Action Group.<br />
Allows interfacing with additional logic in SoC<br />
* direct control of processor for step-by-step debugging<br />
* access to busses and registers<br />
** aids in debugging<br />
** possible usage as additional peripheral data bus<br />
** direct writing to flash for firmware updates (and de-bricking)<br />
<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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.<br />
<br />
<br />
== Specific Implementations ==<br />
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]].<br />
<br />
<br />
<br />
== Probes ==<br />
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.<br />
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.<br />
<br />
<br />
<br />
[[Image:Te_jtag_cable.png|thumb|900px|center|Total Embedded buffered cable]]<br />
[[Image:Wiggler.png|thumb|700px|center|"wiggler" clone from OpenWRT]]<br />
[[Image:JTAGunbuffered.png|thumb|400px|center|unbuffered cable from OpenWRT; used by de-brick utility]]<br />
<br />
Return to [[Summer 2007]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=EJTAG&diff=2194EJTAG2007-10-04T15:34:58Z<p>Jpicotte: </p>
<hr />
<div>EJTAG is a MIPS-specific extension of IEEE 1149.1, the Joint Test Action Group.<br />
Allows interfacing with additional logic in SoC<br />
* direct control of processor for step-by-step debugging<br />
* access to busses and registers<br />
** aids in debugging<br />
** possible usage as additional peripheral data bus<br />
** direct writing to flash for firmware updates (and de-bricking)<br />
<br />
For anyone investigating the capabilities of the WRT54GL EJTAG system, the instruction value is a full 8 bits, not the 5 bits required by specification.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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.<br />
<br />
<br />
== Probes ==<br />
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.<br />
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.<br />
<br />
<br />
<br />
[[Image:Te_jtag_cable.png|thumb|900px|center|Total Embedded buffered cable]]<br />
[[Image:Wiggler.png|thumb|600px|center|"wiggler" clone from OpenWRT]]<br />
[[Image:JTAGunbuffered.png|thumb|500px|center|unbuffered cable from OpenWRT; used by de-brick utility]]<br />
<br />
Return to [[Summer 2007]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=WRT54G&diff=1990WRT54G2007-07-24T22:12:25Z<p>Jpicotte: </p>
<hr />
<div>{{Cleanup}}<br />
<br />
Transceiver from GL causes dropped characters; using [http://www.linksys.com Linksys] transceiver<br />
* <strike>possibly solved by "tighter" transceiver construction</strike><br />
* construction of transceiver using Analog Devices ADM202JN using .22uF capacitors in charge pump (C1 + C2)<br />
* possibility of strapping additional capacitance across internal condensers of Maxim transceiver<br />
** pin8:C1+ ; pin13:C1- using 0.1uF or greater capacitor<br />
** pin11:C2+ ; pin10:C2- using 0.1uF or greater capacitor<br />
<br />
== loading CFE ==<br />
<br />
VxWorks will flash over itself with CFE - http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54G<br />
<br />
Attempted to load micro openWRT kernel and CFE over VxWorks<br />
* upload failed - incompatible browser?<br />
* despite successful re-load of original firmware, bootloader refuses to find image on flash<br />
* possible solutions are loading fresh VxWorks from network or reloading flash through [[EJTAG]] port<br />
<br />
== loading XINU ==<br />
<br />
Control-C interrupts VxWorks loader, as it does in CFE.<br />
VxWorks has an advantage over CFE in that it will remember bootloader settings for tftp host after powercycle. This removes the need for special xinu-console script to talk to CFE. Just run xinu-console, download compiled boot image, and powercycle.<br />
<br />
Settings for VxWorks bootloader:<br />
* boot device: vl0<br />
* host name: morbius<br />
* file name: {backend name}.boot<br />
* inet on ethernet: 192.168.6.{assigned by morbius}<br />
* host inet: 192.168.6.10<br />
* flags 0x88 --tftp and quickboot<br />
<br />
Changes to current XINU revision for 'G' compatibility: +<br />
* loader/start.S<br />
** change max physical address from 0x81000000 to 0x80800000 (cut in half)<br />
** removal of cfe_api.c from loader, remove references in start.S $<br />
** replaced CFE cache flushing with fresh cache initialization function<br />
** altered mips.h for macros in loader cache init function<br />
* system/xdone.c - remove CFE_exit(), add new halt() function<br />
* uart/uartInit.c<br />
** remove '''ucptr->uart_dll = 0x0B;'''<br />
** remove '''ucptr->uart_dlm = 0x00;'''<br />
** If one queries the hardware, values to replace '''0B''' and '''00''' can be identified, '''0E''' and '''00'''<br />
<br />
<br />
+ Loader now reads CPU revision number from CP0 PRId register. This automatically sets max physical address and UART baud rate divisor based on router model.<br />
<br />
The CFE cache initialization has been replaced in XINU v1.0 for WRT54G compatibility.<br />
<br />
== See also ==<br />
* [[WRT54GL]]<br />
* [http://en.wikipedia.org/wiki/WRT54G WRT54G Wiki]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=EJTAG&diff=1985EJTAG2007-07-24T21:49:24Z<p>Jpicotte: </p>
<hr />
<div>EJTAG is a MIPS-specific extension of IEEE 1149.1, the Joint Test Action Group.<br />
Allows interfacing with additional logic in SoC<br />
* direct control of processor for step-by-step debugging<br />
* access to busses and registers<br />
** aids in debugging<br />
** possible usage as additional peripheral data bus<br />
** direct writing to flash for firmware updates (and de-bricking)<br />
<br />
For anyone investigating the capabilities of the WRT54GL EJTAG system, the instruction value is a full 8 bits, not the 5 bits required by specification.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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.<br />
<br />
<br />
== Probes ==<br />
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.<br />
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.<br />
<br />
<br />
<br />
[[Image:Te_jtag_cable.png|thumb|900px|center|Total Embedded buffered cable]]<br />
[[Image:Wiggler.png|thumb|600px|center|"wiggler" clone from OpenWRT]]<br />
[[Image:JTAGunbuffered.png|thumb|700px|center|unbuffered cable from OpenWRT; used by de-brick utility]]<br />
<br />
Return to [[Summer 2007]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Modify_the_Linksys_hardware&diff=1984Modify the Linksys hardware2007-07-23T16:29:20Z<p>Jpicotte: </p>
<hr />
<div>== Summary ==<br />
<br />
This will walk through adding hardware to a [http://www.linksys.com Linksys] [[WRT54GL]] wireless router that will take advantage of existing leads on the PCB for two UART connections, which will be exposed as DB9 connectors mounted to the faceplate of the router. These connections can be used to communicate with the serial console for [[XINU]] and also to interact with the [[Common Firmware Environment]]'s command line interface. Gaining direct access to [[CFE]] is a key step towards being able to run [[XINU]] on the router.<br />
<br />
== Before Starting ==<br />
=== Parts List ===<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
! Quantity<br />
! Part Name<br />
! Details<br />
! Part / Model Number<br />
! Price<br />
|- <br />
| 1<br />
| LinkSys [[WRT54GL]] Router<br />
| 802.11b/g wireless broadband router<br />
| [http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1133202177241&pagename=Linksys%2FCommon%2FVisitorWrapper Linksys WRT54GL]<br />
| ~$65.00<br />
|-<br />
| 1<br />
| Ribbon cable<br />
| 28 AWG, 10 conductor, 25'<br />
| Jameco 643508CM<br />
| $4.99<br />
|-<br />
| 1<br />
| IDC socket connector<br />
| 0.1”, 10 conductor <br />
| Jameco 32491CM<br />
| $0.25<br />
|-<br />
| 1<br />
| IDC shrouded header<br />
| 0.1”, 10 conductor<br />
| Jameco 67811CM<br />
| $0.33<br />
|-<br />
| 1<br />
| RS232 Transmitter/Receiver<br />
| IC 2DVR/2RCVR RS232 5V 20-DIP<br />
| DigiKey MAX233CPP-ND<br />
| $7.45<br />
|-<br />
| 1<br />
| DB9 Female<br />
| 22AWG,SOLDER CUP<br />
| Jameco 15771CM<br />
| $0.59<br />
|-<br />
| 1<br />
| DB9 Male<br />
| 22AWG,SOLDER CUP<br />
| Jameco 15747CM<br />
| $0.59<br />
|-<br />
|}<br />
<br />
(We provide this parts list as a data point; we offer no guarantees about current prices, and it is not our intent to endorse any particular vendor.)<br />
<br />
=== Tools List ===<br />
* Soldering Iron<br />
* Dremel tool (for cutting holes in plastic case)<br />
* Multimeter, or some other way of checking for proper connections<br />
<br />
== Steps to Modify the Hardware ==<br />
<br />
=== Task One: Open the Router ===<br />
<br />
[[Image:Opening-linksys.jpg|thumb|400px|center|It's really very easy.]]<br />
<br />
There are no screws or tools needed to open the router, just pop open the front with your thumbs as shown in the picture. Some nice [http://voidmain.is-a-geek.net/redhat/wrt54g_revival.html illustrated opening instructions] can be found for a more detailed explanation of this step<br />
<br />
'''DO NOTE: This is where the warranty on the router is voided!'''<br />
<br />
=== Task Two: Attach the Serial Header ===<br />
<br />
[[Image:Wrt54gl-layout.jpg|thumb|250px|left|An overhead view to get your bearings. The serial header is (D) here.]]<br />
Once the PCB has been removed from the case, locate the serial header holes provided by LinkSys. This would be a grid of 10 holes (5x2) located on the bottom-right corner of the board when the antennae stubs are on top (see the top-down photo for clarification). [[Image:Serial.jpg|thumb|250px|right|A closer look at our attached serial header.]] These ten holes hold all of the input and output for the two serial interfaces--UART0, and UART1--on the device.<br />
<br />
Now, we could just solder wires right onto these holes, but a by placing a nice 10-pin header on the board we can easily attach and detach a 10 connection cable. This is where you will use your '''soldering iron''' to solder the '''IDC shrouded header''' onto the board.<br />
<br />
This will be the only soldering required for the LinkSys PCB. The rest of the work will be done wiring the MAX233A transceiver and the DB9 connectors correctly and then the finished product just has to be plugged it into this header.<br />
<br />
=== Task Three: Wire Serial Header to MAX233A ===<br />
<br />
[[Image:MAX233A.png|thumb|300px|left|Diagram showing connections from the MAX233A to the DB9 connectors and to the board. Note pins 4 and 6 on the board header.]]<br />
<br />
Using information on the diagram, make the connections from the '''IDC shrouded header''' to the [[MAX233A|MAX233A RS232 Transmitter/Receiver]] chip using your '''soldering iron'''. As you can see from the photos, we did this with the '''ribbon cable''' from our parts list. The '''IDC socket connector''' goes on one end of the cable, and the correct connections are made to the '''RS232 Transmitter/Receiver''' on the other. Because we will be mounting our DB9 connectors to the front of the case, this will allow for easy disconnection and opening of the case. In terms of cable length, try and decide where you are going to mount the MAX233A on the outer case so you can estimate correctly.<br />
<br />
''Be sure to test all of your connections thoroughly before proceeding.''<br />
<br />
=== Task Four: Wire the DB9 Connectors to the MAX233A ===<br />
<br />
[[Image:Maxim.jpg|thumb|200px|right|The MAX233A wired to the ribbon cable and the DB9 connectors.]]<br />
<br />
For the following connections, you are going to use the '''soldering iron''' and either chopped up portions of the '''ribbon cable''' or some other wire (which would probably be more convenient).<br />
<br />
Checking the [[Wiring|wiring diagram]] again, note that there are several loopback connections per DB9 connector in order to fake RS232 hardware flow control compliance. It would be a good idea to get these out of the way first. Then, make the connections required from the '''RS232 Transmitter/Receiver''' to the DB9 connectors, remembering to leave enough slack for where you plan on mounting the MAX233A and the connectors. <br />
<br />
''Again, before mounting anything, test that all connections correspond to the diagram.''<br />
<br />
=== Task Five: Mount DB9 Connectors to the Router Faceplate ===<br />
<br />
[[Image:faceplate.jpg|thumb|200px|right|This is the final version of the faceplate of our router, with the two external serial ports attached and ready to go.]]<br />
<br />
Using your trusty '''dremel''' cut a few DB9 shaped holes in the plastic casing of the router. There are several options for placement; we chose the front so that multiple routers would still be stackable. The picture at right shows the placement of our connectors with wires attached. The fit is quite tight; you may wish to consider only installing one jack (you only need port 0 to communicate with the router, your plans may not call for using the second serial port) or installing them horizontally instead of vertically.<br />
<br />
Using either epoxy or mounting screws (we used a combination of both, as one of our jacks could not fit a hole for a screw), secure the connectors to the case.<br />
<br />
''Following the theme, now would be a good time to do a final test on all connections, because next we are closing things up.''<br />
<br />
=== Task Six: Close the Router ===<br />
<br />
This final task is best described in photos:<br />
{|align="center"<br />
|-<br />
| [[Image:attach-back.jpg|thumb|350px|Now that everything is connected we can re-assemble it. First you put on the back/top half. Keyed ribbon cable is plugged in to serial port header on circuit board.]]<br />
| [[Image:attach-front.jpg|thumb|350px|Next you can carefully install the front half (making sure not to break any of the wires we have).]]<br />
|-<br />
|}<br />
=== Task Seven: Rejoice ===<br />
<br />
[[Image:final.jpg|thumb|500px|center|Now you have a WRT54GL with two serial ports installed and ready to run your own operating system.]]<br />
<br />
== What to do next? ==<br />
<br />
Connect UART0 to a computer and follow the next HOWTO on using a PC to [[HOWTO:Connect to a modified router|connect to a modified router]].</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=WRT54G&diff=1980WRT54G2007-07-20T21:44:42Z<p>Jpicotte: /* loading XINU */</p>
<hr />
<div>{{Cleanup}}<br />
<br />
Transceiver from GL causes dropped characters; using [http://www.linksys.com Linksys] transceiver<br />
* possibly solved by "tighter" transceiver construction<br />
<br />
== loading CFE ==<br />
<br />
VxWorks will flash over itself with CFE - http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54G<br />
<br />
Attempted to load micro openWRT kernel and CFE over VxWorks<br />
* upload failed - incompatible browser?<br />
* despite successful re-load of original firmware, bootloader refuses to find image on flash<br />
* possible solutions are loading fresh VxWorks from network or reloading flash through [[EJTAG]] port<br />
<br />
== loading XINU ==<br />
<br />
Control-C interrupts VxWorks loader, as it does in CFE.<br />
VxWorks has an advantage over CFE in that it will remember bootloader settings for tftp host after powercycle. This removes the need for special xinu-console script to talk to CFE. Just run xinu-console, download compiled boot image, and powercycle.<br />
<br />
Settings for VxWorks bootloader:<br />
* boot device: vl0<br />
* host name: morbius<br />
* file name: {backend name}.boot<br />
* inet on ethernet: 192.168.6.{assigned by morbius}<br />
* host inet: 192.168.6.10<br />
* flags 0x88 --tftp and quickboot<br />
<br />
Changes to current XINU revision for 'G' compatibility: +<br />
* loader/start.S<br />
** change max physical address from 0x81000000 to 0x80800000 (cut in half)<br />
** removal of cfe_api.c from loader, remove references in start.S $<br />
** replaced CFE cache flushing with fresh cache initialization function<br />
** altered mips.h for macros in loader cache init function<br />
* system/xdone.c - remove CFE_exit(), add new halt() function<br />
* uart/uartInit.c<br />
** remove '''ucptr->uart_dll = 0x0B;'''<br />
** remove '''ucptr->uart_dlm = 0x00;'''<br />
** If one queries the hardware, values to replace '''0B''' and '''00''' can be identified, '''0E''' and '''00'''<br />
<br />
<br />
+ Loader now reads CPU revision number from CP0 PRId register. This automatically sets max physical address and UART baud rate divisor based on router model.<br />
<br />
The CFE cache initialization has been replaced in XINU v1.0 for WRT54G compatibility.<br />
<br />
== See also ==<br />
* [[WRT54GL]]<br />
* [http://en.wikipedia.org/wiki/WRT54G WRT54G Wiki]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=WRT54G&diff=1979WRT54G2007-07-20T21:44:04Z<p>Jpicotte: /* loading XINU */</p>
<hr />
<div>{{Cleanup}}<br />
<br />
Transceiver from GL causes dropped characters; using [http://www.linksys.com Linksys] transceiver<br />
* possibly solved by "tighter" transceiver construction<br />
<br />
== loading CFE ==<br />
<br />
VxWorks will flash over itself with CFE - http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54G<br />
<br />
Attempted to load micro openWRT kernel and CFE over VxWorks<br />
* upload failed - incompatible browser?<br />
* despite successful re-load of original firmware, bootloader refuses to find image on flash<br />
* possible solutions are loading fresh VxWorks from network or reloading flash through [[EJTAG]] port<br />
<br />
== loading XINU ==<br />
<br />
Control-C interrupts VxWorks loader, as it does in CFE.<br />
VxWorks has an advantage over CFE in that it will remember bootloader settings for tftp host after powercycle. This removes the need for special xinu-console script to talk to CFE. Just run xinu-console, download compiled boot image, and powercycle.<br />
<br />
Settings for VxWorks bootloader:<br />
* boot device: vl0<br />
* host name: morbius<br />
* file name: {backend name}.boot<br />
* inet on ethernet: 192.168.6.{assigned by morbius}<br />
* host inet: 192.168.6.10<br />
* flags 0x88 --tftp and quickboot<br />
<br />
Changes to current XINU revision for 'G' compatibility:<br />
* loader/start.S<br />
** change max physical address from 0x81000000 to 0x80800000 (cut in half)<br />
** removal of cfe_api.c from loader, remove references in start.S $<br />
** replaced CFE cache flushing with fresh cache initialization function<br />
** altered mips.h for macros in loader cache init function<br />
* system/xdone.c - remove CFE_exit(), add new halt() function<br />
* uart/uartInit.c<br />
** remove '''ucptr->uart_dll = 0x0B;'''<br />
** remove '''ucptr->uart_dlm = 0x00;'''<br />
** If one queries the hardware, values to replace '''0B''' and '''00''' can be identified, '''0E''' and '''00'''<br />
<br />
<br />
Loader now reads CPU revision number from CP0 PRId register. This automatically sets max physical address and UART baud rate divisor based on router model.<br />
<br />
The CFE cache initialization has been replaced in XINU v1.0 for WRT54G compatibility.<br />
<br />
== See also ==<br />
* [[WRT54GL]]<br />
* [http://en.wikipedia.org/wiki/WRT54G WRT54G Wiki]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=WRT54G&diff=1978WRT54G2007-07-20T21:43:27Z<p>Jpicotte: /* loading XINU */</p>
<hr />
<div>{{Cleanup}}<br />
<br />
Transceiver from GL causes dropped characters; using [http://www.linksys.com Linksys] transceiver<br />
* possibly solved by "tighter" transceiver construction<br />
<br />
== loading CFE ==<br />
<br />
VxWorks will flash over itself with CFE - http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54G<br />
<br />
Attempted to load micro openWRT kernel and CFE over VxWorks<br />
* upload failed - incompatible browser?<br />
* despite successful re-load of original firmware, bootloader refuses to find image on flash<br />
* possible solutions are loading fresh VxWorks from network or reloading flash through [[EJTAG]] port<br />
<br />
== loading XINU ==<br />
<br />
Control-C interrupts VxWorks loader, as it does in CFE.<br />
VxWorks has an advantage over CFE in that it will remember bootloader settings for tftp host after powercycle. This removes the need for special xinu-console script to talk to CFE. Just run xinu-console, download compiled boot image, and powercycle.<br />
<br />
Settings for VxWorks bootloader:<br />
* boot device: vl0<br />
* host name: morbius<br />
* file name: {backend name}.boot<br />
* inet on ethernet: 192.168.6.{assigned by morbius}<br />
* host inet: 192.168.6.10<br />
* flags 0x88 --tftp and quickboot<br />
<br />
Changes to current XINU revision for 'G' compatibility:<br />
* loader/start.S<br />
** change max physical address from 0x81000000 to 0x80800000 (cut in half)<br />
** removal of cfe_api.c from loader, remove references in start.S $<br />
** replaced CFE cache flushing with fresh cache initialization function<br />
** altered mips.h for macros in loader cache init function<br />
* system/xdone.c - remove CFE_exit(), add new halt() function<br />
* uart/uartInit.c<br />
** remove '''ucptr->uart_dll = 0x0B;'''<br />
** remove '''ucptr->uart_dlm = 0x00;'''<br />
** If one queries the hardware, values to replace '''0B''' and '''00''' can be identified, '''0E''' and '''00'''<br />
<br />
<br />
Loader now reads CPU revision number from CP0 PRId register. This automatically sets max physical address and UART baud rate divisor based on router model.<br />
<br />
The CFE cache initialization has been removed from XINU v1.0 for WRT54G compatibility.<br />
<br />
== See also ==<br />
* [[WRT54GL]]<br />
* [http://en.wikipedia.org/wiki/WRT54G WRT54G Wiki]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=WRT54G&diff=1977WRT54G2007-07-20T21:42:52Z<p>Jpicotte: /* loading XINU */</p>
<hr />
<div>{{Cleanup}}<br />
<br />
Transceiver from GL causes dropped characters; using [http://www.linksys.com Linksys] transceiver<br />
* possibly solved by "tighter" transceiver construction<br />
<br />
== loading CFE ==<br />
<br />
VxWorks will flash over itself with CFE - http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54G<br />
<br />
Attempted to load micro openWRT kernel and CFE over VxWorks<br />
* upload failed - incompatible browser?<br />
* despite successful re-load of original firmware, bootloader refuses to find image on flash<br />
* possible solutions are loading fresh VxWorks from network or reloading flash through [[EJTAG]] port<br />
<br />
== loading XINU ==<br />
<br />
Control-C interrupts VxWorks loader, as it does in CFE.<br />
VxWorks has an advantage over CFE in that it will remember bootloader settings for tftp host after powercycle. This removes the need for special xinu-console script to talk to CFE. Just run xinu-console, download compiled boot image, and powercycle.<br />
<br />
Settings for VxWorks bootloader:<br />
* boot device: vl0<br />
* host name: morbius<br />
* file name: {backend name}.boot<br />
* inet on ethernet: 192.168.6.{assigned by morbius}<br />
* host inet: 192.168.6.10<br />
* flags 0x88 --tftp and quickboot<br />
<br />
Changes to current XINU revision for 'G' compatibility:<br />
* loader/start.S<br />
** change max physical address from 0x81000000 to 0x80800000 (cut in half)<br />
** removal of cfe_api.c from loader, remove references in start.S $<br />
** replaced CFE cache flushing with fresh cache initialization function<br />
** altered mips.h for macros in loader cache init function<br />
* system/xdone.c - remove CFE_exit(), add new halt() function<br />
* uart/uartInit.c<br />
** remove '''ucptr->uart_dll = 0x0B;'''<br />
** remove '''ucptr->uart_dlm = 0x00;'''<br />
** If one queries the hardware, values to replace '''0B''' and '''00''' can be identified, '''0E''' and '''00'''<br />
<br />
<br />
Loader now reads CPU revision number from CP0 PRId register. This automatically sets max physical address and UART baud rate divisor based on router model.<br />
The CFE cache initialization has benn removed from XINU v1.0 for WRT54G compatibility.<br />
<br />
== See also ==<br />
* [[WRT54GL]]<br />
* [http://en.wikipedia.org/wiki/WRT54G WRT54G Wiki]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=WRT54G&diff=1976WRT54G2007-07-20T21:39:27Z<p>Jpicotte: /* loading XINU */</p>
<hr />
<div>{{Cleanup}}<br />
<br />
Transceiver from GL causes dropped characters; using [http://www.linksys.com Linksys] transceiver<br />
* possibly solved by "tighter" transceiver construction<br />
<br />
== loading CFE ==<br />
<br />
VxWorks will flash over itself with CFE - http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54G<br />
<br />
Attempted to load micro openWRT kernel and CFE over VxWorks<br />
* upload failed - incompatible browser?<br />
* despite successful re-load of original firmware, bootloader refuses to find image on flash<br />
* possible solutions are loading fresh VxWorks from network or reloading flash through [[EJTAG]] port<br />
<br />
== loading XINU ==<br />
<br />
Control-C interrupts VxWorks loader, as it does in CFE.<br />
VxWorks has an advantage over CFE in that it will remember bootloader settings for tftp host after powercycle. This removes the need for special xinu-console script to talk to CFE. Just run xinu-console, download compiled boot image, and powercycle.<br />
<br />
Settings for VxWorks bootloader:<br />
* boot device: vl0<br />
* host name: morbius<br />
* file name: {backend name}.boot<br />
* inet on ethernet: 192.168.6.{assigned by morbius}<br />
* host inet: 192.168.6.10<br />
* flags 0x88 --tftp and quickboot<br />
<br />
Changes to current XINU revision for 'G' compatibility:<br />
* loader/start.S<br />
** change max physical address from 0x81000000 to 0x80800000 (cut in half)<br />
** removal of cfe_api.c from loader, remove references in start.S<br />
** replaced CFE cache flushing with fresh cache initialization function<br />
** altered mips.h for macros in loader cache init function<br />
* system/xdone.c - remove CFE_exit(), add new halt() function<br />
* uart/uartInit.c<br />
** remove '''ucptr->uart_dll = 0x0B;'''<br />
** remove '''ucptr->uart_dlm = 0x00;'''<br />
** If one queries the hardware, values to replace '''0B''' and '''00''' can be identified, '''0E''' and '''00'''<br />
<br />
<br />
Loader now reads CPU revision number from CP0 PRId register. This automatically sets max physical address and UART baud rate divisor based on router model.<br />
<br />
== See also ==<br />
* [[WRT54GL]]<br />
* [http://en.wikipedia.org/wiki/WRT54G WRT54G Wiki]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=EJTAG&diff=1938EJTAG2007-07-15T16:24:21Z<p>Jpicotte: /* Debugging */</p>
<hr />
<div>EJTAG is a MIPS-specific extension of IEEE 1149.1, the Joint Test Action Group.<br />
Allows interfacing with additional logic in SoC<br />
* direct control of processor for step-by-step debugging<br />
* access to busses and registers<br />
** aids in debugging<br />
** possible usage as additional peripheral data bus<br />
** direct writing to flash for firmware updates (and de-bricking)<br />
<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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.<br />
<br />
Note that the unbuffered cable at the bottom of this page is only proven functional in writing to the Test Access Port. It may not read data back from the target device.<br />
<br />
[[Image:Te_jtag_cable.png|thumb|900px|center|Total Embedded buffered cable]]<br />
[[Image:Wiggler.png|thumb|600px|center|"wiggler" clone from OpenWRT]]<br />
[[Image:JTAGunbuffered.png|thumb|700px|center|unbuffered cable from OpenWRT; used by de-brick utility]]<br />
<br />
Return to [[Summer 2007]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=EJTAG&diff=1937EJTAG2007-07-15T16:23:04Z<p>Jpicotte: /* Debugging */</p>
<hr />
<div>EJTAG is a MIPS-specific extension of IEEE 1149.1, the Joint Test Action Group.<br />
Allows interfacing with additional logic in SoC<br />
* direct control of processor for step-by-step debugging<br />
* access to busses and registers<br />
** aids in debugging<br />
** possible usage as additional peripheral data bus<br />
** direct writing to flash for firmware updates (and de-bricking)<br />
<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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.<br />
<br />
Note that the unbuffered cable at the bottom of this page is only proven functional in writing to the Test Access Port. It may not read data back from the target device.<br />
<br />
[[Image:Te_jtag_cable.png|thumb|900px|center|Total Embedded buffered cable]]<br />
[[Image:Wiggler.png|thumb|600px|center|"wiggler" from OpenWRT]]<br />
[[Image:JTAGunbuffered.png|thumb|700px|center|unbuffered cable from OpenWRT; used by de-brick utility]]<br />
<br />
Return to [[Summer 2007]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=WRT350N&diff=1918WRT350N2007-07-12T22:49:12Z<p>Jpicotte: </p>
<hr />
<div>[[Image:WRT350N.png|thumb|900px|left|The Satellite]]<br />
<br />
== Caveats out of the box ==<br />
This router claims to use CFE version 1.0.37 before booting into linux. Although, it appears slightly different than the version on the lab's WRT54GL's. Most noticeably, CFE does not recognize the ethernet hardware when first booting. Recognizing NVRAM settings and communicating with the network is reserved for after linux is up. This made the device unable to load the XINU code using the "boot -elf..." command.<br />
A tip from the OpenWRT forums gives a little insight: [http://forum.openwrt.org/viewtopic.php?pid=47784 WRT350N bricked]<br />
<br />
A network cable was run from a front-end machine capable of communicating with the router at its default address of 192.168.1.1. From there, a blank image was tftp'd (using put) to the router during booting. The inability to verify this image as valid causes the device to drop to a CFE prompt--this time with the network communicating. At this point, one can use the standard procedure of ifconfig and boot commands as per WRT54GL protocol.<br />
Strangely, just as this procedure grew tedious, the WRT350N CFE prompt changed its disposition, and began communicating with the server as hoped. Apparently, beating the device with empty images through tftp does the trick.</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=WRT350N&diff=1917WRT350N2007-07-12T22:48:05Z<p>Jpicotte: </p>
<hr />
<div>[[Image:WRT350N.png|thumb|900px|left|The Satellite]]<br />
<br />
== Caveats out of the box ==<br />
This router claims to use CFE version 1.0.37 before booting into linux. Although, it appears slightly different than the version on the lab's WRT54GL's. Most noticeably, CFE does not recognize the ethernet hardware when first booting. Recognizing NVRAM settings and communicating with the network is reserved for after linux is up. This made the device unable to load the XINU code using the "boot -elf..." command.<br />
A tip from the OpenWRT forums gives a little insight: [http://forum.openwrt.org/viewtopic.php?pid=47784]<br />
<br />
A network cable was run from a front-end machine capable of communicating with the router at its default address of 192.168.1.1. From there, a blank image was tftp'd (using put) to the router during booting. The inability to verify this image as valid causes the device to drop to a CFE prompt--this time with the network communicating. At this point, one can use the standard procedure of ifconfig and boot commands as per WRT54GL protocol.<br />
Strangely, just as this procedure grew tedious, the WRT350N CFE prompt changed its disposition, and began communicating with the server as hoped. Apparently, beating the device with empty images through tftp does the trick.</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=WRT350N&diff=1916WRT350N2007-07-12T22:47:33Z<p>Jpicotte: </p>
<hr />
<div>[[Image:WRT350N.png|thumb|900px|left|The Satellite]]<br />
<br />
== Caveats out of the box ==<br />
This router claims to use CFE version 1.0.37 before booting into linux. Although, it appears slightly different than the version on the lab's 54GL's. Most noticeably, CFE does not recognize the ethernet hardware when first booting. Recognizing NVRAM settings and communicating with the network is reserved for after linux is up. This made the device unable to load the XINU code using the "boot -elf..." command.<br />
A tip from the OpenWRT forums gives a little insight: [http://forum.openwrt.org/viewtopic.php?pid=47784]<br />
<br />
A network cable was run from a front-end machine capable of communicating with the router at its default address of 192.168.1.1. From there, a blank image was tftp'd (using put) to the router during booting. The inability to verify this image as valid causes the device to drop to a CFE prompt--this time with the network communicating. At this point, one can use the standard procedure of ifconfig and boot commands as per WRT54GL protocol.<br />
Strangely, just as this procedure grew tedious, the WRT350N CFE prompt changed its disposition, and began communicating with the server as hoped. Apparently, beating the device with empty images through tftp does the trick.</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1915Serial adapter diagrams2007-07-12T21:54:25Z<p>Jpicotte: /* Null Modem */</p>
<hr />
<div>== RJ45/DB9 adapters ==<br />
Below are diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for UART 0 (DTE). The second diagram is for the platform-dependent UART 1 (DCE).<br />
[[Image:DTE.png|thumb|900px|left|UART 0, DTE]]<br clear="all" /><br />
[[Image:DCE.png|thumb|900px|left|UART 1, DCE]]<br clear="all" /><br />
<br />
== EtherLite to Baytech ==<br />
The third diagram represents the connection between the between the Baytech serial-controlled power strip and the EtherLite terminal annex. Note that for the particular RJ45/DB9 connectors used in this research, the colors of diagram three can be mated with the Signal labels from the first two diagrams (i.e. RTS = DB9 pin 7 = Blue).<br />
[[Image:BaytechWiring.png|thumb|500px|left|Wiring diagram for Baytech to Etherlite connection]]<br />
<br clear="all" /><br />
<br />
== Null Modem ==<br />
The null modem adapter is required to make connections between available UART 1 ports on two machines (UART 0 being in use for communicating results through xinu-console).<br />
[[Image:NullModem.png|thumb|400px|left|RJ45/DB9Female null modem adapter]]<br clear="all" /></div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=File:NullModem.png&diff=1914File:NullModem.png2007-07-12T21:52:42Z<p>Jpicotte: RJ45/DB9 Null modem adapter</p>
<hr />
<div>RJ45/DB9 Null modem adapter</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1913Serial adapter diagrams2007-07-12T21:52:13Z<p>Jpicotte: </p>
<hr />
<div>== RJ45/DB9 adapters ==<br />
Below are diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for UART 0 (DTE). The second diagram is for the platform-dependent UART 1 (DCE).<br />
[[Image:DTE.png|thumb|900px|left|UART 0, DTE]]<br clear="all" /><br />
[[Image:DCE.png|thumb|900px|left|UART 1, DCE]]<br clear="all" /><br />
<br />
== EtherLite to Baytech ==<br />
The third diagram represents the connection between the between the Baytech serial-controlled power strip and the EtherLite terminal annex. Note that for the particular RJ45/DB9 connectors used in this research, the colors of diagram three can be mated with the Signal labels from the first two diagrams (i.e. RTS = DB9 pin 7 = Blue).<br />
[[Image:BaytechWiring.png|thumb|500px|left|Wiring diagram for Baytech to Etherlite connection]]<br />
<br clear="all" /><br />
<br />
== Null Modem ==<br />
The null modem adapter is required to make connections between available UART 1 ports on two machines (UART 0 being in use for communicating results through xinu-console).<br />
[[Image:NullModem.png|thumb|500px|left|UART 1, DCE]]<br clear="all" /></div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1912Serial adapter diagrams2007-07-12T20:19:25Z<p>Jpicotte: </p>
<hr />
<div>== RJ45/DB9 adapters ==<br />
Below are diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for UART 0 (DTE). The second diagram is for the platform-dependent UART 1 (DCE).<br />
[[Image:DTE.png|thumb|900px|left|UART 0, DTE]]<br clear="all" /><br />
[[Image:DCE.png|thumb|900px|left|UART 1, DCE]]<br clear="all" /><br />
<br />
== EtherLite to Baytech ==<br />
The third diagram represents the connection between the between the Baytech serial-controlled power strip and the EtherLite terminal annex. Note that for the particular RJ45/DB9 connectors used in this research, the colors of diagram three can be mated with the Signal labels from the first two diagrams (i.e. RTS = DB9 pin 7 = Blue).<br />
[[Image:BaytechWiring.png|thumb|500px|left|Wiring diagram for Baytech to Etherlite connection]]<br />
<br clear="all" /><br />
<br />
== Null Modem ==<br />
The null modem adapter is required to make connections between available UART 1 ports on two machines (UART 0 being in use for communicating results through xinu-console).</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1911Serial adapter diagrams2007-07-12T20:18:15Z<p>Jpicotte: </p>
<hr />
<div>== RJ45/DB9 adapters ==<br />
Below are diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for UART 0 (DTE). The second diagram is for the platform-dependent UART 1 (DCE).<br />
[[Image:DTE.png|thumb|900px|left|UART 0, DTE]]{{clr}}<br />
[[Image:DCE.png|thumb|900px|left|UART 1, DCE]]{{clr}}<br />
<br />
== EtherLite to Baytech ==<br />
The third diagram represents the connection between the between the Baytech serial-controlled power strip and the EtherLite terminal annex. Note that for the particular RJ45/DB9 connectors used in this research, the colors of diagram three can be mated with the Signal labels from the first two diagrams (i.e. RTS = DB9 pin 7 = Blue).<br />
[[Image:BaytechWiring.png|thumb|500px|left|Wiring diagram for Baytech to Etherlite connection]]<br />
{{clr}}<br />
<br />
== Null Modem ==<br />
The null modem adapter is required to make connections between available UART 1 ports on two machines (UART 0 being in use for communicating results through xinu-console).</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1910Serial adapter diagrams2007-07-12T20:18:00Z<p>Jpicotte: </p>
<hr />
<div>== RJ45/DB9 adapters ==<br />
Below are diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for UART 0 (DTE). The second diagram is for the platform-dependent UART 1 (DCE).<br />
[[Image:DTE.png|thumb|900px|left|UART 0, DTE]]<br />
[[Image:DCE.png|thumb|900px|left|UART 1, DCE]]<br />
<br />
== EtherLite to Baytech ==<br />
The third diagram represents the connection between the between the Baytech serial-controlled power strip and the EtherLite terminal annex. Note that for the particular RJ45/DB9 connectors used in this research, the colors of diagram three can be mated with the Signal labels from the first two diagrams (i.e. RTS = DB9 pin 7 = Blue).<br />
[[Image:BaytechWiring.png|thumb|500px|left|Wiring diagram for Baytech to Etherlite connection]]<br />
{{clr}}<br />
<br />
== Null Modem ==<br />
The null modem adapter is required to make connections between available UART 1 ports on two machines (UART 0 being in use for communicating results through xinu-console).</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1909Serial adapter diagrams2007-07-12T20:13:36Z<p>Jpicotte: </p>
<hr />
<div>== RJ45/DB9 adapters ==<br />
Below are diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for UART 0 (DTE). The second diagram is for the platform-dependent UART 1 (DCE).<br />
[[Image:DTE.png|thumb|900px|left|UART 0, DTE]]<br />
[[Image:DCE.png|thumb|900px|left|UART 1, DCE]]<br />
<br />
== EtherLite to Baytech ==<br />
The third diagram represents the connection between the between the Baytech serial-controlled power strip and the EtherLite terminal annex. Note that for the particular RJ45/DB9 connectors used in this research, the colors of diagram three can be mated with the Signal labels from the first two diagrams (i.e. RTS = DB9 pin 7 = Blue).<br />
[[Image:BaytechWiring.png|thumb|500px|left|Wiring diagram for Baytech to Etherlite connection]]<br />
<br />
== Null Modem ==<br />
The null modem adapter is required to make connections between available UART 1 ports on two machines (UART 0 being in use for communicating results through xinu-console).</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Build_Backend_Pool&diff=1908Build Backend Pool2007-07-12T20:06:43Z<p>Jpicotte: /* Additional (Optional) hardware */</p>
<hr />
<div>== Summary ==<br />
<br />
This page details how to scale your laboratory environment up to a pool of backend target machines available for remote access.<br />
<br />
== The Big Picture ==<br />
[[Image:XINU-Lab-schematic.gif]]<br />
<br />
=== XINU Backends ===<br />
Backend targets upload a student's kernel over a private network on boot, and run the O/S directly. No simulations or emulation are involved; this is real hardware.<br />
<br />
MIPS targets: We use Linksys WRT54GL wireless routers (~$60) with [[HOWTO:Modify_the_Linksys_hardware|serial port modifications]] (~$10) running an embedded MIPS32 200MHz processor, 4 MB flash, 16 MB RAM, two UARTs, wired and wireless network interfaces.<br />
<br />
PowerPC targets: We use Apple G3 desktops (recycled) with 512 MB RAM, linear framebuffer, PCI bus, NIC, HD. Apple G4 MiniMac also supported.<br />
<br />
CISC targets: Classic XINU runs on Intel x86, Sun 3/Motorola 68K, Sparc, and VAX, among others.<br />
<br />
=== XINU Server ===<br />
A general purpose server with multiple network interfaces manages a private network for the XINU backends, using standard network protocols like DHCP and TFTP.<br />
<br />
Backend serial consoles can connect directly to server's serial ports, or, in larger installations, to a serial annex or concentrator that allows many more serial ports.<br />
<br />
A daemon running on the server allows users on frontend workstations to remotely access backend serial consoles, or upload fresh kernels. Optional rebooting hardware allows clients to remotely reset crashed backends.<br />
<br />
Our [[Console Tools]] are freely available for modern UNIX platforms, including Fedora Linux and Solaris.<br />
<br />
=== XINU Frontends ===<br />
General purpose computer laboratory workstations can compile the XINU kernel, using a standard GNU C compiler and UNIX toolchain. GCC crosscompilers are readily available when the frontend architecture does not match the backend architecture.<br />
<br />
Backend consoles can be connected directly to frontend serial ports, or frontends can communicate with the server daemon that manages collections of backend serial consoles.<br />
<br />
With fully remote console access, kernel upload and powercycling, any machine on the network is a potential frontend, and need not be physically near the XINU server and laboratory hardware. Students can work on their operating system projects from their dorm room computers.<br />
<br />
== Additional (Optional) hardware ==<br />
* Terminal Annex (EtherLite 32)<br />
* Serial-Controlled Power Strip (BayTech)<br />
* [[Serial adapter diagrams]]<br />
<br />
== The Server ==<br />
<br />
Our XINU Server is a PowerPC G5 XServe running Fedora Core Linux. We use this configuration as a model for the information below, but other architecture / O/S combinations are known to work, and there's no reason this shouldn't work for virtually any machine with two network interfaces running a modern UNIX O/S.<br />
<br />
=== DHCP Daemon ===<br />
<br />
Many modern firmware implementations will allow a device to automatically acquire an IP address using the DHCP protocol even before the O/S kernel begins to boot. The [[CFE]] on our Linksys backends will attempt to configure its primary ethernet interface when issued the command,<br />
<br />
ifconfig -auto eth0<br />
<br />
over the serial console. See [[HOWTO:Run your own code]] for more details.<br />
<br />
In our configuration, the XINU Server runs a DHCP daemon that is configured to supply addresses to backends on the private network. We use the<br />
standard '''dchp''' server package that comes stock with our Linux distribution (dhcp-3.0.5-3.fc6, as of this writing). Here is a sample configuration<br />
file, [http://www.mscs.mu.edu/~brylow/xinu/Morbius-dhcpd.conf dhcpd.conf]. Our configuration supplies a fixed IP address for each backend, based upon MAC address. It is important to note that the "filename" field designates a unique boot image for each backend; this allows each backend to boot a distinct image, customized by the student currently connected to that backend's serial console.<br />
<br />
=== TFTP Daemon ===<br />
Many modern firmware implementations will allow a device to upload a boot image over a network device using the Trivial File Transfer Protocol (TFTP). We use the stock TFTP server available with our Linux distribution (tftp-server-0.42-3.1, at this writing,) configured to answer requests on the private network, and with the /tftpboot directory writable by the xinu-console daemon user ID. Most TFTP daemons use TCP wrapper to regulate access; see the<br />
notes on security below.<br />
<br />
=== XINU Console Daemon ===<br />
The XINU Console Daemon and various associated utilities provide network clients with connectivity to backend consoles that are really only connected directly to the console host.<br />
The xinu-console software package is now freely available for UNIX console hosts and front end clients.<br />
<br />
[http://www.mscs.mu.edu/~brylow/xinu/xinu-console-2.02.tar.gz (GZipped tarball xinu-console-2.02.tar.gz)]<br />
<br />
[http://www.mscs.mu.edu/~brylow/xinu/xinu-console-2.02-2.src.rpm (Fedora Core Source RPM xinu-console-2.02-2.src.rpm)]<br />
<br />
The XINU Console Daemon uses TCP wrappers to prevent unauthorized access; see the notes on security below.<br />
<br />
== The Client ==<br />
<br />
=== Console Access ===<br />
Source for xinu-console included in Console Tools tarball. Explain environment variables. Ssh tunneling? Mips-console wrapper script.<br />
<br />
== Security ==<br />
<br />
A word on security. Isolated private network. TCP Wrappers. Iptables packet filtering.</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1906Serial adapter diagrams2007-07-12T20:03:34Z<p>Jpicotte: EtherLite terminal annex adapter diagrams moved to Serial adapter diagrams</p>
<hr />
<div>Below are diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for port 1 (DTE). The second diagram is for the platform-dependent port 2 (DCE). The third diagram represents the connection between the between the Baytech serial-controlled power strip and the EtherLite terminal annex. Note that for the particular RJ45/DB9 connectors used in this research, the colors of diagram three can be mated with the Signal labels from the first two diagrams (i.e. RTS = DB9 pin 7 = Blue).<br />
[[Image:DTE.png|thumb|900px|left|Port 1, DTE]]<br />
[[Image:DCE.png|thumb|900px|left|Port 2, DCE]]<br />
[[Image:BaytechWiring.png|thumb|500px|left|Wiring diagram for Baytech to Etherlite connection]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=EtherLite_terminal_annex_adapter_diagrams&diff=1907EtherLite terminal annex adapter diagrams2007-07-12T20:03:34Z<p>Jpicotte: EtherLite terminal annex adapter diagrams moved to Serial adapter diagrams</p>
<hr />
<div>#REDIRECT [[Serial adapter diagrams]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1904Serial adapter diagrams2007-07-12T19:49:06Z<p>Jpicotte: </p>
<hr />
<div>Below are diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for port 1 (DTE). The second diagram is for the platform-dependent port 2 (DCE). The third diagram represents the connection between the between the Baytech serial-controlled power strip and the EtherLite terminal annex. Note that for the particular RJ45/DB9 connectors used in this research, the colors of diagram three can be mated with the Signal labels from the first two diagrams (i.e. RTS = DB9 pin 7 = Blue).<br />
[[Image:DTE.png|thumb|900px|left|Port 1, DTE]]<br />
[[Image:DCE.png|thumb|900px|left|Port 2, DCE]]<br />
[[Image:BaytechWiring.png|thumb|500px|left|Wiring diagram for Baytech to Etherlite connection]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1903Serial adapter diagrams2007-07-12T19:48:25Z<p>Jpicotte: </p>
<hr />
<div>== Serial bay adapters ==<br />
Below are diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for port 1 (DTE). The second diagram is for the platform-dependent port 2 (DCE). The third diagram represents the connection between the between the Baytech serial-controlled power strip and the EtherLite terminal annex. Note that for the particular RJ45/DB9 connectors used in this research, the colors of diagram three can be mated with the Signal labels from the first two diagrams (i.e. RTS = DB9 pin 7 = Blue).<br />
[[Image:DTE.png|thumb|900px|left|Port 1, DTE]]<br />
[[Image:DCE.png|thumb|900px|left|Port 2, DCE]]<br />
[[Image:BaytechWiring.png|thumb|500px|left|Wiring diagram for Baytech to Etherlite connection]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1902Serial adapter diagrams2007-07-12T19:44:38Z<p>Jpicotte: </p>
<hr />
<div>== Serial bay adapters ==<br />
Below are diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for port 1 (DTE). The second diagram is for the platform-dependent port 2 (DCE). The third diagram represents the connection between the between the Baytech serial-controlled power strip and the EtherLite terminal annex.<br />
[[Image:DTE.png|thumb|900px|left|Port 1, DTE]]<br />
[[Image:DCE.png|thumb|900px|left|Port 2, DCE]]<br />
[[Image:BaytechWiring.png|thumb|700px|left|Wiring diagram for Baytech to Etherlite connection]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=File:BaytechWiring.png&diff=1901File:BaytechWiring.png2007-07-12T19:43:50Z<p>Jpicotte: Wiring diagram for Baytech to EtherLite connection</p>
<hr />
<div>Wiring diagram for Baytech to EtherLite connection</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1900Serial adapter diagrams2007-07-12T19:19:24Z<p>Jpicotte: </p>
<hr />
<div>== Serial bay adapters ==<br />
Below are diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for port 1 (DTE). The second diagram is for the platform-dependent port 2 (DCE). The third diagram represents the connection between the between the Baytech serial-controlled power strip and the EtherLite terminal annex.<br />
[[Image:DTE.png|thumb|900px|left|Port 1, DTE]]<br />
[[Image:DCE.png|thumb|900px|left|Port 2, DCE]]<br />
[[Image:BaytechWiring.png|thumb|900px|left|Wiring diagram for Baytech to Etherlite connection]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Build_Backend_Pool&diff=1899Build Backend Pool2007-07-12T19:15:13Z<p>Jpicotte: /* Additional (Optional) hardware */</p>
<hr />
<div>== Summary ==<br />
<br />
This page details how to scale your laboratory environment up to a pool of backend target machines available for remote access.<br />
<br />
== The Big Picture ==<br />
[[Image:XINU-Lab-schematic.gif]]<br />
<br />
=== XINU Backends ===<br />
Backend targets upload a student's kernel over a private network on boot, and run the O/S directly. No simulations or emulation are involved; this is real hardware.<br />
<br />
MIPS targets: We use Linksys WRT54GL wireless routers (~$60) with [[HOWTO:Modify_the_Linksys_hardware|serial port modifications]] (~$10) running an embedded MIPS32 200MHz processor, 4 MB flash, 16 MB RAM, two UARTs, wired and wireless network interfaces.<br />
<br />
PowerPC targets: We use Apple G3 desktops (recycled) with 512 MB RAM, linear framebuffer, PCI bus, NIC, HD. Apple G4 MiniMac also supported.<br />
<br />
CISC targets: Classic XINU runs on Intel x86, Sun 3/Motorola 68K, Sparc, and VAX, among others.<br />
<br />
=== XINU Server ===<br />
A general purpose server with multiple network interfaces manages a private network for the XINU backends, using standard network protocols like DHCP and TFTP.<br />
<br />
Backend serial consoles can connect directly to server's serial ports, or, in larger installations, to a serial annex or concentrator that allows many more serial ports.<br />
<br />
A daemon running on the server allows users on frontend workstations to remotely access backend serial consoles, or upload fresh kernels. Optional rebooting hardware allows clients to remotely reset crashed backends.<br />
<br />
Our [[Console Tools]] are freely available for modern UNIX platforms, including Fedora Linux and Solaris.<br />
<br />
=== XINU Frontends ===<br />
General purpose computer laboratory workstations can compile the XINU kernel, using a standard GNU C compiler and UNIX toolchain. GCC crosscompilers are readily available when the frontend architecture does not match the backend architecture.<br />
<br />
Backend consoles can be connected directly to frontend serial ports, or frontends can communicate with the server daemon that manages collections of backend serial consoles.<br />
<br />
With fully remote console access, kernel upload and powercycling, any machine on the network is a potential frontend, and need not be physically near the XINU server and laboratory hardware. Students can work on their operating system projects from their dorm room computers.<br />
<br />
== Additional (Optional) hardware ==<br />
* Terminal Annex (EtherLite 32)<br />
* Serial-Controlled Power Strip (BayTech)<br />
* [[EtherLite terminal annex adapter diagrams]]<br />
<br />
== The Server ==<br />
<br />
Our XINU Server is a PowerPC G5 XServe running Fedora Core Linux. We use this configuration as a model for the information below, but other architecture / O/S combinations are known to work, and there's no reason this shouldn't work for virtually any machine with two network interfaces running a modern UNIX O/S.<br />
<br />
=== DHCP Daemon ===<br />
<br />
Many modern firmware implementations will allow a device to automatically acquire an IP address using the DHCP protocol even before the O/S kernel begins to boot. The [[CFE]] on our Linksys backends will attempt to configure its primary ethernet interface when issued the command,<br />
<br />
ifconfig -auto eth0<br />
<br />
over the serial console. See [[HOWTO:Run your own code]] for more details.<br />
<br />
In our configuration, the XINU Server runs a DHCP daemon that is configured to supply addresses to backends on the private network. We use the<br />
standard '''dchp''' server package that comes stock with our Linux distribution (dhcp-3.0.5-3.fc6, as of this writing). Here is a sample configuration<br />
file, [http://www.mscs.mu.edu/~brylow/xinu/Morbius-dhcpd.conf dhcpd.conf]. Our configuration supplies a fixed IP address for each backend, based upon MAC address. It is important to note that the "filename" field designates a unique boot image for each backend; this allows each backend to boot a distinct image, customized by the student currently connected to that backend's serial console.<br />
<br />
=== TFTP Daemon ===<br />
Many modern firmware implementations will allow a device to upload a boot image over a network device using the Trivial File Transfer Protocol (TFTP). We use the stock TFTP server available with our Linux distribution (tftp-server-0.42-3.1, at this writing,) configured to answer requests on the private network, and with the /tftpboot directory writable by the xinu-console daemon user ID. Most TFTP daemons use TCP wrapper to regulate access; see the<br />
notes on security below.<br />
<br />
=== XINU Console Daemon ===<br />
The XINU Console Daemon and various associated utilities provide network clients with connectivity to backend consoles that are really only connected directly to the console host.<br />
The xinu-console software package is now freely available for UNIX console hosts and front end clients.<br />
<br />
[http://www.mscs.mu.edu/~brylow/xinu/xinu-console-2.02.tar.gz (GZipped tarball xinu-console-2.02.tar.gz)]<br />
<br />
[http://www.mscs.mu.edu/~brylow/xinu/xinu-console-2.02-2.src.rpm (Fedora Core Source RPM xinu-console-2.02-2.src.rpm)]<br />
<br />
The XINU Console Daemon uses TCP wrappers to prevent unauthorized access; see the notes on security below.<br />
<br />
== The Client ==<br />
<br />
=== Console Access ===<br />
Source for xinu-console included in Console Tools tarball. Explain environment variables. Ssh tunneling? Mips-console wrapper script.<br />
<br />
== Security ==<br />
<br />
A word on security. Isolated private network. TCP Wrappers. Iptables packet filtering.</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Build_Backend_Pool&diff=1897Build Backend Pool2007-07-12T19:14:16Z<p>Jpicotte: /* Additional (Optional) hardware */</p>
<hr />
<div>== Summary ==<br />
<br />
This page details how to scale your laboratory environment up to a pool of backend target machines available for remote access.<br />
<br />
== The Big Picture ==<br />
[[Image:XINU-Lab-schematic.gif]]<br />
<br />
=== XINU Backends ===<br />
Backend targets upload a student's kernel over a private network on boot, and run the O/S directly. No simulations or emulation are involved; this is real hardware.<br />
<br />
MIPS targets: We use Linksys WRT54GL wireless routers (~$60) with [[HOWTO:Modify_the_Linksys_hardware|serial port modifications]] (~$10) running an embedded MIPS32 200MHz processor, 4 MB flash, 16 MB RAM, two UARTs, wired and wireless network interfaces.<br />
<br />
PowerPC targets: We use Apple G3 desktops (recycled) with 512 MB RAM, linear framebuffer, PCI bus, NIC, HD. Apple G4 MiniMac also supported.<br />
<br />
CISC targets: Classic XINU runs on Intel x86, Sun 3/Motorola 68K, Sparc, and VAX, among others.<br />
<br />
=== XINU Server ===<br />
A general purpose server with multiple network interfaces manages a private network for the XINU backends, using standard network protocols like DHCP and TFTP.<br />
<br />
Backend serial consoles can connect directly to server's serial ports, or, in larger installations, to a serial annex or concentrator that allows many more serial ports.<br />
<br />
A daemon running on the server allows users on frontend workstations to remotely access backend serial consoles, or upload fresh kernels. Optional rebooting hardware allows clients to remotely reset crashed backends.<br />
<br />
Our [[Console Tools]] are freely available for modern UNIX platforms, including Fedora Linux and Solaris.<br />
<br />
=== XINU Frontends ===<br />
General purpose computer laboratory workstations can compile the XINU kernel, using a standard GNU C compiler and UNIX toolchain. GCC crosscompilers are readily available when the frontend architecture does not match the backend architecture.<br />
<br />
Backend consoles can be connected directly to frontend serial ports, or frontends can communicate with the server daemon that manages collections of backend serial consoles.<br />
<br />
With fully remote console access, kernel upload and powercycling, any machine on the network is a potential frontend, and need not be physically near the XINU server and laboratory hardware. Students can work on their operating system projects from their dorm room computers.<br />
<br />
== Additional (Optional) hardware ==<br />
* Terminal Annex (EtherLite 32)<br />
* Serial-Controlled Power Strip (BayTech)<br />
** [[EtherLite terminal annex adapter diagrams]]<br />
<br />
== The Server ==<br />
<br />
Our XINU Server is a PowerPC G5 XServe running Fedora Core Linux. We use this configuration as a model for the information below, but other architecture / O/S combinations are known to work, and there's no reason this shouldn't work for virtually any machine with two network interfaces running a modern UNIX O/S.<br />
<br />
=== DHCP Daemon ===<br />
<br />
Many modern firmware implementations will allow a device to automatically acquire an IP address using the DHCP protocol even before the O/S kernel begins to boot. The [[CFE]] on our Linksys backends will attempt to configure its primary ethernet interface when issued the command,<br />
<br />
ifconfig -auto eth0<br />
<br />
over the serial console. See [[HOWTO:Run your own code]] for more details.<br />
<br />
In our configuration, the XINU Server runs a DHCP daemon that is configured to supply addresses to backends on the private network. We use the<br />
standard '''dchp''' server package that comes stock with our Linux distribution (dhcp-3.0.5-3.fc6, as of this writing). Here is a sample configuration<br />
file, [http://www.mscs.mu.edu/~brylow/xinu/Morbius-dhcpd.conf dhcpd.conf]. Our configuration supplies a fixed IP address for each backend, based upon MAC address. It is important to note that the "filename" field designates a unique boot image for each backend; this allows each backend to boot a distinct image, customized by the student currently connected to that backend's serial console.<br />
<br />
=== TFTP Daemon ===<br />
Many modern firmware implementations will allow a device to upload a boot image over a network device using the Trivial File Transfer Protocol (TFTP). We use the stock TFTP server available with our Linux distribution (tftp-server-0.42-3.1, at this writing,) configured to answer requests on the private network, and with the /tftpboot directory writable by the xinu-console daemon user ID. Most TFTP daemons use TCP wrapper to regulate access; see the<br />
notes on security below.<br />
<br />
=== XINU Console Daemon ===<br />
The XINU Console Daemon and various associated utilities provide network clients with connectivity to backend consoles that are really only connected directly to the console host.<br />
The xinu-console software package is now freely available for UNIX console hosts and front end clients.<br />
<br />
[http://www.mscs.mu.edu/~brylow/xinu/xinu-console-2.02.tar.gz (GZipped tarball xinu-console-2.02.tar.gz)]<br />
<br />
[http://www.mscs.mu.edu/~brylow/xinu/xinu-console-2.02-2.src.rpm (Fedora Core Source RPM xinu-console-2.02-2.src.rpm)]<br />
<br />
The XINU Console Daemon uses TCP wrappers to prevent unauthorized access; see the notes on security below.<br />
<br />
== The Client ==<br />
<br />
=== Console Access ===<br />
Source for xinu-console included in Console Tools tarball. Explain environment variables. Ssh tunneling? Mips-console wrapper script.<br />
<br />
== Security ==<br />
<br />
A word on security. Isolated private network. TCP Wrappers. Iptables packet filtering.</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Build_Backend_Pool&diff=1896Build Backend Pool2007-07-12T19:13:32Z<p>Jpicotte: /* Additional (Optional) hardware */</p>
<hr />
<div>== Summary ==<br />
<br />
This page details how to scale your laboratory environment up to a pool of backend target machines available for remote access.<br />
<br />
== The Big Picture ==<br />
[[Image:XINU-Lab-schematic.gif]]<br />
<br />
=== XINU Backends ===<br />
Backend targets upload a student's kernel over a private network on boot, and run the O/S directly. No simulations or emulation are involved; this is real hardware.<br />
<br />
MIPS targets: We use Linksys WRT54GL wireless routers (~$60) with [[HOWTO:Modify_the_Linksys_hardware|serial port modifications]] (~$10) running an embedded MIPS32 200MHz processor, 4 MB flash, 16 MB RAM, two UARTs, wired and wireless network interfaces.<br />
<br />
PowerPC targets: We use Apple G3 desktops (recycled) with 512 MB RAM, linear framebuffer, PCI bus, NIC, HD. Apple G4 MiniMac also supported.<br />
<br />
CISC targets: Classic XINU runs on Intel x86, Sun 3/Motorola 68K, Sparc, and VAX, among others.<br />
<br />
=== XINU Server ===<br />
A general purpose server with multiple network interfaces manages a private network for the XINU backends, using standard network protocols like DHCP and TFTP.<br />
<br />
Backend serial consoles can connect directly to server's serial ports, or, in larger installations, to a serial annex or concentrator that allows many more serial ports.<br />
<br />
A daemon running on the server allows users on frontend workstations to remotely access backend serial consoles, or upload fresh kernels. Optional rebooting hardware allows clients to remotely reset crashed backends.<br />
<br />
Our [[Console Tools]] are freely available for modern UNIX platforms, including Fedora Linux and Solaris.<br />
<br />
=== XINU Frontends ===<br />
General purpose computer laboratory workstations can compile the XINU kernel, using a standard GNU C compiler and UNIX toolchain. GCC crosscompilers are readily available when the frontend architecture does not match the backend architecture.<br />
<br />
Backend consoles can be connected directly to frontend serial ports, or frontends can communicate with the server daemon that manages collections of backend serial consoles.<br />
<br />
With fully remote console access, kernel upload and powercycling, any machine on the network is a potential frontend, and need not be physically near the XINU server and laboratory hardware. Students can work on their operating system projects from their dorm room computers.<br />
<br />
== Additional (Optional) hardware ==<br />
* Terminal Annex (EtherLite 32)<br />
* Serial-Controlled Power Strip (BayTech)<br />
** [[Etherlite terminal annex adapter diagrams]]<br />
<br />
== The Server ==<br />
<br />
Our XINU Server is a PowerPC G5 XServe running Fedora Core Linux. We use this configuration as a model for the information below, but other architecture / O/S combinations are known to work, and there's no reason this shouldn't work for virtually any machine with two network interfaces running a modern UNIX O/S.<br />
<br />
=== DHCP Daemon ===<br />
<br />
Many modern firmware implementations will allow a device to automatically acquire an IP address using the DHCP protocol even before the O/S kernel begins to boot. The [[CFE]] on our Linksys backends will attempt to configure its primary ethernet interface when issued the command,<br />
<br />
ifconfig -auto eth0<br />
<br />
over the serial console. See [[HOWTO:Run your own code]] for more details.<br />
<br />
In our configuration, the XINU Server runs a DHCP daemon that is configured to supply addresses to backends on the private network. We use the<br />
standard '''dchp''' server package that comes stock with our Linux distribution (dhcp-3.0.5-3.fc6, as of this writing). Here is a sample configuration<br />
file, [http://www.mscs.mu.edu/~brylow/xinu/Morbius-dhcpd.conf dhcpd.conf]. Our configuration supplies a fixed IP address for each backend, based upon MAC address. It is important to note that the "filename" field designates a unique boot image for each backend; this allows each backend to boot a distinct image, customized by the student currently connected to that backend's serial console.<br />
<br />
=== TFTP Daemon ===<br />
Many modern firmware implementations will allow a device to upload a boot image over a network device using the Trivial File Transfer Protocol (TFTP). We use the stock TFTP server available with our Linux distribution (tftp-server-0.42-3.1, at this writing,) configured to answer requests on the private network, and with the /tftpboot directory writable by the xinu-console daemon user ID. Most TFTP daemons use TCP wrapper to regulate access; see the<br />
notes on security below.<br />
<br />
=== XINU Console Daemon ===<br />
The XINU Console Daemon and various associated utilities provide network clients with connectivity to backend consoles that are really only connected directly to the console host.<br />
The xinu-console software package is now freely available for UNIX console hosts and front end clients.<br />
<br />
[http://www.mscs.mu.edu/~brylow/xinu/xinu-console-2.02.tar.gz (GZipped tarball xinu-console-2.02.tar.gz)]<br />
<br />
[http://www.mscs.mu.edu/~brylow/xinu/xinu-console-2.02-2.src.rpm (Fedora Core Source RPM xinu-console-2.02-2.src.rpm)]<br />
<br />
The XINU Console Daemon uses TCP wrappers to prevent unauthorized access; see the notes on security below.<br />
<br />
== The Client ==<br />
<br />
=== Console Access ===<br />
Source for xinu-console included in Console Tools tarball. Explain environment variables. Ssh tunneling? Mips-console wrapper script.<br />
<br />
== Security ==<br />
<br />
A word on security. Isolated private network. TCP Wrappers. Iptables packet filtering.</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1894Serial adapter diagrams2007-07-12T19:12:55Z<p>Jpicotte: Etherlite serial bay adapter diagrams moved to EtherLite terminal annex adapter diagrams</p>
<hr />
<div>== Serial bay adapters ==<br />
Below are the diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for port 1 (DTE) and the second diagram is for the platform-dependent port 2 (DCE).<br />
[[Image:DTE.png|thumb|900px|left|Port 1, DTE]]<br />
[[Image:DCE.png|thumb|900px|left|Port 2, DCE]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Etherlite_serial_bay_adapter_diagrams&diff=1895Etherlite serial bay adapter diagrams2007-07-12T19:12:55Z<p>Jpicotte: Etherlite serial bay adapter diagrams moved to EtherLite terminal annex adapter diagrams</p>
<hr />
<div>#REDIRECT [[EtherLite terminal annex adapter diagrams]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Build_Backend_Pool&diff=1893Build Backend Pool2007-07-12T19:06:20Z<p>Jpicotte: /* Additional (Optional) hardware */</p>
<hr />
<div>== Summary ==<br />
<br />
This page details how to scale your laboratory environment up to a pool of backend target machines available for remote access.<br />
<br />
== The Big Picture ==<br />
[[Image:XINU-Lab-schematic.gif]]<br />
<br />
=== XINU Backends ===<br />
Backend targets upload a student's kernel over a private network on boot, and run the O/S directly. No simulations or emulation are involved; this is real hardware.<br />
<br />
MIPS targets: We use Linksys WRT54GL wireless routers (~$60) with [[HOWTO:Modify_the_Linksys_hardware|serial port modifications]] (~$10) running an embedded MIPS32 200MHz processor, 4 MB flash, 16 MB RAM, two UARTs, wired and wireless network interfaces.<br />
<br />
PowerPC targets: We use Apple G3 desktops (recycled) with 512 MB RAM, linear framebuffer, PCI bus, NIC, HD. Apple G4 MiniMac also supported.<br />
<br />
CISC targets: Classic XINU runs on Intel x86, Sun 3/Motorola 68K, Sparc, and VAX, among others.<br />
<br />
=== XINU Server ===<br />
A general purpose server with multiple network interfaces manages a private network for the XINU backends, using standard network protocols like DHCP and TFTP.<br />
<br />
Backend serial consoles can connect directly to server's serial ports, or, in larger installations, to a serial annex or concentrator that allows many more serial ports.<br />
<br />
A daemon running on the server allows users on frontend workstations to remotely access backend serial consoles, or upload fresh kernels. Optional rebooting hardware allows clients to remotely reset crashed backends.<br />
<br />
Our [[Console Tools]] are freely available for modern UNIX platforms, including Fedora Linux and Solaris.<br />
<br />
=== XINU Frontends ===<br />
General purpose computer laboratory workstations can compile the XINU kernel, using a standard GNU C compiler and UNIX toolchain. GCC crosscompilers are readily available when the frontend architecture does not match the backend architecture.<br />
<br />
Backend consoles can be connected directly to frontend serial ports, or frontends can communicate with the server daemon that manages collections of backend serial consoles.<br />
<br />
With fully remote console access, kernel upload and powercycling, any machine on the network is a potential frontend, and need not be physically near the XINU server and laboratory hardware. Students can work on their operating system projects from their dorm room computers.<br />
<br />
== Additional (Optional) hardware ==<br />
* Terminal Annex (EtherLite 32)<br />
* Serial-Controlled Power Strip (BayTech)<br />
** [[Etherlite serial bay adapter diagrams]]<br />
<br />
== The Server ==<br />
<br />
Our XINU Server is a PowerPC G5 XServe running Fedora Core Linux. We use this configuration as a model for the information below, but other architecture / O/S combinations are known to work, and there's no reason this shouldn't work for virtually any machine with two network interfaces running a modern UNIX O/S.<br />
<br />
=== DHCP Daemon ===<br />
<br />
Many modern firmware implementations will allow a device to automatically acquire an IP address using the DHCP protocol even before the O/S kernel begins to boot. The [[CFE]] on our Linksys backends will attempt to configure its primary ethernet interface when issued the command,<br />
<br />
ifconfig -auto eth0<br />
<br />
over the serial console. See [[HOWTO:Run your own code]] for more details.<br />
<br />
In our configuration, the XINU Server runs a DHCP daemon that is configured to supply addresses to backends on the private network. We use the<br />
standard '''dchp''' server package that comes stock with our Linux distribution (dhcp-3.0.5-3.fc6, as of this writing). Here is a sample configuration<br />
file, [http://www.mscs.mu.edu/~brylow/xinu/Morbius-dhcpd.conf dhcpd.conf]. Our configuration supplies a fixed IP address for each backend, based upon MAC address. It is important to note that the "filename" field designates a unique boot image for each backend; this allows each backend to boot a distinct image, customized by the student currently connected to that backend's serial console.<br />
<br />
=== TFTP Daemon ===<br />
Many modern firmware implementations will allow a device to upload a boot image over a network device using the Trivial File Transfer Protocol (TFTP). We use the stock TFTP server available with our Linux distribution (tftp-server-0.42-3.1, at this writing,) configured to answer requests on the private network, and with the /tftpboot directory writable by the xinu-console daemon user ID. Most TFTP daemons use TCP wrapper to regulate access; see the<br />
notes on security below.<br />
<br />
=== XINU Console Daemon ===<br />
The XINU Console Daemon and various associated utilities provide network clients with connectivity to backend consoles that are really only connected directly to the console host.<br />
The xinu-console software package is now freely available for UNIX console hosts and front end clients.<br />
<br />
[http://www.mscs.mu.edu/~brylow/xinu/xinu-console-2.02.tar.gz (GZipped tarball xinu-console-2.02.tar.gz)]<br />
<br />
[http://www.mscs.mu.edu/~brylow/xinu/xinu-console-2.02-2.src.rpm (Fedora Core Source RPM xinu-console-2.02-2.src.rpm)]<br />
<br />
The XINU Console Daemon uses TCP wrappers to prevent unauthorized access; see the notes on security below.<br />
<br />
== The Client ==<br />
<br />
=== Console Access ===<br />
Source for xinu-console included in Console Tools tarball. Explain environment variables. Ssh tunneling? Mips-console wrapper script.<br />
<br />
== Security ==<br />
<br />
A word on security. Isolated private network. TCP Wrappers. Iptables packet filtering.</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=File:DCE.png&diff=1892File:DCE.png2007-07-12T19:04:06Z<p>Jpicotte: RJ45/DB9 serial adapter</p>
<hr />
<div>RJ45/DB9 serial adapter</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=File:DTE.png&diff=1891File:DTE.png2007-07-12T18:59:19Z<p>Jpicotte: RJ45/DB9 adapter diagram</p>
<hr />
<div>RJ45/DB9 adapter diagram</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1890Serial adapter diagrams2007-07-12T18:58:34Z<p>Jpicotte: </p>
<hr />
<div>== Serial bay adapters ==<br />
Below are the diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for port 1 (DTE) and the second diagram is for the platform-dependent port 2 (DCE).<br />
[[Image:DTE.png|thumb|900px|left|Port 1, DTE]]<br />
[[Image:DCE.png|thumb|900px|left|Port 2, DCE]]</div>Jpicottehttps://xinu.cs.mu.edu/index.php?title=Serial_adapter_diagrams&diff=1889Serial adapter diagrams2007-07-12T18:56:56Z<p>Jpicotte: New page: == Serial bay adapters == Below are the diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for port 1...</p>
<hr />
<div><br />
== Serial bay adapters ==<br />
Below are the diagrams for RJ45 to DB9 adapters allowing connection between an Etherlite serial bay and XINU backends in a pool. The first diagram is for port 1 (DTE) and the second diagram is for the platform-dependent port 2 (DCE).</div>Jpicotte