Workflow RTEMS on Zynq Zedboard

[Badr El Hiouel]

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 ​

________

*Badr EL HIOUEL*
Mail : elh.badr at gmail.com


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

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