Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:alanshieh [2006/06/14 22:45] 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 ===== | ===== Deliverables and Timeline ===== | ||
| - | Note: Since I am working with Etherboot 5.4.x, I am going directly for 16:32 UNDI stack support. | + | 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 | * Implement memory map functionality for Linux | ||
| Line 14: | Line 35: | ||
| * PXE Extensions for segment descriptor & location | * PXE Extensions for segment descriptor & location | ||
| * Interrupt processing cleanup (est 7/18/2006) | * Interrupt processing cleanup (est 7/18/2006) | ||
| - | * Test on alternate Etherboot hardware, including real hardware | ||
| - | * Test with full network boot (LTSP, NFS root) | ||
| - | * Experiment with getting other other PXE stacks -- inference of segment lengths via E820 holes. | ||
