Intel pro 100 (8255x) not responding to commands as expected

[agargiulo]

I've read through Intel's manual, and looked at the source code for the linux and freeBSD drivers for examples on how to setup and configure the intel pro 100 (8255x) network card. As far as I can tell, I'm writing the command to the correct PCI device at the correct offsets from the CSR IO Mapped Base Address Register, but the device is not responding according to how the documentation claims it will. I am being told to load 0 into the CSR SCB General Pointer (offset of 0x4 from the IO Mapped BAR) then use the Load CU Base Address SCB command (0x0060).

Code: Select all

    __outl(CSR_BAR + E_CSR_SCB_GEN_PTR, 0x00000000);
    __outb(CSR_BAR + E_CSR_SCB_COM_WORD, 0x60);

They then tell me to wait for that register to return 0 on read, and then run the same sequence with the Receive Unit (RU).

The first sequence writes the correct value to what appears to be the correct register, but then I read the register every tenth of a millisecond or so, and it's still 0x0060 instead of 0x0000

If I don't wait, or do that command at all, and write the command for the RU down to the device, (0x0006), the interrupt is generated (and was supposed to happen for that first write as well). But from what I can tell, the RU is now in suspended mode and I get a different result when I read back the byte I just wrote (0x0004 vs. 0x0006)
I know that I am writing down to the correct locations, because when I use PORT software reset command, it works just fine.

[agargiulo]

So that future people don't come across this exact same issue, find my thread, and rage because it was left unanswered, here you go:

I found out that the Base Address I read in from an offset of 0x14 on the PCI configuration has a hard coded 1 for the least-significant bit. That 1 signifies that the Base Address is IO Mapped. What I failed to see in the documentation was this:

Base registers that map into I/O space are always 32 bits with bit 0 hard wired to a 1, bit 1 is reserved
and must return 0 on reads, and the other bits are used to map the device into I/O space.

So the address I was getting (in this case 0x0000E001) was including two bits that I was supposed to mask. This caused everything I read and wrote to be a single byte too high.
When I read from the status word, I was actually getting the most significant byte of the status word and the least significant byte of the command word. Writing to the command byte actually wrote to the half of the word I was supposed to leave alone for the most part, and reading it back was obviously wrong because the card didn't clear that half of the register.

In other words, this is what you want to do:

Code: Select all

uint32_t CSR_BAR = pci_readl(dev->bus, dev->slot, dev->func, 0x14) & 0xFFFFFFFC;

[sortie]

I think this is a subset of the general PCI model. Whenever you encounter a PCI BAR, you should parse it in the standard manner and see whether the registers are memory mapped or not, and whether the location in memory is a 32-bit or 64-bit value. See the wiki PCI article for more information.