On 9/14/06, John Bonesio <[EMAIL PROTECTED]> wrote: <snip>
> << 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? U-Boot has the same issues as Linux - Xilinx drivers don't match the coding style - The license boilerplate is not GPL compatible - The IP can change rapidly, so do the drivers belong in the u-boot mainline tree? - Current code is not set up to support multiple drivers in the code base. (I know it's possible, but it's not being done at the moment) (and see my comments on Linux below) > > << 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. Simply generating code and inserting it into the kernel tree itself is okay on the surface, but the current scheme is distasteful. I would make the following recommendations to make it more palatable: - Keep generated code in a single sub-directory. Don't scatter it all over the kernel source. ie. generate all code into /xilinx-bsp instead of bits into /arch/ppc and /drivers. - Don't overwrite *anything* that from the mainline tree. (Hence the /xilinx-bsp suggestion above). If you need to modify files in the tree, like in /arch/ppc, then submit patches for the needed changes and *don't* try to modify them from within EDK. - If you want something in mainline; make sure it can coexist with drivers for other versions of the same IP, or make it support multiple versions. - Corollary to the above two points; once a Xilinx provided patch/driver is accepted into mainline, treat it like the rest of mainline and don't let EDK overwrite it. - Regardless of Xilinx's intentions, 3rd party drivers will probably be written and accepted into mainline. Be prepared to coexist with them also. - Stop requiring xparameters.h to be mangled! Generate it correctly the first time! I think I'll scream if I get handed another xparams file from an FPGA engineer which was generated as a no-os target. The Linux redefines are useful, why aren't they in xparameters.h for all targets? Unfortunately, generating the drivers ends up being a one way street. If the code is not in mainline, it will not keep up with changes to the kernel API, and it is more difficult to get bug fixes into the driver code from 3rd parties (ie. users need to wait for the next EDK release cycle before the changes appear in generated code). This is probably the major reason why writing new 3rd party drivers for inclusion in mainline is attractive to me. > > Having the ability to make rapid hardware changes, I think, is a bit > different from what most folks are used to. Different, but manageable. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
