Workflow RTEMS on Zynq Zedboard
chrisj at rtems.org
Wed Mar 23 03:40:33 UTC 2016
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  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.
More information about the users