AMD PCNET: Difference between revisions

The first task of the driver should be to enable the IO ports and bus mastering ability of the device in PCI configuration space. This is done by setting bits 0 and 2 of the control register, e.g. <sourcesyntaxhighlight lang="c">uint32_t conf = pciConfigReadDWord(bus, slot, func, offset);

pciConfigWriteDWord(bus, slot, func, offset, conf);</sourcesyntaxhighlight>

In addition, the card requires different length data accesses to the registers depending on the setting of DWIO: if DWIO=0, then offsets 0x0 through 0xf are read as single bytes, all others read/written as 16-bit words; if DWIO=1, then all registers (including 0x0 through 0xf) are read/written as 32-bit double words (and with accesses aligned on 32-bit boundaries). We can write functions to access the registers:<sourcesyntaxhighlight lang="c">void writeRAP32(uint32_t val)

}</sourcesyntaxhighlight>

Unfortunately it is difficult to determine the current state of DWIO (and therefore know which state the card is in when the driver initializes) as the only way of reporting it is to read BCR18 bit 7, which in turn requires knowledge of the BDP, which requires knowledge of DWIO etc. Fortunately, following a reset (either hard or soft), the card is in a known state with DWIO=0 (16-bit access). Normally, therefore, when your driver takes control of the card, it canwould expect to assume it is in 16-bit mode. However, it may be the case that firmware or a bootloaderboot-loader has already initialized the card into 32-bit mode, which you didn't know about. You should, therefore, reset the card when your driver takes control. This is accomplished by a read of the reset register:<sourcesyntaxhighlight lang="c">ind(io_base + 0x18);

inw(io_base + 0x14);</sourcesyntaxhighlight>Note this snippet reads first from the 32-bit reset register: if the card is in 32-bit mode this will trigger a reset, if in 16-bit mode it will simply read garbage without affecting the card. It then reads from the 16-bit reset register: if the card was initially in 32-bit mode, it has since been reset and will now be reset again, otherwise it will reset for the first time.

Then, if desired, you can program the card into 32-bit mode (the rest of this article assumes this, but you can easily substitute read/writeCSR32 with read/writeCSR16 if you like). To do this, we simply need to perform a 32 bit write of 0 to the RDP. After reset, RAP points to CSR0, so we are effectively writing 0 to CSR0. This will not cause any harm as we completely reprogram CSR0 later anyway.<sourcesyntaxhighlight lang="c">outd(io_base + 0x10, 0);</sourcesyntaxhighlight>

We now need to set the value of SWSTYLE to 2. After reset, it defaults to 0 representing 16-bit legacy compatibility mode. We want the card to be able to access all of the first 4 GiB of (physical) memory for its buffers, so need to set it to 32-bit mode.<sourcesyntaxhighlight lang="c">uint32_t csr58 = readCSR32(58);

csr58 &= 0xfff00xFF00; // SWSTYLE is 8 bits (7:0)

writeCSR32(58, csr58);</sourcesyntaxhighlight>

The card has both 10/100baseT and coaxial outputs. It has functionality to automatically select whichever is attached which is normally enabled by default. This snippet simply ensures this functionality is enabled by setting the ASEL bit in BCR2 just in case firmware has altered this for some reason.<sourcesyntaxhighlight lang="c">uint32_t bcr2 = readBCR32(2);

writeBCR32(2, bcr2);</sourcesyntaxhighlight>

For example, if you wisewish to define 32 receive buffers and 8 transmit buffers (similar to what the Linux driver does), then you would need to allocate 32 * 16 bytes for the receive DEs, 8 * 16 bytes for the transmit DEs, 32 * packet length (1544 is used in Linux, but we will use 15481520 as it is a multiple of 16) for the actual receive buffers and 8 * packet length for the actual transmit buffers.

The DEs contain a number of important bits for sending/receiving packets, e.g. destination MAC address, error bits etc. but they also contain an important bit called the ownership bit (bit 7 of byte 7). If this is cleared, it means the driver 'owns' that particular ring buffer entry. If it is set, it means the card owns it (and the driver should not touch the entire entry). The way this works is that the only party (driver or card) that can read/write the entry is the one that owns it, and particularly only the owning party can flip ownership back to the other party. At initialization, you would want the card to 'own' all the receive buffers (OWN = 1) (so it can write new packets into them that it receives, then flip ownership to the driver), and the driver to 'own' all the transmit buffers (OWN = 0) (so it can write packets to be transmitted, then flip ownership to the drivercard). For the Transmit Ring, remember to not set the OWNer bit until you have a buffer to transmit.

Thus to initialize the ring buffers you'd want something like:<sourcesyntaxhighlight lang="c">int rx_buffer_ptr = 0;

const int buffer_size = 15481520; // length of each packet buffer

if(cur_tx_idxret == tx_buffer_count)

if(cur_rx_idxret == rx_buffer_count)

memset(&des[idx * de_size], de_size0, 0de_size);

}</sourcesyntaxhighlight>

| 0 || TLEN << (7:4)* || RLEN << (7:4)* || colspan="2" | MODE

Note that TLEN and RLEN are the log2 of the number of transmit and receive descriptor entries respectively and are in the high order nibble of the byte while the lower nibble of the byte is reserved. For example, if you have 8 transmit descriptor entries, TLEN would be 3 (as 2^3 = 8),. whichThe youmaximum thenvalue needof toTLEN shiftand leftRLEN byis 49 bits,(i.e. so512 thebuffers). actual valueHowever, toafter writeinitialization, toyou bytemay 3change wouldthis beto 0x30. Thea maximum value of TLEN65535 andbyte RLENwriting isto 9the (i.e.CSR76 512and buffers)CSR78 registers.

MODE provides various functions to control how the card works with regards to sending and receiving packets, and running loopbackloop-back tests. You probably want to set it to zero (enable transmit and receive functionality, receive broadcast packets and those sent this physical address, disable promiscuous mode). See the spec description of CSR15 for further details.

| 2 || Big -endian enable - you will want to ensure this is cleared to zero

For example:<sourcesyntaxhighlight lang="c">int sendPacket(void *packet, size_t len, uint8_t *dest)

}</sourcesyntaxhighlight>

Note that interrupts can come from many sources (other than new packets). If a new packet has been signalledsignaled then CSR0 bit 10 will be set. There are other bits in CSR0 than can be set (depending on how you set up interrupt masks in CSR3) and additionally other bits in CSR4 that can signal interrupts (although these are usually masked out on reset). After you have properly handled an interrupt, you will need to write a 1 back to the appropriate bit in CSR0 or CSR4 before sending EOI to you interrupt controller (or the interrupt will continue to be signalledsignaled). ORingBitwise OR CSR0 with 0x7f000x7F00 and ORingbitwise OR CSR4 with 0x026a0x022A will reset all interrupts. Remember to preserve bit 6 in CSR0 and bit 11 in CSR4.

Once a receive packet interrupt has been received, you need to loop through the receive descriptor entries (starting at rx_buffer_ptr) handling each packet until you find an entry which the driver doesn't own, then stop. e.g. <sourcesyntaxhighlight lang="c">void handleReceiveInterrupt()

writeCSR32(0, readCSR32(0) | 0x0400);

}</sourcesyntaxhighlight>

* [httphttps://wwwpdf1.datasheetcatalogalldatasheet.orgcom/datasheet-pdf/AdvancedMicroDevicesview/mXxsxv89876/AMD/AM79C970.pdfhtml Specification]