Workflow RTEMS on Zynq Zedboard

Badr El Hiouel elh.badr at
Thu Mar 24 09:26:26 UTC 2016

Thank you Jan for the help.

In the Zedboard's lab they did the same thing , they didn't create a new
standalone bsp for the FSBL.
I did again the steps to build testsuites with rtems ( I tought that the
probleme maybe come from my file.elf ) and it still don't work.

Can anybody please tell us how to launch Rtems demos application on the
Zynq ?

​Thank you ​


Mail : elh.badr at

2016-03-23 18:21 GMT+01:00 Jan Sommer <soja-lists at>:

> 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
>>>> 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>:
>> 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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list