OSDev.org

I started writing a programmers guide to the rtl8169 chipset. I recently wrote this driver for the Netgear GA311 and thought id share my experiences and tips. At the moment it is very half-baked and incomplete, but I'm editing it very soon and will add more to it.

http://wiki.osdev.org/RTL8169

wow, respect on developping a driver just from the specs and guesswork, that must be very hard work... I usually don't remember anything I read from a technical specification after about 5 minutes if I understand it in the first place.

Thanks, I wrote a bunch more, and with a fully working reset example.. more to come.

looks like a nice start (it's slightly better than the RTL8139 article), i might have to purchase one and give writing my own driver a crack (the prospect of gigabit ethernet on my OS is very likeable)

Thanks to the spec link, I now almost have a functional RTL8169 driver to RDOS (I have some problem with sending packets that I will eventually figure out).

Anyway, I like this architecture a lot. The interface is simple and probably race-free, which should make for a stable driver. It's not cluttered with scatter-gather garbage either, and can offlload checksums for IP, TCP and UDP. I need to look closer at this as my NIC interface currently don't support offloading checksums.

Here is the BareMetal OS Assembly driver for the RTL816x/811x: http://code.google.com/p/baremetal/sour ... tl8169.asm

I'll be keeping an eye on this article for any potential improvements I can make.

Good to see you back on the forums, 01000101.

-Ian

ReturnInfinity wrote:Here is the BareMetal OS Assembly driver for the RTL816x/811x: http://code.google.com/p/baremetal/sour ... tl8169.asm

Interesting, but the layout of the Tx buffer is not part of the code. Currently, I know that the NIC transmits my packet (it clears the OWN + updates the fields), but I cannot see the packet from another computer (its a DHCP-packet addressed to the broadcast address). Does the buffer start with the 6 byte destination or something else?

ReturnInfinity wrote:Good to see you back on the forums, 01000101.

-Ian

Note that I bumped a thread from 2008!

os_net_rtl8169_transmit in my driver sets that up. All it needs is the address in memory where the packet is sitting and also the size of it. That information gets written into the RTL9168 transmit ring buffer. Do you see activity on the NIC or switch?

Ah, so you did. My mistake!

-Ian

Some expected feature that wasn't spelled-out properly in the spec. Apparantely, when using more than one descriptor, there is a need to go through the descriptor ring sequentially for send-packets, as the controller won't check more than the current entry for "ready-to-send". I assumed setting the "queue" bit would imply it would search through the whole descriptor-ring, but it won't do that.

Now it generally works, but after a while the receiver stops working. I have no idea about this, but can conclude that all descriptors in the ring are free. I'll check the ISR bits tomorrow.

EDIT: Issue solved. I was corrupting the EOR flag in the last descriptor. The code link below is to a working implementation.

BTW, my driver is here: http://rdos.net/vc/viewvc.cgi/trunk/ker ... iew=markup

There is an important part missing in the Wiki, as well as in other simple drivers. The spec for the NIC claims that PHY ANAR register is setup to autonegotiate all available modes, but this is not always true (not true on any of my test machines at least). Resetting the PHY won't work either. The only way to get the correct speed on some chips is to set all possible bits in the PHY ANAR register. After writing these bits during boot, and starting autonegotiation at boot and in the ISR when the link goes off, I now get the correct speed of the link. Without these, the NIC will use 10M regardless of switch/router capabilities.