Workflow RTEMS on Zynq Zedboard

[Chris Johns]

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/