Ethernet driver for Linux kernel 2.6 running on ML403

[Keith J Outwater]

Grant,
You bring up excellent points, and I am having to deal with these
issues in my 2.4.x kernel and U-Boot ports to VirtexII Pro FPGAs
as well.

> On 9/14/06, Michael Galassi <mgalassi at c-cor.com> wrote:
> > It is also worth noting that as released in MVL pro 4.0.1 it only
> > supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> > tagged as deprecated in the current version (8.2.01i) of Xilinx's
> > EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
> > lengths to break compatibility with older versions.  This will
> > presumably be fixed next month when it is rumored that wonderful new
> > things will come from Xilinx.  In the mean-time it is possible, though
> > neither simple, nor fun, to create Virtex4 designs with the older IP.

I think the general case is that Xilinx IP will be constantly evolving, 
and
Xilinx driver code, when released under the GPL, will appear sporadically.
Maybe it's best to resign ourselves to the fact that this situation
probably won't change, and then try to deal with it in a way that does
not depend so heavily on Xilinx drivers.

> 
> So what direction do we (as the community) want to go for supporting
> Xilinx IP in the Linux kernel?

I don't know about anyone else, but running Linux on Virtex FPGAs is
something I simply have to be able to do.  With or without Xilinx
drivers, I think the kernel needs to support Xilinx hardware.

> 
> IIRC, Xilinx intends to get drivers submitted into mainline.  (Based
> on their cross-platform driver support code).  It is unknown which and
> how many drivers for different IP versions will be submitted.

That's part of the problem: we seem to get support for some
IP cores, but not all.  Xilinx takes a piecemeal approach
to releasing drivers under the GPL.

> 
> However, the xilinx driver code is verbose and does not match well
> with the rest of the Linux code base.  (due to the cross platform
> support)  Plus, the Xilinx tool work flow is geared towards the EDK
> tool overwriting the driver code in the kernel tree with code for the
> generated design.  In which case, does it even make sense to accept
> Xilinx drivers into the Linux tree when they are just going to get
> overwritten by the toolchain anyway?  Unfortunately, regenerating
> drivers has it's own problems considering that the license on the
> generated code is not GPL compatible at the moment.

Same complaints apply for Xilinx drivers in the U-Boot bootloader.
It is proving very difficult to get Xilinx code into U-Boot which means
BSPs that use the code are hard to get submitted as well.

The Xilinx approach of overwriting the source tree just feels wrong, and
no one seems to want to do it that way.

> 
> If we reject the Xilinx driver code, then we either have to do without
> Xilinx support in mainline, or we need to write new drivers that
> address the above issues (support multiple IP versions, etc).  The
> Xilinx support in mainline right now does not use any Xilinx code.
> (Xilinx PIC and UART).
> 
> Thoughts?

As painful as it may be, maybe we just write drivers from scratch and
try to track changes in the IP.

Regards,
Keith Outwater