Intel-82541ER Project

From Deos
Jump to navigationJump to search


Provide network device drivers to support the AGM2_Program.

Description

Develop a DO-178B level A process-based driver, and a DO-178B level E library-based driver for the Intel 82541ER Ethernet controller. Note that the GCC/X86/PE startup library will also have to be certified to support this project, although this effort has not been accounted for in the estimates given below. The NGFMS project also needs the GCC/X86/PE startup library to be certified, so there is an opportunity for cost-sharing between these two projects.

News

  • 2007-10-17: Version 1.0.0 of the Cardon-compatible, library-based Pro1000 driver has been released. The distribution is available here: ftp://deos.ddci.com/.SHARP/middleware/pro1000-library-cardon-compatible/1.0.0/
  • 2007-10-02: Larry Miller reports their group is expected to begin using the Cardon-compatible, library-based Pro1000 driver in January 2008 (possibly sooner). He also reports they expect to use the Process-based Pro1000 driver on a Cardon-based system (CDS on DU3 hardware) with a certification date in the March 2009 time frame. I informed Larry that this will require an update to the EPIC network process because it does not currently support the process-based driver interface. The Cardon-compatibility requirement will add about a month to the time required to develop the process-based Pro1000 driver.
  • 2007-10-02: The code bases for the library-based Intel 82546EB and 82541ER drivers have been merged into a single code base that supports multiple Pro1000 controllers via configuration file.
  • 2007-07-20: The auto-negotiation speed and controller type can now be specified in net.config for the library-based driver.
  • 2007-06-20: A PE-formatted, Cardon-compatible version of the level E library-based driver is operational.
  • 2007-06-18: Added the tracking table for the Cardon-compatible, library-based driver.
  • 2007-03-13: While funded, the scheduled need by dates have yet to be worked out with the customer.
  • 2006-11-29: Success! The library-style gigabit Ethernet driver has been transformed into a partitioned driver, and it's running on the development PC (a Pentium 200). As a rough performance benchmark, a "put" operation of a 1MB file resulted in a transfer rate of 720KB/s, and a "get" of the same file resulted in a transfer rate of 490KB/s, as reported by the FTP client. No attempts have yet been made to optimize the driver for speed, so higher performance may be possible.
  • 2006-10-18: Success! The level E library-style gigabit Ethernet driver is running on the AGM2 hardware. The software environment included the following: kernel 7.1.0; latest RTIP network stack(custom build for debugging); FTP server 7.0.3 (not the EPIC FTP server). As a rough performance benchmark, a "put" operation of a 1MB file resulted in a transfer rate of 3600KB/s, as reported by the FTP client. No attempts have yet been made to optimize the driver for speed, so higher performance may be possible.
  • 2006-07-10: John had a meeting today with Larry Miller and Steve Pearce. We discussed the recent ERB decision that the AGM2 will not be upgraded to the Agave Deos kernel when it is rolled into production this year. However, there are a number of display units under development that will need the 82541ER driver. So the plan for now is for John to continue his efforts to integrate the library form of the driver on the AGM2 hardware under Agave. This will reduce technical risk, and provide an opportunity to benchmark network throughput on the AGM2 hardware. Following that integration effort, it is expected that work will begin on the level A, partitioned form of the driver.
  • 2006-06-30: Success! The gigabit Ethernet driver is auto-negotiating at 100Mbps on the development PC, as needed for the AGM2 hardware. Because of the AGM2 external wiring limitations, it is necessary to disable the 1000Mbps auto-negotiation capability, although we'll want to make this configurable for other platforms that can handle 1000Mbps.
  • 2006-06-23: Here's a rough benchmark for the level E library-style gigabit Ethernet driver running on the Pentium-200 development PC with the WinSystems Ethernet board, as reported by the FTP server while putting and getting a 2MB file: 970KB/s (put) and 55KB/s (get). This looks promising for meeting our target of a 5MB/s loading speed on the much faster AGM2 hardware. I'm not sure why the transmit speed is so much lower - maybe that's normal. Also, no attempt has yet been made to optimize the driver for speed.
  • 2006-06-19: It's alive! The gigabit ethernet driver (level E library version) is running on the development PC and successfully communicating with the controller on the WinSystems board. A quick test of an ftp get and put indicate the driver is functioning well.
  • 2006-05-03: The WinSystems gigabit ethernet board has been installed in a PC and appears to be accessible on the PCI bus. The intelpc PAL has been modified on my workstation to support the 82541ER controller. The library-style driver that Ryan developed for the 82546EB (same family of controllers) is being used as the baseline for the 82541ER. The differences between controllers is being investigated, and the driver code is being updated accordingly. JBR

Tasks

This information is intended to facilitate the technical work to be done. It is NOT for the purpose of estimating effort. That has already been done and is reflected in the estimate spreadsheet (see Project Management below).

Requirements Development

  • [DEOSDMA] in the references is an unpublished document that lives in the kernel DDD area. Its name is dma-effects.htm.
  • [SAS] and [SCID] in the references need document numbers.
  • Verify the definitions. Some of them are controller-specific.
  • Update requirements related to mac address processing: pro1000_open_40
  • Verify NI_PRO1000_XMIT_60.
  • Verify the size of PIN_PRO1000ENET_30. Can the size be reduced as it was for the Pro100?
  • Verify the issue described in 5.2, DMA Restart Considerations, is legitimate for the Pro1000.
  • Timing analyses in section 5.3 are based on 100Mbps. Could scale up to 1000, but that seems rather meaningless because actual throughput will be much lower.
  • We may need to add some information regarding the auto-negotiation speed (see Code Development below). If added, this will probably be architecture (not requirements).

Code Development:

  • Update to the latest NetBSD baseline (our baseline is over a year old).
  • Add implementation code to rpc_get_mac_addr() (in pro1000.cpp).
  • Add logic to limit the auto-negotiation speed to 100Mbps or slower (this has already been implemented in the library-based driver).
  • Add new mac address logic (see Mac Address Logic below).
  • Add trace tags.
  • Remove support for Ethernet controllers other than the 82541ER if such support causes structural coverage problems.
  • Examine the code for its ability to be tested and correct as needed.
  • Examine the code for general structural coverage issues and correct as needed.

Mac Address Logic

The Displays hardware is not expected to have EEPROMs for configuring the Ethernet controllers. Therefore the mac address will have to be determined by calling back to the network process via ethernetAddressPointerForInterface(). However, it's convenient to be able to use off-the-shelf network cards for development and testing, and those cards DO have EEPROMs. Therefore I propose the following scheme:

  • The Pro1000 driver calls ethernetAddressPointerForInterface() to get a mac address from the network process.
  • The resulting mac address is used if it's non-zero.
  • If the resulting mac address is zero, the Pro1000 driver retrieves the mac address from the EEPROM (it does not check to ensure the prom exists or is valid because this will not be testable on a COTS board).
  • The ethernetAddressPointerForInterface() function retrieves the mac address from inetaddr.dll if it was successfully loaded and if it contains a function named ethernetAddressPointer().
  • The ethernetAddressPointerForInterface() function retrieves the mac address from net.config if it is unable to get it from inetaddr.dll.
  • The ethernetAddressPointerForInterface() function returns a mac address of zero if it's unable to get a valid mac address from either inetaddr.dll or net.config.
  • Note: This scheme will result in the use of a fabricated mac address during some test scenarios. This mac address will have to work in a real network environment, without disrupting any other hosts on the network.
  • Note: Pro1000 testing will only need to cover the scenarios of ethernetAddressPointerForInterface() returning both valid and invalid mac addresses. The distinction of the mac address coming from inetaddr.dll or net.config is not important for Pro1000 testing. Supporting the mac address definition in net.config simply provides an easier way to define a mac address for development and testing.

Test Development

  • Port the test cases and procedures from Pro100.
  • Update the test cases and procedures for Pro1000 as needed.
  • Port the test infrastructure support from Pro100.
  • Update the test infrastructure support as needed for compatibility with the latest common test system.
  • Update the Pro1000-specific test infrastructure support (run-tests.sh) to take advantage of the latest best practices in this area. Use kernel testing as a reference for this purpose.

Requirements Coverage Analysis

  • Port the scripts in /docs from Pro100.
  • Update the scripts in /docs as needed for Pro1000.

Build Environment

  • Update to support building for both PE and ELF formats (currently builds ELF).
  • Note that the build environment has already been updated to use the common build system.

Compatibility

  • To work with the Cardon series Deos kernel, the Pro1000 driver needs to be built in PE format (this is covered under Build Environment above).
  • To work with the Deos ANSI library, the PE-formatted Pro1000 driver will need to link against the older ansi.dll (not the newer libansi.so).

Network Process: The Primus EPIC network process is based on the Cardon-era Deos network process, and does not support the partitioned driver interface. Therefore we can either work with the EPIC core team to help them upgrade the EPIC network process, or we can back-port the Deos network process to Cardon. I suggest back-porting the Deos network process because that will be a smaller effort, and will provide more capability. Here are the required tasks:

  • Build in PE format
  • Use the Image library instead of the corresponding kernel services (because they don't exist in the Cardon kernel)
  • Optional: Add support for multiple interfaces to the inetaddr API. This has already been implemented for LWIP. This is optional because Displays will only be using a single interface.
  • Note: Steve Pearce tried running the Deos network process on some display hardware with the TG595 driver and found that it would not survive a warm start. Apparently some change was made to the EPIC network stack for this purpose, but it is also known to sometimes have problems with warm starts.

Project Management

Estimates and time tracking for this project are being maintained in the following spreadsheets:

Estimates:

https://deos.ddci.com/scm/Deos/products/network/network-drivers/pro1000-partitioned/branches/mainline/project-management/pro1000-estimation-and-reuse-plan.xls

Time tracking:

https://deos.ddci.com/scm/Deos/products/network/network-drivers/pro1000-partitioned/branches/mainline/project-management/HourTracking.xls

Timesite Administrivia

See Timesite_Codes

Retrieved from "https://ddci.zapto.org/Wiki/index.php?title=Intel-82541ER_Project&oldid=12107"