cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

plip.rst (8389B)


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