✎ soc:2010:andreif:journal:week6

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Week 6 [ Mon 28 Jun 2010 - Sun 3 Jul 2010 ] =====

==== Day 1 [ Mon 28 Jun 2010 ] ====

Git commit: [[http://git.etherboot.org/?p=people/andreif/gpxe.git;a=commit;h=caf738b675be03f6b190518cba0e6ac5cadbc5ee|caf738b675be03f6b190518cba0e6ac5cadbc5ee]]

Started working on the .open implementation today, and the first couple of lines of code were related to the NIC's power mode. Now I don't think you can interact with a NIC when it's off :) so I suspect there is some low-power mode involved that the NIC starts in.

Next up I learned about [[http://en.wikipedia.org/wiki/Ethernet_flow_control|pause frames]] which are a means of flow control in Ethernet. What happens is that a receiver overwhelmed by the amount of traffic that is sent to it, starts sending out pause frames that cause the sender to limit the amount of traffic sent. This might sound good but apparently it interferes with TCP's flow control mechanisms and this leads to [[http://www.smallnetbuilder.com/index2.php?option=com_content&task=view&id=30212&pop=1&page=0&Itemid=54|poor performance]]. Some of the nForce NICs have support for PAUSE frames.

Finally, the descriptor rings had to be set up. These differ a little from the pcnet32 descriptor. For starters, there are no separate descriptor formats for rx and tx. Both of them have the same layout:<code>
u32 buf
u32 flaglen
</code>
There is also an extended descriptor format that newer NICs use. The result is that all of the descriptors (rx+tx) are stored in one large circular buffer.

Besides these, the driver stores an array of ''struct nv_skb_map'' which has the following layout:<code>
struct sk_buff *skb
dma_addr_t dma;
unsigned int dma_len:31;
unsigned int dma_single:1;
struct ring_desc_ex *first_tx_desc;
struct nv_skb_map *next_tx_ctx;
</code>
The equivalent of the ''sk_buff'' structure is gPXE's ''iobuf'' so I renamed it ''struct nv_iob_map''. Now, the question is: what does it do? The linked list format suggests some sort of packet fragmentation but I'm not sure yet, once I reach _transmit I'll probably figure it out though.

==== Day 2 [ Tue 29 Jun 2010 ] ====

Git commit: [[http://git.etherboot.org/?p=people/andreif/gpxe.git;a=commit;h=97ac5f59a2b43b760d85318f31fd175fca9be1ee|97ac5f59a2b43b760d85318f31fd175fca9be1ee]]

Continued work on the .open routine today. I left off yesterday at rx and tx ring initialization. This involves filling the fields described above with the appropriate values. The problematic part was understanding what [[http://lxr.linux.no/linux+*/drivers/net/forcedeth.c#L1760|pci_map_single()]] does, to replace it with the appropriate functionality in the gPXE driver.

First off, Stefan mentioned that gPXE does not do DMA mapping, which I suppose means that we can't explicitly declare a memory area that is accessible by both the CPU and the device. To be more exact, we do not have an API in place to do this automatically. Linux does because there exist architectures that need more work to use DMA because of IOMMUs for example. An IOMMU is used to hold mappings between a device's address space and physical address space. This can be useful to overcome limitations imposed by a limited number of address pins on the device's part.

Another use for the DMA API is implementing bounce buffers which allow devices to DMA to/from regions that are non-DMA-able using buffers from a DMA-able region. The Linux API also offers a scatter-gather DMA abstraction.

In conclusion, I replaced the ''pci_map_single()'' call to a simple ''virt_to_bus'' call.

The next steps taken by the driver are:
  * Various initializations ( including a wonderfully named register: NvRegUnknownSetupReg6 )
  * It passes control of the rings to the hardware by writing the rings' addresses to appropriate registers
  * It sets link speed 
  * More initializations ( this time NvRegUnknownSetup5 comes in )
  * Reads NvReg[Receiver|Transmitter]Status and writes it back unmodified ( I suspect this resets some bits, just like CSR0 from pcnet32 )

Next, the driver sets up a slot time register. I already knew that slot time is the time it takes for the signal to travel the distance between two nodes, but I didn't expect to have control over it. The driver uses some pseudo-random number generator to set this value. I thought slot time had to be considered only in half-duplex modes but some constant names (NVREG_SLOTTIME_10_100_FULL) have me thinking otherwise. I'm not too sure of the role of this slot time register.

From what I've read, .open continues with interrupt management, which I'll do tomorrow, and hopefully conclude the .open implementation with it.
Trace: • project_plan • pxeknifedsl • pravin • asdlkf • stefanha • week2 • journal • week4 • journal • journal • notes • dverkamp • wrapup • old_news • week6 • project_plan