Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
soc:2010:andreif:journal:week1 [2010/05/26 12:17] andreif |
soc:2010:andreif:journal:week1 [2010/05/29 10:39] andreif |
||
|---|---|---|---|
| Line 61: | Line 61: | ||
| * PORTSEL - //Port Select// - allows software controlled selection of the network medium | * PORTSEL - //Port Select// - allows software controlled selection of the network medium | ||
| * ASEL - //Auto Select// - automatically select the operating media interface port | * ASEL - //Auto Select// - automatically select the operating media interface port | ||
| + | |||
| + | ==== Day 4 ==== | ||
| + | Git commit: [[http://git.etherboot.org/?p=people/andreif/gpxe.git;a=commit;h=eb08022a85cf8c63fe9de240cb2d00679d942006|eb08022a85cf8c63fe9de240cb2d00679d942006]] | ||
| + | |||
| + | Heh. Today was fun. I kept on going with the .probe routine and the first two lines of code | ||
| + | <code C> | ||
| + | priv->tx_ring_size = TX_RING_SIZE; | ||
| + | priv->rx_ring_size = RX_RING_SIZE; | ||
| + | </code> | ||
| + | led me to read about the descriptor rings. They contain information about data buffers scattered in memory, such as: address, length, status. At this point I don't know if a frame can be split across multiple buffers or not, but I'll cross that bridge when I get to it. Today was about | ||
| + | allocating the memory necessary for these descriptors and it turns out this is easy to do with ''malloc_dma'' and ''free_dma'' which allocates aligned memory (as the specifications required). The old driver didn't do this, so I browsed the r8169 code to see how it's done. Also it seems that the old one worked with only one Tx descriptor. | ||
| + | |||
| + | The old driver had 4 Tx and 16 Rx buffers by default, but the new one has 16 Tx and 32 Rx buffers. I'm not sure how these numbers are chosen. Empirically, perhaps (observe which combination performs better)? | ||
| + | |||
| + | The next lines involved setting up the MII (//Media Independent Interface//). I wasn't quite sure what that was so I started browsing. Turns out modern NICs use this to separate layer 2 from layer 1 basically. To be more specific, the chip that implements the MAC logic is separated from the PHY chip (which, from what I can tell, is the closest thing to the wires from the NIC). Since the physical medium can range from copper to fiber optics to quantum carrier pigeons, the MII allows the MAC to remain oblivious to this diversity. | ||
| + | |||
| + | Eventually the initialization block was all done and after switching to 32bit mode I could tell the NIC where to find it. | ||
| + | |||
| + | At stefanha's suggestion i started refactoring the .probe routine a bit, since it was quickly becoming >4 screens long. Even though I've moved around some large code blocks, the routine still has 3 screens because of everything else that I've added. It needs more cowbell. | ||
| + | |||
| + | ==== Day 5 ==== | ||
| + | Git commit: [[http://git.etherboot.org/?p=people/andreif/gpxe.git;a=commit;h=f77ad7eee94a3d161a2ddf0c94a8906a75169d24|f77ad7eee94a3d161a2ddf0c94a8906a75169d24]] | ||
| + | |||
| + | Didn't manage to do as much as I wanted today. The .probe implementation is almost done, there are a few missing pieces such as the debugging code for 0x2620 and 0x2624 and the options settings. The debugging code isn't mandatory for now since I don't have any of those specific chips. I want to keep the .probe implementation as clean as possible since I'll probably be referring to it a lot to see if I forgot to initialize stuff. So for now I'll keep that debugging code out. When all is done, I'll bring the code in. The //options// are used later in the code, so I'll tackle those when I reach the specific sections. Also, the TX and RX descriptors aren't fully initialized yet, I'll do that when I actually implement tx and rx. Other than that :), the .probe routine is pretty much done. | ||
| + | |||
| + | Did a test to see if .probe runs all the way through and this gave me an oportunity to fix some bugs, mostly related to the fact that I performed certain initializations after they were required. Gpxe now tells me that the .open routine is unsupported, so I guess I'll tackle that next. | ||
| + | |||
| + | ==== Day 6 ==== | ||
| + | Git commit: [[http://git.etherboot.org/?p=people/andreif/gpxe.git;a=commit;h=ad2ec93a52650947ce04e55f765456b6e22dcb36|ad2ec93a52650947ce04e55f765456b6e22dcb36]] | ||
| + | |||
| + | Today I ran into the first piece of code that I just couldn't understand. Starting the .open implementation, I had to set up the options field. This field describes some of the NICs capabilities, such as: duplex mode, auto negotiation, 10/100Base-T, etc. This is all good but the way these options are selected in both the Linux driver and the old driver don't make any sense to me. I spent several hours browsing the source code and the Internet trying to find some answers but this didn't yield any results. After a while I went on with the .open implementation, I understand what it does, but the way the options are set is all wrong so nothing I've written so far works how its supposed to. | ||
| + | |||
| + | For example, my current chip is an AM79C970A which can do full-duplex. Because of the options, the old driver's code ends up taking a path leading to the access of BCR32 which the chip doesn't have. I'm not sure if the NIC silently fails when you try to access an inexistent register or something really evil happens :) | ||
| + | |||
| + | If I don't figure this out by tomorrow, I'll set the options as they should be for my current chip and after the driver works, I'll go through each other chips' datasheet and figure out the rest. | ||
| + | |||
| + | Some other stuff to note: | ||
| + | * AUI - //Attachment Unit Interface// | ||
| + | * GPSI - //General Purpose Serial Interface// | ||
