Git commit: 0906919af2982e3f285287035c210e101fafd783

Today I continued with my work on the forcedeth driver. Eventually I reached a point where I really needed the registers mapped. At this point, I was really confused since I saw that most of the drivers simply got ioaddr as the base address or used ioremap to get a memory mapped BAR. The Linux driver can't do this since some models have different register sizes (i guess this is the total size of all registers). So, it has to search all the BARs and select the one which describes the largest memory area. I had to go a bit more low-level to do this, and use some pci_* routines. With stefanha's help I did manage to do it eventually.

I spent most of the time reading up on the PCI specification and studying to see if other drivers have this problem. There is the via-velocity driver which has a similar problem and implements its own pci_resource_flags routine. Perhaps this should be moved to a common header somewhere.

Tomorrow I'll finish .probe and do the first tests on the NIC I have :)

Git commit: 57da3ac719c5a15cf772dfa2cc5bf93cf6434eb5

Well, I guess one should not count his chickens before they hatch. The .probe routine branched into a lot of other routines, some of which were not that easy to understand. There is yet another routine I have to implement phy_init which I'll get to tomorrow.

In other news, I posted my r8169 patch today.

Git commit: a344aefa7cc02caa32aa4bb85f23748f7673d676

Finally the implementations are done. I managed to finish both .probe and .remove today, along with some auxiliary routines they used. There is a surprising amount of code involved, mostly due to small vendor-specific tweaks. I'll post a description tomorrow regarding the registers I've used so far, and what I have learned about the NICs. The code will have to be cleaned, I have some routines a gazillion lines long.

Everything's ready for the first test tomorrow.

Git commit: 5756a78e83b6a83851a07fce80b2993772b772ce

Lots'o'issues today.

• Using the forcedeth.usb image does not work. At first I thought that there was a problem with my USB stick, but then Marty confirmed that this seems to be an issue with a lot of systems and suggested I use SYSLINUX instead. And so I did. I followed the instructions from here to create the bootable stick. It worked, but SYSLINUX gave an error: cannot find kernel image. It was surprising since forcedeth.lkrn was there on the stick and the syslinux.cfg file was correct. Well, I learned something new because of this; since I formatted the disk with mkdosfs, the filnames have a restriction. Renaming forcedeth.lkrn to forcedet.lkr and modifying the syslinux.cfg accordingly, I managed to get gPXE to boot.

• And yet, it doesn't work! Naturally I now enabled debugging messages to see how the .probe routine behaved. Nothing showed up. I enabled debugging in PCI too and that didn't work either. In case someone else runs into the same problems, here are some of the things you might want to look for (all compiled from the discussion I had today with Marty and Stefan):
  • the file you want to debug does have actual DBG messages
  • output is redirected to the serial console (config/console.h)
  • check the link map to see if the object you're debugging gets imported
  • make sure the driver does have a PCI_ROM statement that corresponds to the NIC's characteristics
  • call adjust_pci_device()
  • make sure the struct pci_driver isn't tagged with an __unused label

The last two of these were the problems I've had, but I went through all of them in order to figure out what the problem was. As a result, .probe now works, life is good. Of course, bugs related to it will surface once I implement the other routines.

I didn't get to do anything else today, I'll have to catch up tomorrow. As Stefan said, booting from an USB stick can be a real pain because of the constant dd-ing and moving of the switch from one USB port to another. As he suggested, I'll get a switch and setup a small DHCP server that can service the forcedeth machine with an image it can chainload.

Hurray for using gPXE for the first time on a physical machine

Only managed to run a couple of tests on Virtual Box today, with console disabled. There was a clear difference in speed with the console disabled but overall speeds increased because of packet interception (my guess). I should investigate this, plus try it with the rtdsc timer.

me.\m/()

me.rest()