Table of Contents
Week 5 [ Mon 21 Jun 2010 - Sun 27 Jun 2010 ]
Day 1 [ Mon 21 Jun 2010 ]
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 :)
Day 2 [ Tue 22 Jun 2010 ]
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.
Day 3 [ Wed 23 Jun 2010 ]
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.
Day 4 [ Thu 24 Jun 2010 ]
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 sinceforcedeth.lkrn
was there on the stick and thesyslinux.cfg
file was correct. Well, I learned something new because of this; since I formatted the disk withmkdosfs
, the filnames have a restriction. Renamingforcedeth.lkrn
toforcedet.lkr
and modifying thesyslinux.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
Day 5 [ Fri 25 Jun 2010 ]
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.
Day 6 [ Sat 26 Jun 2010 ]
me.\m/()
Day 7 [ Sun 27 Jun 2010 ]
me.rest()