Root/
1 | PLIP: The Parallel Line Internet Protocol Device |
2 | |
3 | Donald Becker (becker@super.org) |
4 | I.D.A. Supercomputing Research Center, Bowie MD 20715 |
5 | |
6 | At some point T. Thorn will probably contribute text, |
7 | Tommy Thorn (tthorn@daimi.aau.dk) |
8 | |
9 | PLIP Introduction |
10 | ----------------- |
11 | |
12 | This document describes the parallel port packet pusher for Net/LGX. |
13 | This device interface allows a point-to-point connection between two |
14 | parallel ports to appear as a IP network interface. |
15 | |
16 | What is PLIP? |
17 | ============= |
18 | |
19 | PLIP is Parallel Line IP, that is, the transportation of IP packages |
20 | over a parallel port. In the case of a PC, the obvious choice is the |
21 | printer port. PLIP is a non-standard, but [can use] uses the standard |
22 | LapLink null-printer cable [can also work in turbo mode, with a PLIP |
23 | cable]. [The protocol used to pack IP packages, is a simple one |
24 | initiated by Crynwr.] |
25 | |
26 | Advantages of PLIP |
27 | ================== |
28 | |
29 | It's cheap, it's available everywhere, and it's easy. |
30 | |
31 | The PLIP cable is all that's needed to connect two Linux boxes, and it |
32 | can be built for very few bucks. |
33 | |
34 | Connecting two Linux boxes takes only a second's decision and a few |
35 | minutes' work, no need to search for a [supported] netcard. This might |
36 | even be especially important in the case of notebooks, where netcards |
37 | are not easily available. |
38 | |
39 | Not requiring a netcard also means that apart from connecting the |
40 | cables, everything else is software configuration [which in principle |
41 | could be made very easy.] |
42 | |
43 | Disadvantages of PLIP |
44 | ===================== |
45 | |
46 | Doesn't work over a modem, like SLIP and PPP. Limited range, 15 m. |
47 | Can only be used to connect three (?) Linux boxes. Doesn't connect to |
48 | an existing Ethernet. Isn't standard (not even de facto standard, like |
49 | SLIP). |
50 | |
51 | Performance |
52 | =========== |
53 | |
54 | PLIP easily outperforms Ethernet cards....(ups, I was dreaming, but |
55 | it *is* getting late. EOB) |
56 | |
57 | PLIP driver details |
58 | ------------------- |
59 | |
60 | The Linux PLIP driver is an implementation of the original Crynwr protocol, |
61 | that uses the parallel port subsystem of the kernel in order to properly |
62 | share parallel ports between PLIP and other services. |
63 | |
64 | IRQs and trigger timeouts |
65 | ========================= |
66 | |
67 | When a parallel port used for a PLIP driver has an IRQ configured to it, the |
68 | PLIP driver is signaled whenever data is sent to it via the cable, such that |
69 | when no data is available, the driver isn't being used. |
70 | |
71 | However, on some machines it is hard, if not impossible, to configure an IRQ |
72 | to a certain parallel port, mainly because it is used by some other device. |
73 | On these machines, the PLIP driver can be used in IRQ-less mode, where |
74 | the PLIP driver would constantly poll the parallel port for data waiting, |
75 | and if such data is available, process it. This mode is less efficient than |
76 | the IRQ mode, because the driver has to check the parallel port many times |
77 | per second, even when no data at all is sent. Some rough measurements |
78 | indicate that there isn't a noticeable performance drop when using IRQ-less |
79 | mode as compared to IRQ mode as far as the data transfer speed is involved. |
80 | There is a performance drop on the machine hosting the driver. |
81 | |
82 | When the PLIP driver is used in IRQ mode, the timeout used for triggering a |
83 | data transfer (the maximal time the PLIP driver would allow the other side |
84 | before announcing a timeout, when trying to handshake a transfer of some |
85 | data) is, by default, 500usec. As IRQ delivery is more or less immediate, |
86 | this timeout is quite sufficient. |
87 | |
88 | When in IRQ-less mode, the PLIP driver polls the parallel port HZ times |
89 | per second (where HZ is typically 100 on most platforms, and 1024 on an |
90 | Alpha, as of this writing). Between two such polls, there are 10^6/HZ usecs. |
91 | On an i386, for example, 10^6/100 = 10000usec. It is easy to see that it is |
92 | quite possible for the trigger timeout to expire between two such polls, as |
93 | the timeout is only 500usec long. As a result, it is required to change the |
94 | trigger timeout on the *other* side of a PLIP connection, to about |
95 | 10^6/HZ usecs. If both sides of a PLIP connection are used in IRQ-less mode, |
96 | this timeout is required on both sides. |
97 | |
98 | It appears that in practice, the trigger timeout can be shorter than in the |
99 | above calculation. It isn't an important issue, unless the wire is faulty, |
100 | in which case a long timeout would stall the machine when, for whatever |
101 | reason, bits are dropped. |
102 | |
103 | A utility that can perform this change in Linux is plipconfig, which is part |
104 | of the net-tools package (its location can be found in the |
105 | Documentation/Changes file). An example command would be |
106 | 'plipconfig plipX trigger 10000', where plipX is the appropriate |
107 | PLIP device. |
108 | |
109 | PLIP hardware interconnection |
110 | ----------------------------- |
111 | |
112 | PLIP uses several different data transfer methods. The first (and the |
113 | only one implemented in the early version of the code) uses a standard |
114 | printer "null" cable to transfer data four bits at a time using |
115 | data bit outputs connected to status bit inputs. |
116 | |
117 | The second data transfer method relies on both machines having |
118 | bi-directional parallel ports, rather than output-only ``printer'' |
119 | ports. This allows byte-wide transfers and avoids reconstructing |
120 | nibbles into bytes, leading to much faster transfers. |
121 | |
122 | Parallel Transfer Mode 0 Cable |
123 | ============================== |
124 | |
125 | The cable for the first transfer mode is a standard |
126 | printer "null" cable which transfers data four bits at a time using |
127 | data bit outputs of the first port (machine T) connected to the |
128 | status bit inputs of the second port (machine R). There are five |
129 | status inputs, and they are used as four data inputs and a clock (data |
130 | strobe) input, arranged so that the data input bits appear as contiguous |
131 | bits with standard status register implementation. |
132 | |
133 | A cable that implements this protocol is available commercially as a |
134 | "Null Printer" or "Turbo Laplink" cable. It can be constructed with |
135 | two DB-25 male connectors symmetrically connected as follows: |
136 | |
137 | STROBE output 1* |
138 | D0->ERROR 2 - 15 15 - 2 |
139 | D1->SLCT 3 - 13 13 - 3 |
140 | D2->PAPOUT 4 - 12 12 - 4 |
141 | D3->ACK 5 - 10 10 - 5 |
142 | D4->BUSY 6 - 11 11 - 6 |
143 | D5,D6,D7 are 7*, 8*, 9* |
144 | AUTOFD output 14* |
145 | INIT output 16* |
146 | SLCTIN 17 - 17 |
147 | extra grounds are 18*,19*,20*,21*,22*,23*,24* |
148 | GROUND 25 - 25 |
149 | * Do not connect these pins on either end |
150 | |
151 | If the cable you are using has a metallic shield it should be |
152 | connected to the metallic DB-25 shell at one end only. |
153 | |
154 | Parallel Transfer Mode 1 |
155 | ======================== |
156 | |
157 | The second data transfer method relies on both machines having |
158 | bi-directional parallel ports, rather than output-only ``printer'' |
159 | ports. This allows byte-wide transfers, and avoids reconstructing |
160 | nibbles into bytes. This cable should not be used on unidirectional |
161 | ``printer'' (as opposed to ``parallel'') ports or when the machine |
162 | isn't configured for PLIP, as it will result in output driver |
163 | conflicts and the (unlikely) possibility of damage. |
164 | |
165 | The cable for this transfer mode should be constructed as follows: |
166 | |
167 | STROBE->BUSY 1 - 11 |
168 | D0->D0 2 - 2 |
169 | D1->D1 3 - 3 |
170 | D2->D2 4 - 4 |
171 | D3->D3 5 - 5 |
172 | D4->D4 6 - 6 |
173 | D5->D5 7 - 7 |
174 | D6->D6 8 - 8 |
175 | D7->D7 9 - 9 |
176 | INIT -> ACK 16 - 10 |
177 | AUTOFD->PAPOUT 14 - 12 |
178 | SLCT->SLCTIN 13 - 17 |
179 | GND->ERROR 18 - 15 |
180 | extra grounds are 19*,20*,21*,22*,23*,24* |
181 | GROUND 25 - 25 |
182 | * Do not connect these pins on either end |
183 | |
184 | Once again, if the cable you are using has a metallic shield it should |
185 | be connected to the metallic DB-25 shell at one end only. |
186 | |
187 | PLIP Mode 0 transfer protocol |
188 | ============================= |
189 | |
190 | The PLIP driver is compatible with the "Crynwr" parallel port transfer |
191 | standard in Mode 0. That standard specifies the following protocol: |
192 | |
193 | send header nibble '0x8' |
194 | count-low octet |
195 | count-high octet |
196 | ... data octets |
197 | checksum octet |
198 | |
199 | Each octet is sent as |
200 | <wait for rx. '0x1?'> <send 0x10+(octet&0x0F)> |
201 | <wait for rx. '0x0?'> <send 0x00+((octet>>4)&0x0F)> |
202 | |
203 | To start a transfer the transmitting machine outputs a nibble 0x08. |
204 | That raises the ACK line, triggering an interrupt in the receiving |
205 | machine. The receiving machine disables interrupts and raises its own ACK |
206 | line. |
207 | |
208 | Restated: |
209 | |
210 | (OUT is bit 0-4, OUT.j is bit j from OUT. IN likewise) |
211 | Send_Byte: |
212 | OUT := low nibble, OUT.4 := 1 |
213 | WAIT FOR IN.4 = 1 |
214 | OUT := high nibble, OUT.4 := 0 |
215 | WAIT FOR IN.4 = 0 |
216 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9