Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
soc:alanshieh [2006/06/14 22:31]
ashieh
soc:alanshieh [2006/08/11 13:31] (current)
ashieh
Line 1: Line 1:
 ====== Alan Shieh, Linux UNDI Driver ====== ====== Alan Shieh, Linux UNDI Driver ======
 +===== Comparing a UNDI driver to server-side initrd selection =====
  
 +It is possible to achieve the same effect as an UNDI driver with other approaches, such as loading all possible drivers into an initrd, or selecting an initrd based on MAC address, thus allowing Linux to load the right module. Such a design of this is much more conservative,​ as it relies on driver code that has been used by a larger population
  
 +There are some disadvantages with each approach. Having a larger initrd may increase the booting time or RAM requirements. Selecting initrd based on MACs requires a MAC=>NIC database. This may need to be collected manually, or make assumptions based on MAC=>​Manufacturer mappings. For instance, one could provide all Intel drivers for all NICs with a MAC that is assigned to Intel.
 +
 +UNDI has its advantages and disadvantages. New deployments that install Etherboot stacks on supported NICs will automatically support the UNDI driver, without configuring any other software. A boot process that uses the UNDI driver can use arbitrary userspace / kernel code to talk to network and figure out how to load the right drivers for a particular machine.
 +
 +Though the UNDI driver is about an order of magnitude slower than the Linux driver, it can still download most modules in <1s on an emulated NE2K-PCI.
 +
 +===== Deliverables and Timeline =====
 +
 +Note: Since I am working with Etherboot 5.4.x, I am going directly for 16:32 UNDI stack support. As of 7/30, the UNDI driver works with the NE2K-PCI, which uses PIO to send data to/from the card. 
 +
 +Here are the remaining deliverables:​
 +
 +  * Implement support for memory mapped registers
 +  * Test on alternate Etherboot hardware, including real hardware
 +  ** Test card that uses PIO to set up DMA
 +  ** Test card that uses memory mapped registers to set up DMA
 +  * Test with full network boot (LTSP, NFS root)
 +
 +  * Experiment with getting other other PXE stacks -- inference of segment lengths via E820 holes.
 +
 +These steps are done
 +
 +  * Implement memory map functionality for Linux
 +  * Set up UNDI Probe memory map
 +  * Find UNDI ROM
 +  * Make sure E820 Map is sane [[E820IRC:​IRC Logs for E820 issue]]. I am Here (6/​15/​2006). Estimated completion time 6/20/2006
 +  * Hard code segment descriptor & location. 16:32 downcall (est 6/27/2006)
 +  * Test UNDI calls, see proposal for details (est 7/4/2006)
 +  * Integration with TUN/TAP device; transmit data with Linux (est 7/11/2006)
 +  * PXE Extensions for segment descriptor & location
 +  * Interrupt processing cleanup (est 7/18/2006)
 +
 +
 +===== Resources =====
 +[[Alan'​s test / development infrastructure]]
 ===== UNDI proposal ===== ===== UNDI proposal =====
  
 [[OldUNDIProposal]] [[OldUNDIProposal]]
  
 +<​file>​
 = Goals = = Goals =
 * Support both 16:16 and 16:32 protected mode UNDI stacks * Support both 16:16 and 16:32 protected mode UNDI stacks
Line 212: Line 250:
     (paging, IOMMU, Linux kernel layout modifications)     (paging, IOMMU, Linux kernel layout modifications)
 *** Attempt to support unmodified PXE stacks *** Attempt to support unmodified PXE stacks
 +</​file>​

QR Code
QR Code soc:alanshieh (generated for current page)