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