Subject: Re: help on finding xilinx_enet for 2.6

From: "David H. Lynch Jr" <[email-masked]>
Date: Thu, 14 Sep 2006 15:06:31 -0400

Aleck Lin wrote:
>
> David,
>
>  
>
> I saw your post from last year 
> (http://ozlabs.org/pipermail/linuxppc-embedded/2005-November/021090.html)
>
>  
>
> And I have a couple of questions.
>
>    1. Were you able to use the Xilinx_enet from 2.4 tree for kernel 2.6??
>    2. I'm assuming that you've probably have made it work by now. Can
>       I get some hints on making the ethernet driver for 2.6?
>
>  
>
> Thanks!
>
>  
>
> Aleck
>
Aleck;

    I have been doing board bringup for the Pico E1x series of boards. 
They are Xilinx V4 boards.
    I started with the Linux 2.6 kernel.org tree before there was any 
Xilinx V4 support - I have subsequently conformed
    my code to Grant's patches.
    I looked at the MV xilinx_edk stuff for UartLite and Ethernet and 
decided their code just looked too gnarly.
    I wrote a UartLite driver of my own from scratch. It was fairly 
simple and I have Uartlite support from the early boot code on.

    I started the TEMAC much later. Pico had me work with the LocalLink 
TEMAC at first. That was an almost from scratch driver.
    It was just barely working when they switched gears and decided to 
use the PLB FIFO TEMAC.
    I pulled the MV 2.6 TEMAC driver from the patches posted on this 
list - NOT from the 2.4 tree - though there is an obvious common heritage.
    That driver works fine - given the caveat I listed - it does NOT 
have PHY/MII autonegotiation support. It is not difficult to hardcode 
for whatever
    fixed speed you want, but the caveat is still there. Purportedly, 
proper support is complete or nearly complete - but I have not seen it 
posted.

    In the interim I started a from scratch PLB FIFO TEMAC driver. It 
does NOT support SG DMA - I think Xilinx is now insisting you build the
    PLB TEMAC one way or the other, but you can't build it both. As such 
I do not beleive the driver should be designed to be able to dynamic 
mode switching
    on a condition that can not change dynamically - byt the 
MV/Xilinx_EDK driver does.

    I also had another motive for doing a from scratch driver - I had a 
contract to write basically the same driver for GHS Integrity.
    I basically took the Linux driver gutted the Linux specific 
interfaces, added the GHS interfaces and created a Linux like sk_buff 
shim for GHS and had the thing working in fairly
    short order. In fact the GHS driver works better than the Linux 
driver at the moment. It was also a higher priority.
    I am only just getting back to cleaning up and fixing the Linux 
driver - so it still has a few minor problems and I need to pick up some 
improvements that occured as it
    moved forward to GHS.

    My from scratch driver very loosely used the EDK code as a starting 
point. It drew atleast as much from my LL TEMAC. Right now it sends 
fine. Autonegotiates
    10/100/1000 FD. It appears to receive fine, but Linux silently 
dropps the received packets without reporting an error.
    Whatever the problem is - it is with my driver. It is almost 
certainly trivial. It is also almost certainly going to be a bear to find.
    I had hoped someone with a similar problem (on any driver) might 
have given me a clue how they fixed it. But so far no joy.
    I only recently got back to work on the Linux driver. I do expect it 
will be complete soon.

    In the meantime the posted MV Xilinx_edk based driver works - within 
its limits.

-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       [email-masked] 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein