1 | %% This LaTeX-file was created by <raguet> Wed Apr 7 17:10:33 1999
|
---|
2 | %% LyX 1.0 (C) 1995-1999 by Matthias Ettrich and the LyX Team
|
---|
3 |
|
---|
4 | %% Do not edit this file unless you know what you are doing.
|
---|
5 | \documentclass[10pt,american]{article}
|
---|
6 | \usepackage[T1]{fontenc}
|
---|
7 | \usepackage{a4wide}
|
---|
8 | \pagestyle{plain}
|
---|
9 | \usepackage{babel}
|
---|
10 | \usepackage[dvips]{graphics}
|
---|
11 |
|
---|
12 | \makeatletter
|
---|
13 |
|
---|
14 |
|
---|
15 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
|
---|
16 | \providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
|
---|
17 |
|
---|
18 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
|
---|
19 | \usepackage[dvips]{epsfig}
|
---|
20 |
|
---|
21 | \makeatother
|
---|
22 |
|
---|
23 | \begin{document}
|
---|
24 |
|
---|
25 | \resizebox*{1\textwidth}{!}{\includegraphics{garde.eps}}
|
---|
26 |
|
---|
27 | {\par\centering \newpage\par}
|
---|
28 | \vspace{0.3cm}
|
---|
29 |
|
---|
30 | \bigskip{}
|
---|
31 | {\par\centering \textbf{\Huge Ethernet Driver for PCI DEC board}\Huge \par}
|
---|
32 | \bigskip{}
|
---|
33 |
|
---|
34 | \tableofcontents{}
|
---|
35 |
|
---|
36 | \listoffigures{}
|
---|
37 |
|
---|
38 | \newpage
|
---|
39 |
|
---|
40 |
|
---|
41 | \section{\noindent Introduction}
|
---|
42 |
|
---|
43 | One aim of our project is to port RTEMS on a standard PowerPC platform. To achieve
|
---|
44 | it, we have chosen a Motorola MCP750 board. This board includes an Ethernet
|
---|
45 | controller based on a DEC21140 chip. Because RTEMS has a TCP/IP stack, we will
|
---|
46 | have to develop the DEC21140 related ethernet driver for the PowerPC port of
|
---|
47 | RTEMS. As this controller is able to support 100Mbps network and as there is
|
---|
48 | a lot of PCI card using this DEC chip (cf \ref{List}), we have decided to first
|
---|
49 | implement this driver on an Intel PC386 target to provide a solution for using
|
---|
50 | RTEMS on PC with the 100Mbps network and then to port this code on PowerPC in
|
---|
51 | a second phase.\\
|
---|
52 |
|
---|
53 |
|
---|
54 | \noindent The aim of this document is to give some PCI board generalities and
|
---|
55 | to explain the software architecture of the RTEMS driver. Finally, we will see
|
---|
56 | what will be done for ChorusOs and Netboot environment .
|
---|
57 |
|
---|
58 |
|
---|
59 | \section{Document Revision History}
|
---|
60 |
|
---|
61 | \underbar{Current release} :
|
---|
62 |
|
---|
63 | \begin{itemize}
|
---|
64 | \item \noindent Current applicable release is 1.0.
|
---|
65 | \end{itemize}
|
---|
66 | \noindent \underbar{Existing releases} :
|
---|
67 |
|
---|
68 | \begin{itemize}
|
---|
69 | \item \noindent 1.0 : Released the 10/02/98. First version of this document.
|
---|
70 | \item 0.1 : First draft of this document
|
---|
71 | \end{itemize}
|
---|
72 | \noindent \underbar{Planned releases} :
|
---|
73 |
|
---|
74 | \begin{itemize}
|
---|
75 | \item \noindent None planned today.
|
---|
76 | \end{itemize}
|
---|
77 |
|
---|
78 | \section{DEC21140 PCI Board Generalities}
|
---|
79 |
|
---|
80 | This chapter describes rapidely the PCI interface of this Ethernet controller.
|
---|
81 | The board we have chosen for our PC386 implementation is a D-Link DFE-500TX.
|
---|
82 | This is a dual-speed 10/100Mbps Ethernet PCI adapter with a DEC21140AF chip.
|
---|
83 | Like other PCI devices, this board has a PCI device's header containing some
|
---|
84 | required configuration registers, as shown in figure \ref{PCI reg}. By reading
|
---|
85 | or writing these registers, a driver can obtain information about the type of
|
---|
86 | the board, the interrupt it uses, the mapping of the chip specific registers,~...
|
---|
87 | \\
|
---|
88 |
|
---|
89 |
|
---|
90 | \noindent On Intel target, the chip specific registers can be accessed via 2
|
---|
91 | methods : I/O port access or PCI address mapped access. We have chosen to implement
|
---|
92 | the PCI address access to obtain compatible source code to the port the driver
|
---|
93 | on a PowerPC target.\\
|
---|
94 |
|
---|
95 |
|
---|
96 | \begin{figure}
|
---|
97 | {\par\centering \includegraphics{PCI_reg.eps} \par}
|
---|
98 |
|
---|
99 |
|
---|
100 | \caption{\label{PCI reg}PCI device's configuration header space format}
|
---|
101 | \end{figure}
|
---|
102 | On RTEMS, a PCI API exists. We have used it to configure the board. After initializing
|
---|
103 | this PCI module via the \textbf{\textit{pcib\_init()}} function, we try to detect
|
---|
104 | the DEC21140 based ethernet board. This board is characterized by its Vendor
|
---|
105 | ID (0x1011) and its Device ID (0x0009). We give these arguments to the \textbf{\textit{pcib\_find\_by\_deviceid}}
|
---|
106 | function which returns , if the device is present, a pointer to the configuration
|
---|
107 | header space (cf fig \ref{PCI reg}). Once this operation performed, the driver
|
---|
108 | is able to extract the information it needs to configure the board internal
|
---|
109 | registers, like the interrupt line, the base address,... The board internal
|
---|
110 | registers will not be detailled here. You can find them in \cite{1}.\newpage
|
---|
111 |
|
---|
112 |
|
---|
113 | \section{\noindent RTEMS Driver Software Architecture}
|
---|
114 |
|
---|
115 | In this chapter will see the initialization phase, how the controller uses the
|
---|
116 | host memory and the 2 threads launched at the initialization time.
|
---|
117 |
|
---|
118 |
|
---|
119 | \subsection{Initialization phase}
|
---|
120 |
|
---|
121 | The DEC21140 Ethernet driver keeps the same software architecture than the other
|
---|
122 | RTEMS ethernet drivers. The only API the programmer can use is the \textbf{\textit{``rtems\_dec21140\_driver\_attach}}\\
|
---|
123 | \textbf{\textit{(struct rtems\_bsdnet\_ifconfig {*}config)''}} function which
|
---|
124 | detects the board and initializes the associated data structure (with registers
|
---|
125 | base address, entry points to low-level initialization function,...), if the
|
---|
126 | board is found.
|
---|
127 |
|
---|
128 | \noindent Once the attach function executed, the driver initializes the DEC
|
---|
129 | chip. Then the driver connects an interrupt handler to the interrupt line driven
|
---|
130 | by the Ethernet controller (the only interrupt which will be treated is the
|
---|
131 | receive interrupt) and launches 2 threads : a receiver thread and a transmitter
|
---|
132 | thread. Then the driver waits for incoming frame to give to the protocol stack
|
---|
133 | or outcoming frame to send on the physical link.
|
---|
134 |
|
---|
135 |
|
---|
136 | \subsection{Memory Buffer}
|
---|
137 |
|
---|
138 | This DEC chip uses the host memory to store the incoming Ethernet frames and
|
---|
139 | the descriptor of these frames. We have chosen to use 7 receive buffers and
|
---|
140 | 1 transmit buffer to optimize memory allocation due to cache and paging problem
|
---|
141 | that will be explained in paragraph \ref{Problem}).\\
|
---|
142 |
|
---|
143 |
|
---|
144 | \noindent To reference these buffers to the DEC chip we use a buffer descriptors
|
---|
145 | ring. The descriptor structure is defined in figure \ref{bdescr}. Each descriptor
|
---|
146 | can reference one or two memory buffers. We choose to use only one buffer of
|
---|
147 | 1520 bytes per descriptor.\\
|
---|
148 |
|
---|
149 |
|
---|
150 | \noindent The difference between a receive and a transmit buffer descriptor
|
---|
151 | is located in the status and control bits fields. We do not give details here,
|
---|
152 | please refer to \cite{1}.
|
---|
153 |
|
---|
154 | \begin{figure}
|
---|
155 | {\par\centering \includegraphics{recv_bd.eps} \par}
|
---|
156 |
|
---|
157 |
|
---|
158 | \caption{\label{bdescr}Buffer Descriptor}
|
---|
159 | \end{figure}
|
---|
160 |
|
---|
161 |
|
---|
162 |
|
---|
163 | \subsection{Receiver Thread}
|
---|
164 |
|
---|
165 | This thread is event driven. Each time a DEC PCI board interrupt occurs, the
|
---|
166 | handler checks if this is a receive interrupt and send an event ``reception''
|
---|
167 | to the receiver thread which looks into the entire buffer descriptors ring the
|
---|
168 | ones that contain a valid incoming frame (bit OWN=0 means descriptor belongs
|
---|
169 | to host processor). Each valid incoming ethernet frame is sent to the protocol
|
---|
170 | stack and the buffer descriptor is given back to the DEC board (the host processor
|
---|
171 | reset bit OWN, which means descriptor belongs to 21140).
|
---|
172 |
|
---|
173 |
|
---|
174 | \subsection{Transmitter Thread}
|
---|
175 |
|
---|
176 | This thread is also event driven. Each time an Ethernet frame is put in the
|
---|
177 | transmit queue, an event is sent to the transmit thread, which empty the queue
|
---|
178 | by sending each outcoming frame. Because we use only one transmit buffer, we
|
---|
179 | are sure that the frame is well-sent before sending the next.
|
---|
180 |
|
---|
181 |
|
---|
182 | \section{\label{Problem}Encountered Problems}
|
---|
183 |
|
---|
184 | On Intel PC386 target, we were faced with a problem of memory cache management.
|
---|
185 | Because the DEC chip uses the host memory to store the incoming frame and because
|
---|
186 | the DEC21140 configuration registers are mapped into the PCI address space,
|
---|
187 | we must ensure that the data read (or written) by the host processor are the
|
---|
188 | ones written (or read) by the DEC21140 device in the host memory and not old
|
---|
189 | data stored in the cache memory. Therefore, we had to provide a way to manage
|
---|
190 | the cache. This module is described in the document \cite{2}. On Intel, the
|
---|
191 | memory region cache management is available only if the paging unit is enabled.
|
---|
192 | We have used this paging mechanism, with 4Kb page. All the buffers allocated
|
---|
193 | to store the incoming or outcoming frames, buffer descriptor and also the PCI
|
---|
194 | address space of the DEC board are located in a memory space with cache disable.\\
|
---|
195 |
|
---|
196 |
|
---|
197 | \noindent Concerning the buffers and their descriptors, we have tried to optimize
|
---|
198 | the memory space in term of allocated page. One buffer has 1520 bytes, one descriptor
|
---|
199 | has 16 bytes. We have 7 receive buffers and 1 transmit buffer, and for each,
|
---|
200 | 1 descriptor : (7+1){*}(1520+16) = 12288 bytes = 12Kb = 3 entire pages. This
|
---|
201 | allows not to lose too much memory or not to disable cache memory for a page
|
---|
202 | which contains other data than buffer, which could decrease performance.
|
---|
203 |
|
---|
204 |
|
---|
205 | \section{ChorusOs DEC Driver}
|
---|
206 |
|
---|
207 | Because ChorusOs is used in several Canon CRF projects, we must provide such
|
---|
208 | a driver on this OS to ensure compatibility between the RTEMS and ChorusOs developments.
|
---|
209 | On ChorusOs, a DEC driver source code already exists but only for a PowerPC
|
---|
210 | target. We plan to port this code (which uses ChorusOs API) on Intel target.
|
---|
211 | This will allow us to have homogeneous developments. Moreover, the port of the
|
---|
212 | development performed with ChorusOs environment to RTEMS environment will be
|
---|
213 | easier for the developers.
|
---|
214 |
|
---|
215 |
|
---|
216 | \section{Netboot DEC driver}
|
---|
217 |
|
---|
218 | We use Netboot tool to load our development from a server to the target via
|
---|
219 | an ethernet network. Currently, this tool does not support the DEC board. We
|
---|
220 | plan to port the DEC driver for the Netboot tool.\\
|
---|
221 |
|
---|
222 |
|
---|
223 | \noindent But concerning the port of the DEC driver into Netboot, we are faced
|
---|
224 | with a problem : in RTEMS environment, the DEC driver is interrupt or event
|
---|
225 | driven, in Netboot environment, it must be used in polling mode. It means that
|
---|
226 | we will have to re-write some mechanisms of this driver.
|
---|
227 |
|
---|
228 |
|
---|
229 | \section{\label{List}List of Ethernet cards using the DEC chip}
|
---|
230 |
|
---|
231 | Many Ethernet adapter cards use the Tulip chip. Here is a non exhaustive list
|
---|
232 | of adapters which support this driver :
|
---|
233 |
|
---|
234 | \begin{itemize}
|
---|
235 | \item Accton EtherDuo PCI.
|
---|
236 | \item Accton EN1207 All three media types supported.
|
---|
237 | \item Adaptec ANA6911/TX 21140-AC.
|
---|
238 | \item Cogent EM110 21140-A with DP83840 N-Way MII transceiver.
|
---|
239 | \item Cogent EM400 EM100 with 4 21140 100mbps-only ports + PCI Bridge.
|
---|
240 | \item Danpex EN-9400P3.
|
---|
241 | \item D-Link DFE500-Tx 21140-A with DP83840 transceiver.
|
---|
242 | \item Kingston EtherX KNE100TX 21140AE.
|
---|
243 | \item Netgear FX310 TX 10/100 21140AE.
|
---|
244 | \item SMC EtherPower10/100 With DEC21140 and 68836 SYM transceiver.
|
---|
245 | \item SMC EtherPower10/100 With DEC21140-AC and DP83840 MII transceiver. \\
|
---|
246 | Note: The EtherPower II uses the EPIC chip, which requires a different driver.
|
---|
247 | \item Surecom EP-320X DEC 21140.
|
---|
248 | \item Thomas Conrad TC5048.
|
---|
249 | \item Znyx ZX345 21140-A, usually with the DP83840 N-Way MII transciever. Some ZX345
|
---|
250 | cards made in 1996 have an ICS 1890 transciver instead.
|
---|
251 | \item ZNYX ZX348 Two 21140-A chips using ICS 1890 transcievers and either a 21052
|
---|
252 | or 21152 bridge. Early versions used National 83840 transcievers, but later
|
---|
253 | versions are depopulated ZX346 boards.
|
---|
254 | \item ZNYX ZX351 21140 chip with a Broadcom 100BaseT4 transciever.
|
---|
255 | \end{itemize}
|
---|
256 | Our DEC driver has not been tested with all these cards, only with the D-Link
|
---|
257 | DFE500-TX.
|
---|
258 |
|
---|
259 | \begin{thebibliography}{DEC21140 Hardware Manual}
|
---|
260 | \bibitem[DEC21140 Hardware Manual]{1}DIGITAL, \textit{DIGITAL Semiconductor 21140A PCI Fast Ethernet LAN Controller
|
---|
261 | - Hardware Reference Manual.}
|
---|
262 | \bibitem[99.TA.0021.M.ER]{2}Emmanuel Raguet, \textit{RTEMS Cache Management For Intel.}
|
---|
263 | \end{thebibliography}
|
---|
264 | \end{document}
|
---|