[U-Boot-Users] Re: License issues with Xilinx provided files

[U-Boot-Users] Re: License issues with Xilinx provided files

[Keith J Outwater]

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
> 
> 

[U-Boot-Users] Re: License issues with Xilinx provided files

[Peter Ryser]

>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

[U-Boot-Users] Re: License issues with Xilinx provided files

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at 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

[U-Boot-Users] Re: License issues with Xilinx provided files

[Keith J Outwater]

wd at 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 at 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

[U-Boot-Users] Re: License issues with Xilinx provided files

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Open the pod bay doors, HAL."                    - Dave Bowman, 2001