packets, huh?

3c905: transmitting!

It turns out that we'd overlooked something about the northbridge's SMM handling: the memory controller blocks PCI DMA access to the SMM segments just like it prevents the CPU from reaching them. This explains why sending packets was failing before; at some point shortly after sending the first packet, the network card would attempt to access the no-longer-open frame descriptor, and be told "no!"

Now that we've set Tseg to be open all the time, packet sending works reliably under both Linux and Pebbles, and the PCI bothering code still does what it's supposed to. The next step is to start sending out screen dumps...

This brought up an interesting race condition. Suppose we have some device that we set up to repeatedly attempt to DMA our code into SMM. Most of the time, this will fail. However, at some point, an SMI will occur (and if not, we can enable some more traps); if the DMA happens to occur while the northbridge is in SMM, then shazam...

This driver would receive 0 style points if I were grading it

Magic constants abound ... even when they're #defined previously. Comments like:

        /** failed after RETRY attempts **/
        outputf("Failed to send after %d retries", retries);

Not just bad indentation (i.e., not what I want), but inconsistent indentation. Committing code, too, that you know to be wrong:

            /** I don't know what MII MAC only mode is!!! **/

The Linux driver, mind you, isn't much better:

/*  Update statistics.
        Unlike with the EL3 we need not worry about interrupts changing
        the window setting from underneath us, but we must still guard
        against a race condition with a StatsUpdate interrupt updating the
        table.  This is done by checking that the ASM (!) code generated uses
        atomic updates with '+='.
        */

By the end of this, this driver will be mostly completely rewritten. And that's fine with me.

3c905 status

After a few embarassing bugs, I have the network card initializing for me, and giving me its MAC address:

returned 0x2a
NetWatch running
Probing PCI device: 3c905c-tpo
3c90x: Picked I/O address ec00
EEPROM adr 00, data 00b0 d097 bcac 9200
EEPROM adr 04, data 00ca 0000 0000 6d50
EEPROM adr 08, data 2940 0000 00b0 d097
EEPROM adr 0c, data bcac 0020 0000 00aa
MAC Address = 00:b0:d0:97:bc:ac
Connectors present:
10Base-T / 100Base-TX
.
found 3c90x, hopefully!

I also have it transmitting packets; it manages to squeeze two packets down the wire before it hangs up and never talks to me again (and worse, sits in an infinite loop in system management mode). These sorts of hangs were pretty damn hard to diagnose last time I did this sort of stuff; hopefully I'll not be in too big trouble here.

It occurs to me that I might want better logging for my outputs; a serial logger might be nice. Maybe we should get a USB serial dongle to go with the 412mac, which is currently acting as a nice companion box that runs tcpdump, etc.

Good news!

I just got new pictures of the Dacia Sandero!

The even better news is that we found a 3c905 driver that we can pretty much just fully grab, since it has a couple of interesting features -- in particular, it's BSD-compatible (yes!), it's polling-driven (yes!), it's not Linux (yes!), and it doesn't use malloc() (yes!).

So, uh, Thanks Etherboot. Thetherboot. Here is the driver that we plan to grab, anyway; we'll see what happens tonight.