Re: xilinx microblaze
On 7/08/2015 9:00 pm, e...@e-bbes.com wrote: Zitat von Hesham ALMatary heshamelmat...@gmail.com: Yes, I run an update of Cygwin (but wasn't really old), and I started it again with --jobs=none. So far, the log file is twice the size of yesterdays, so it seems that it was a problem with the tools. There is an old and what seems to be an on going issue with cygwin and friends like MSYS2 with GNU make. Maybe cygwin also needs to have the jobs default set to off. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: xilinx microblaze
On 7/08/2015 3:01 pm, emanuel stiebler wrote: should it still work, didn't see anything about it for a while on this list, tried yesterday, and the source-builder failed in newlib: Can you please try '--jobs=none' on the RSB command line ? I wonder if this is a GNU make and cgywin dll issue. If your cygwin updated ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: xilinx microblaze
Zitat von Hesham ALMatary heshamelmat...@gmail.com: Hi, FYI, there's some initial port that runs hello world here [1]. I'll most likely work on rebasing and improving it soon, and perhaps revive the discussion of the upstreaming process, if it's of interest. Any chance, you could check it in? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: xilinx microblaze
On Fri, Aug 7, 2015 at 12:07 PM, e...@e-bbes.com wrote: Zitat von Hesham ALMatary heshamelmat...@gmail.com: Hi, FYI, there's some initial port that runs hello world here [1]. I'll most likely work on rebasing and improving it soon, and perhaps revive the discussion of the upstreaming process, if it's of interest. Any chance, you could check it in? I'd like to, but this will be subjected to some Xilinx licence issues, and my schedule. So no (timing) guarantees. -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
xilinx microblaze
Hi all, should it still work, didn't see anything about it for a while on this list, tried yesterday, and the source-builder failed in newlib: microblaze-rtems4.11-ar rc ../libc.a *.o microblaze-rtems4.11-ranlib libc.a rm -rf tmp make[8]: Leaving directory '/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/microblaze-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-pc-cygwin-1/build/microblaze-rtems4.11/m/mh/le/newlib/libc' Makefile:675: recipe for target 'all-recursive' failed make[7]: Leaving directory '/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/microblaze-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-pc-cygwin-1/build/microblaze-rtems4.11/m/mh/le/newlib/libc' make[7]: *** [all-recursive] Error 1 Makefile:627: recipe for target 'all-recursive' failed make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory '/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/microblaze-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-pc-cygwin-1/build/microblaze-rtems4.11/m/mh/le/newlib' make[5]: *** [all] Error 2 Makefile:450: recipe for target 'all' failed make[5]: Leaving directory '/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/microblaze-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-pc-cygwin-1/build/microblaze-rtems4.11/m/mh/le/newlib' make[4]: *** [multi-do] Error 1 Makefile:1188: recipe for target 'multi-do' failed make[4]: Leaving directory '/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/microblaze-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-pc-cygwin-1/build/microblaze-rtems4.11/newlib' make[3]: *** [all-multi] Error 2 Makefile:1104: recipe for target 'all-multi' failed make[3]: Leaving directory '/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/microblaze-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-pc-cygwin-1/build/microblaze-rtems4.11/newlib' make[2]: *** [all] Error 2 Makefile:450: recipe for target 'all' failed make[2]: Leaving directory '/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/microblaze-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-pc-cygwin-1/build/microblaze-rtems4.11/newlib' Makefile:11086: recipe for target 'all-target-newlib' failed make[1]: Leaving directory '/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/microblaze-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-pc-cygwin-1/build' make[1]: *** [all-target-newlib] Error 2 Makefile:866: recipe for target 'all' failed make: *** [all] Error 2 shell cmd failed: sh -ex /cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/microblaze-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-pc-cygwin-1/doit error: building microblaze-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-pc-cygwin-1 See error report: rsb-report-microblaze-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-pc-cygwin-1.txt Build Set: Time 2:12:55.482808 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Xilinx Microblaze copyrights question
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. Should I (or anyone of you) create a thread on Xilinx forums to discuss about that issue? 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Xilinx Microblaze copyrights question
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
Re: Xilinx Microblaze copyrights question
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 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.comOn-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
Re: Xilinx Microblaze copyrights question
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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Xilinx Microblaze copyrights question
These may already be in the tree as part of the Zynq port if the serial port(s) are the same. Please post the full copyright text but check if the same code is already in the tree in support of another of their ports. And congratulations on getting it working this much quickly. :) On January 28, 2015 1:07:38 PM CST, Gedare Bloom ged...@rtems.org wrote: See if there is a license in the distribution that contained the Xilinx files. -Gedare On Wed, Jan 28, 2015 at 1:05 PM, Hesham Moustafa heshamelmat...@gmail.com wrote: Hi, I am currently porting RTEMS to Microblaze based on Joel's work. Hello world hits Init and printf successfully, so I have to write a console driver. Xilinx has UART driver already. The question is can I copy code from Xilinx files to RTEMS? The files have (c) Copyright 2002-2013 Xilinx, Inc. All rights reserved. lines only. P.S. Joel's work quotes files from Xilinx as is. Best, Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Xilinx Microblaze copyrights question
Hi, I am currently porting RTEMS to Microblaze based on Joel's work. Hello world hits Init and printf successfully, so I have to write a console driver. Xilinx has UART driver already. The question is can I copy code from Xilinx files to RTEMS? The files have (c) Copyright 2002-2013 Xilinx, Inc. All rights reserved. lines only. P.S. Joel's work quotes files from Xilinx as is. Best, Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Xilinx Microblaze copyrights question
See if there is a license in the distribution that contained the Xilinx files. -Gedare On Wed, Jan 28, 2015 at 1:05 PM, Hesham Moustafa heshamelmat...@gmail.com wrote: Hi, I am currently porting RTEMS to Microblaze based on Joel's work. Hello world hits Init and printf successfully, so I have to write a console driver. Xilinx has UART driver already. The question is can I copy code from Xilinx files to RTEMS? The files have (c) Copyright 2002-2013 Xilinx, Inc. All rights reserved. lines only. P.S. Joel's work quotes files from Xilinx as is. Best, Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
