Xilinx Microblaze copyrights question

[Hesham Moustafa]

On Mon, Feb 2, 2015 at 2:36 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>
> 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.
I'll make some research to see which one to use. In the meanwhile,
here's the only-used Xilinx code (UART) [1]. I've installed the tools
using RSB, so hello.exe is compiled from there. XMD (Xilinx
Microprocessor Debugger) is used to communicate with the hardware and
open a session for GDB to connect and load/debug the programs.
However, I couldn't use GDB version installed from RSB because there
is a problem between the number of registers sent from XMD and
different versions of GDB expects pre-defined number of registers and
terminates if it differs. This can be solved with a patch.

[1] https://github.com/heshamelmatary/rtems-microblaze/blob/master/c/src/lib/libbsp/microblaze/shared/uart/uart.c

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