[U-Boot-Users] Re: License issues with Xilinx provided files
Peter Ryser peter.ryser@xilinx.com wrote on 05/08/2006 06:21:06 PM:
Keith,
thanks for the follow-up. I would have missed Wolfgang's email. I think we should take the discussion back to the mailing list.
The drivers should be in a common location and the BSP generation
mechanism should be used to overwrite these files for a given hardware design. That will always guarantee that the drivers matching the IP will be used.
Won't that mean that for any given design that uses a Virtex2/ppc405, the public U-Boot source tree will never be guaranteed correct? It sounds like the user would be required to maintain a locally modified U-Boot source tree for each design.
That sounds like a clumsy solution.
Could we just set up a common driver library and provide a mechanism to allow a particular board to configure the library for the particular IP versions used in the hardware design? Then the IP versions are specified in the board configuration file and you're done.
Note that no matter what approach is used, there is still the licensing issue. I cannot, for example, submit certain Xilinx driver files for inclusion into U-Boot that I need to support my board.
Are you planning to add a complete set of drivers to U-Boot?
Cheers,
- Peter
Won't that mean that for any given design that uses a Virtex2/ppc405, the public U-Boot source tree will never be guaranteed correct?
Yes, it will be correct because the updates to the U-Boot source tree are aligned with reference designs for a set of boards.
It sounds like the user would be required to maintain a locally modified U-Boot source tree for each design.
IMHO, that's good design practice anyway. For every hardware project you have a number of software projects that are aligned to the hardware features. At any given time you want to be able to go back to that source tree if an issue comes up.
That sounds like a clumsy solution.
Configurable hardware is different from static hardware. On one hand it is a challenge while on the other hand it has lots of benefits. It's definitely not clumsy.
Could we just set up a common driver library and provide a mechanism to allow a particular board to configure the library for the particular IP versions used in the hardware design? Then the IP versions are specified in the board configuration file and you're done.
IMHO, having a driver library would make things much more complicated. Generating the required drivers for a given hardware configuration is straight forward.
Note that no matter what approach is used, there is still the licensing issue. I cannot, for example, submit certain Xilinx driver files for inclusion into U-Boot that I need to support my board.
That's correct. You can not change the license of drivers shipping in EDK to GPL. However, if you let me know what drivers you need to have licensed under GPL I can get this done.
Are you planning to add a complete set of drivers to U-Boot?
No, drivers will be added on a "as needed" basis. But in the first place stuff needs to make it into the source tree that we have submitted in the past before we can add new things.
- Peter
In message 4462411F.4080200@xilinx.com you wrote:
It sounds like the user would be required to maintain a locally modified
^^^^^^^^^^^^^^^^
U-Boot source tree for each design.
IMHO, that's good design practice anyway. For every hardware project you have a number of software projects that are aligned to the hardware features. At any given time you want to be able to go back to that source tree if an issue comes up.
But why in a *locally modified* tree? IMO the public source tree should be used.
IMHO, having a driver library would make things much more complicated. Generating the required drivers for a given hardware configuration is straight forward.
Is the complexity of such a driver library (which seems to be a good thing to have IMHO) an inherent issue that cannot be resolved, or is it a result of the current design that, assuming we had enough resources, could be resolved in a technically clean way?
That's correct. You can not change the license of drivers shipping in EDK to GPL. However, if you let me know what drivers you need to have licensed under GPL I can get this done.
Are you planning to add a complete set of drivers to U-Boot?
No, drivers will be added on a "as needed" basis. But in the first place stuff needs to make it into the source tree that we have submitted in the past before we can add new things.
I'll be working on this ASAP.
Best regards,
Wolfgang Denk
wd@denx.de wrote on 05/10/2006 03:58:18 PM:
In message 4462411F.4080200@xilinx.com you wrote:
It sounds like the user would be required to maintain a locally
modified
^^^^^^^^^^^^^^^^
U-Boot source tree for each design.
IMHO, that's good design practice anyway. For every hardware project
you
have a number of software projects that are aligned to the hardware features. At any given time you want to be able to go back to that source tree if an issue comes up.
But why in a *locally modified* tree? IMO the public source tree should be used.
I agree, especially for commercially available boards. A README.<board> file can be used to document the hardware design (EDK version, IP versions, memory map, etc...) in sufficient detail to re-create the FPGA firmware. If a user wished to overwrite (i.e. locally modify) the U-Boot tree they could, but IMO that should not be *required*. I really like the idea of minimizing local maintenance and configuration control. Let the maintainer do that ;)
IMHO, having a driver library would make things much more complicated.
Generating the required drivers for a given hardware configuration is straight forward.
Yes, EDK will do that and it is fairly painless. That approach also requires that EDK be very aware of the organization and layout of the U-Boot source tree. Setting up a driver library is only complicated once and the U-Boot user generally won't/shouldn't see that complexity.
Is there a compelling benefit associated with having EDK know how to plant driver source code into the U-Boot source tree automatically?
Is the complexity of such a driver library (which seems to be a good thing to have IMHO) an inherent issue that cannot be resolved, or is it a result of the current design that, assuming we had enough resources, could be resolved in a technically clean way?
I think it can be resolved. We simply need to agree on an approach. Wolfgang, in any case that driver library is going to be big if you use the Xilinx drivers as-is. That's what made my two BSPs so large.
That's correct. You can not change the license of drivers shipping in EDK to GPL. However, if you let me know what drivers you need to have licensed under GPL I can get this done.
Are you planning to add a complete set of drivers to U-Boot?
No, drivers will be added on a "as needed" basis. But in the first
place
stuff needs to make it into the source tree that we have submitted in the past before we can add new things.
OK, but I really think that we need to all agree on how the library will be implemented. Let's get a framework in place and then adding new drivers as necessary will be easy. It's the lack of such a framework that drove me to use a local copy of the driver sources in my BSPs in the first place. I'd
like to get the BSPs incorporated in the official source tree, but that can't happen until the library issue gets resolved.
I'll be working on this ASAP.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de : 1. What is the possibility of this being added in the future? In the near future, the probability is close to zero. In the distant future, I'll be dead, and posterity can do whatever they like... :-) - lwall
In message OF5E0E2CF7.16CDEDE0-ON0725717E.00778F50-0725717E.007955AC@mck.us.ray.com you wrote:
I think it can be resolved. We simply need to agree on an approach. Wolfgang, in any case that driver library is going to be big if you use the Xilinx drivers as-is. That's what made my two BSPs so large.
You know what Linux kernel maintainers usually say when they are confronted with similar mess^H^H^H^Hmass of code?
Guess what that means? The "as-is" is probably a no-go.
Best regards,
Wolfgang Denk
participants (3)
-
Keith J Outwater -
Peter Ryser -
Wolfgang Denk