Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2008:stefanha:journal:week4 [2008/06/20 11:17] stefanha |
soc:2008:stefanha:journal:week4 [2008/06/23 04:58] (current) stefanha |
||
|---|---|---|---|
| Line 153: | Line 153: | ||
| Copy-pasting the Linux driver was not a good tactic since the Linux code is much more complex. Eventually I just focused on understanding how the hardware supports transmitting frames (there is no public documentation available!), and then implemented a simple TX path resembling the gPXE natsemi driver. | Copy-pasting the Linux driver was not a good tactic since the Linux code is much more complex. Eventually I just focused on understanding how the hardware supports transmitting frames (there is no public documentation available!), and then implemented a simple TX path resembling the gPXE natsemi driver. | ||
| - | Next steps: | + | ==== Sat Jun 21 ==== |
| - | * [b44] Implement RX path. | + | Git commit: [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=39144f971c261bcd92f5052059d444d742b0010f|[b44] Working RX path]] |
| - | * [b44] Implement TX error handling. | + | |
| - | * [bzImage] Debug Lilo triple-fault. | + | **The b44 driver is receiving Ethernet frames**. I just booted PXELINUX and HTTP-booted Linux 2.6.25 on this card for the first time! Getting the RX path working has been painful. |
| - | * [GDB] Update [[:dev:gdbstub|GDB stub page]] and screencast when UDP code is merged into mainline. See [[http://grub.enbug.org/DebuggingWithGDB|GRUB GDB wiki page]] for inspiration. | + | |
| - | * [GDB] Real-mode remote debugging. | + | I think some of the Linux driver code is misleading/incorrect. Luckily there are drivers for OpenBSD, FreeBSD, and Solaris. Those drivers might even be based on the Linux driver, but they do some things differently and it helps to compare them to each other. My main issue with the RX path was a comment in the Linux driver claiming that the hardware writes a header structure 30 bytes //before// the DMA address of the I/O buffer. |
| + | |||
| + | This is false. The Linux driver does offset the DMA address by 30 bytes, but it also offsets the IO buffer by 30 bytes. In the end, it makes no difference and all that has happened is that 30 bytes of the IO buffer have been wasted. The header structure gets written //to// the DMA address, not before it. | ||
| + | |||
| + | The next steps for the b44 driver are cleaning it up, making it robust, and testing. Most of the initialization code is straight from the Linux driver. I want to get to grips with it and then simplify it for gPXE. | ||
| + | |||
| + | I have omitted performance optimizations from the Linux driver. The Linux driver has a "copy threshold" which dictates whether to copy a received packet to a fresh IO buf to hand off to the network stack, or whether to remove the current IO buf from the RX ring and pass it straight to the network stack (and allocating a fresh IO buf for the RX ring). I'll talk to Balaji about performance measurement since he's been optimizing his USB driver. | ||
| + | |||
| + | **Lilo bzImage debugging still underway**. I made a little bit of progress tonight by determining that the triple-fault happens in the call to ''install''. I think that EIP goes crazy somewhere inside ''install'' and hence the triple fault. I'm sure the issue triggers inside ''install'' since I've placed infinite loops before and after the call. The loop after the call never happens. | ||
| + | |||
| + | My current debugging cycle is by booting up Damn Small Linux in QEMU and copying over my latest ''gpxe.lkrn'', running ''lilo'', and rebooting into gPXE. This is slow and frustrating. I need to script it but my DSL install seems to be read-only. | ||
| + | |||
| + | ===== Next week ===== | ||
| + | On to [[.:week5|Week 5]]. | ||
