Xilinx Microblaze copyrights question

Joel Sherrill joel.sherrill at oarcorp.com
Mon Feb 2 14:36:07 UTC 2015


On 2/2/2015 7:57 AM, Hesham Moustafa wrote:
> OK for now I have a Hello World port working, using a very little code
> for UART_RS232 IP (two functions send/receive and UART register
> definitions) which I believe there is a similar code for it on RTEMS
> somewhere. 

If it is really an NS16550, then you can use the libchip driver. Various
BSPs
use libchip drivers. The pc386 is one. The sim68000 is the simplest example
but it uses an mc68681. It is good for the configuration. Assuming it is
memory mapped, you should be able to use standard accessor methods
and just fill in the table.

> Should I (or anyone of you) create a thread on Xilinx
> forums to discuss about that issue?
Chris should answer this since he is leading the discussions with Xilinx
we have been having.
> On Sun, Feb 1, 2015 at 11:20 PM, Chris Johns <chrisj at rtems.org> wrote:
>> On 31/01/2015 8:32 am, Peter Dufault wrote:
>>> The wording is very bizarre:
>>>
>>> "Except as otherwise provided in a valid license issued to you by Xilinx,
>>> and to the maximum extent permitted by applicable law: (1) THESE MATERIALS
>>> ARE MADE AVAILABLE "AS IS" AND WITH ALL FAULTS, AND XILINX HEREBY DISCLAIMS
>>> ALL WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY..."
>>>
>>> If there is no other valid license the source is made available "AS IS".
>>> But what does "made available" mean?  How can it be used?  They then go on
>>> to restrict their liability, making it plain it is expected that the code
>>> will be used without the "other valid license".  To further add to that
>>> expectation they specifically mention situations where it can't be used
>>> under any circumstances.
>>>
>>> I wouldn't want to hazard a guess as to what this mess legally means.
>>> This is a "I'll have my cake and eat it too, please" copyright.  I'm sure an
>>> aggressive lawyer would have a field day with it.
>>>
>>> Yes, the code should be avoided if there isn't another "valid license"
>>> somewhere that clarifies things.  Has part of the RTEMS discussion with
>>> Xilinx specifically asking for an appropriate "valid license" and providing
>>> a suggested one?  That's the tack I'd take.
>>>
>> Here is the long version.
>>
>> In my view the key issue is the confidential statement and the fact you have
>> to have downloaded an SDK to obtain the code and the SDK is covered by a EUL
>> you must agree too.
>>
>> My understanding is Xilinx and their lawyers are concerned about their code
>> being used on devices that are not make by Xilinx which is an understandable
>> position to take given the investment they have made. Code placed into RTEMS
>> is free for people to take a use and the RTEMS project cannot determine if
>> the code is only being used on Xilinx devices therefore we are never sure we
>> comply.
>>
>> My personal view is the code we are wishing to leverage and use has low IP
>> value and is often just register definitions or device set up described in
>> publicly available documentation. The benefits to projects like ours is the
>> ability to bring up a new device quickly with vendor tested code. Limiting
>> the access to this code raises the cost of entry for new devices and in this
>> specific case it is hurting the Microblaze. We cannot use the Linux version
>> of the code because it is GPL.
>>
>> The Microblaze and Zynq are a little more complex due to the programmable
>> logic side of things. A complex projects using these devices will need to
>> integrate with the programmable logic tools from Xilinx, eg Vivado. The flow
>> on effect here is these tools are designed to match up with the Xilinx SDK.
>> If we cannot use or access this code we run the risk of breaking when the
>> tools are upgraded. Xilinx have in the past had a loose coupling between the
>> hardware tools and the SDK and have been able to move and change things as
>> they needed too. Xilinx understand they need to find a way to define a clear
>> and solid interface between the hardware tools and the SDK. My hope is the
>> RTEMS project can work with Xilinx in this area and be a part of this work.
>>
>> There is real demand for RTEMS on these Xilinx devices which is really good
>> news so we need to keep moving and this means we need to develop clean code
>> for now.
>>
>> Chris

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985




More information about the devel mailing list