Workflow RTEMS on Zynq Zedboard

[Jan Sommer]

Am 2016-03-23 14:19, schrieb Badr El Hiouel:
> Thank you Chris and Jan for your clarifications, its very helpful.
> 
> Jan, I found the lab you talked about. I had the zedboard version and I 
> did
> the same steps but it did'nt work.
> 
> What I did is to create a hello application + zynq design (from the 
> lab) +
> generate the FSBL + Xilinx bsp standalone  and then in the option of 
> create
> zynq boot image I changed the hello.elf by ticker.elf. Then , I did 
> program
> flash and it went fine. but when using Tera Ter ( terminal ) with
> 115200/8/n/1/n , I have nothing shown in the window ( The LED Done is 
> blue
> and I clicked on BTN7) so I guess that what I did is not working.

I just checked it with my setup. In contrast to Figure 1 of tutorial 4 I 
didn't use the "Create New" option, but "Use existing" and chose the 
standalone_bsp_0.
I followed through with the flash programming and the program ran  after 
I pressed the reset button.


> Do you have a solution to how to use an elf file or how to port Rtems 
> demos to the
> board in general ?
> 

Well, for us RTEMS on the Zync doesn't have high priority atm, so I only 
spend some time here or there fiddling with it.
Chris made some good points I wasn't aware of (I will have to do some 
more research to understand everything) and I will see how that applies 
to us when I find the time, but there's nothing concrete from my side.

Cheers,

    Jan

> There is this xilinx
> ​tutorial
> http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_4/SDK_Doc/SDK_concepts/concept_faq_debugelfusingsdkwithoutproject.html
> ​
> But when doing this I can
> ​'​
> t create a boot image.
> 
> ​Thank you for your help. ​
> 
> *Badr *
> 
> 2016-03-23 4:40 GMT+01:00 Chris Johns <chrisj at rtems.org>:
> 
>> On 22/03/2016 21:16, Jan Sommer wrote:
>> 
>>> Then you have the bsp in the Xilinx context. The Zync CPU consists of 
>>> an
>>> ARM-CPU and an FPGA. In order to run any application on the CPU you 
>>> also
>>> have to configure the FPGA, which you do with the bsp and the FSBL 
>>> from
>>> the Xilinx-toolchain.
>>> I don't know too much about that configuration so far. I simply 
>>> followed
>>> the tutorial where the FPGA is mainly responsible to connect the CPU 
>>> to
>>> the RAM.
>>> 
>> 
>> The Xilinx BSP code is installed as part of the SDK and is available 
>> for
>> you to use and review. Check the license as it does not allow you to 
>> make
>> that code public.
>> 
>> When you create an SDK "application" various parts of the SDK BSP code 
>> is
>> copied into your work area and built. What is copied depends on the 
>> type of
>> application you create. There is a nasty gota here. If you need to 
>> edit the
>> BSP code, for example to change the default PHY mode for the GigE MAC 
>> to
>> support an STP interface the SDK notices and kindly refreshes the copy 
>> from
>> the original without saying a word about it. You can argue this is all 
>> ok
>> except the Xilinx SDK BSP has bugs, for example the BSP ethernet 
>> driver for
>> the Zynq cannot operate close to gigbit speeds. Do you need to update 
>> the
>> original code in the SDK? How do you configuration manage this with a 
>> team
>> of users? The SDK does make nice sample app videos.
>> 
>> Another simple test is to compile some of the Xilinx BSP code with the
>> RTEMS compiler which is a newer version of gcc and watch the warnings.
>> 
>> For me the important issue with the Xilinx hardware tools and SDK is 
>> their
>> close integration. The hardware designer tools and the SDK versions 
>> need to
>> match. If your FGPA design team need a new version to resolve an issue 
>> the
>> SDK needs to upgrade. What if the newer SDK has an issue? You are 
>> wedged.
>> This interaction works both directions.
>> 
>> My approach to the Zynq is to keep the hardware design work-flow for 
>> the
>> FPGA team completely detached from the software work-flow. This means
>> software and hardware can each control and manage the versions of the 
>> tools
>> they need to complete the work they need to do.
>> 
>> Further to this I suggest taking a sample of the FSBL code from the 
>> SDK
>> and creating a separate custom project and lock it down. Then build 
>> this
>> code with the RTEMS compiler. The means the project only need to
>> configuration manage the hardware design tools and the RTEMS tools. 
>> The
>> only wrinkle in this is `bootgen` from the SDK and I hope one day an 
>> open
>> source version appears.
>> 
>> There is a side effect of this and that is loading the bitfile which 
>> the
>> SDK magically embeds in the FSBL. I have RTEMS load the bitfile from 
>> SD or
>> flash. I consider the Xilinx documented single image with the FSBL, 
>> bitfile
>> and the application as a configuration nightmare and a bricking risk. 
>> IMO
>> even the golden images that can be supported by the Zynq's BootROM 
>> code can
>> have issues. I use [1] to load RTEMS from a JFFS2 from my hacked FSBL.
>> 
>> Finally an unrelated note, there is hidden requirement for the FSBL
>> structure, coding etc. A Zynq as a PCI Express device needs to load 
>> the
>> bitfile and boot in under 100msecs or it misses the PCI express host 
>> probes
>> and it not seen.
>> 
>> Chris
>> 
>> [1] https://ftp.rtems.org/pub/rtems/people/chrisj/jffs2-boot/
>>