Workflow RTEMS on Zynq Zedboard

[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. Do you
have a solution to how to use an elf file or how to port Rtems demos to the
board in general ?

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20160323/b06f1081/attachment-0002.html>