More comments below... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J Outwater Sent: Thursday, September 14, 2006 11:36 AM To: linuxppc-embedded@ozlabs.org Subject: RE: Ethernet driver for Linux kernel 2.6 running on ML403
> Hi, > > I just saw this thread. The next version of EDK 8.2.2 will have a temac > v3.00a driver for linux 2.6. Our plan is to begin our code freeze stage > tomorrow. If people really need the driver right away, and can't wait a > few weeks for the release, I could possibly provide a patch (or use some > other distribution method) for the driver. > > Here at Xilinx, we have been in talks about having our drivers more > readily available in the open source repositories. As far as I know, > everyone seems to think that this would be a good thing for us. Right > now the plan is to have a 3rd party check our drivers into the main > repository as we have limited resources here. (Basically we're up to our > eyeballs in work right now.) I know that MontaVista is you preferred Linux partner - if they do the released, then we have to wait for them. If individual designers can get the driver sources, you can bet it will make it's way into the mainline kernel. > > I do know that Xilinx would rather play a principle role in developing > and maintaining these open source drivers, rather than having a separate > group go off and implement a separate set. You may end up having to serve multiple customer bases then, to keep things from forking. The are lots of us who want to have lots of fine-grained control over our source trees and the way in which we do builds. [John] One thing that may help you, is that you can clear out the 'target_dir' setting in xps. That will let you generate the BSP and then simply copy over the files you need. > > << 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.>> > > I've only touched on U-Boot a little bit. Have any thoughts on how to > make this easier? My perspective on this is that of a hardware designer who also develops code. I understand that is a good thing from the Xilinx point of view to make it as easy as possible for designers to develop designs using EDK with automatic BSP generation. It's great for doing stand alone (no OS) designs or to get "instant gratification" as in "gee, I just booted Linux!" (a la Xilinx XAPP765). When you do that, though, invariably you end up having to make decisions that constrain how the design flow works for the user and then it's hard for the user to deviate from that flow. For example, the idea of having a user auto-generate source code for a BSP that overwrites the bootloader or kernel source tree. The problem is that it's hard to "take the training wheels off" if I want or need to have a stable source base of if I want to use the mainline kernel or the mainline bootloader (U-Boot). What if the source code bases for the kernel or bootloader get re-arranged? What I'd really like to have is "out of the box" kernel support for all the primary peripheral devices like communications and interface stuff and U-Boot support for those devices as well. I don't want to have to generate BSPs and overwrite the source trees. [John] See my comment above. The whole licensing thing is another issue. As I stated to someone else at Xilinx: These are just drivers, not the crown jewels. GPL it all and make it easier for designers to incorporate the code into open source projects. Dual license if you have customers who have to have things locked up. [John] I believe this is our intention going forward. For U-Boot, I'm getting push-back from the maintainer on the size and "verbosity" of the code. Sounds like this might be an issue for the kernel as well. > > << The Xilinx approach of overwriting the source tree just feels wrong, > and > no one seems to want to do it that way.>> > > I am in the group that has control over how this is done. What would you > propose be done different? Keep in mind that we are trying to support a > process where someone builds a hardware design and the later changes it > with new peripherals or perhaps makes minor tweaks. We want to make the > updating of the Linux kernel to reflect these hardware changes easy for > people. A noble goal, and clearly the right thing to do from a user-success point of view, but do the hardware peripherals (i.e. the IP cores) change that much? See my comment below: Can you create a system that allows software drivers to verify that they (the drivers) are compatible with a particular IP version? For the novice user, the "full auto" system probably works fine, but for (some, at least) experienced users, it tends to be an additional layer or complexity (or opacity) that would be nice to get rid of. > > Having the ability to make rapid hardware changes, I think, is a bit > different from what most folks are used to. I agree. I think we all need to agree how best to manage the driver code so that as IP versions change, the drivers can be properly matched to the IP. Also, as more and more people port Linux to their Virtex designs, we can (hopefully) expect more "out of the box" support for Xilinx hardware. That's basically the situation you have with more conventional peripheral devices. [John] Yep, we'd like this too. I don't think that there are any "version" registers in the Xilinx IP cores that a driver could check to determine compatibility. That would be very cheap to implement in hardware and you could then develop more universal drivers. [John] We've examined doing this in the past, and gotten some push back due to the use of bram or other resources. Conceptually, it's a great idea, I just don't know if this is likely to happen any time soon. > > Cheers, > > - John > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Keith J Outwater > Sent: Thursday, September 14, 2006 9:48 AM > To: linuxppc-embedded@ozlabs.org > Subject: Re: Ethernet driver for Linux kernel 2.6 running on ML403 > > 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 <[EMAIL PROTECTED]> 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 > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
