OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [rtems-20020807/] [doc/] [networking/] [decdriver.t] - Blame information for rev 1765

Details | Compare with Previous | View Log

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

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.