On Mon, Feb 2, 2015 at 2:36 PM, Joel Sherrill <joel.sherr...@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 <chr...@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.sherr...@oarcorp.com On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
