Basic Workflow With Zynq BSPs?
Chris Johns
chrisj at rtems.org
Thu Apr 23 00:59:19 UTC 2015
On 23/04/2015 3:23 am, Jonathan Brandmeyer wrote:
> I've managed to get the demo applications to run on the microzed with
> the following workflow:
>
> -Build the RTEMS xilinx_zynq_zedboard BSP as normal
> -Build a basic FPGA bitstream, Xilinx BSP, and first-stage bootloader
> (FSBL) as described in the first few tutorials for the microzed. The
> FSBL references the BSP, which in turn references the hardware-specific
> configuration settings provided by Xilinx' tools. Xilinx BSP is
> actually a complete freestanding C environment + hardware setup code and
> drivers.
> - Package a BOOT.BIN file composed of the FSBL, fpga bitstream, and an
> RTEMS demo program. BUT, rename the demo application to have the suffix
> .elf instead of .exe so that the Xilinx "bootgen" utility correctly
> identifies the entry point of the RTEMS ELF file.
>
This is inline with the Xilinx work flow. I do not follow this path for
a number of reasons mostly related to the configuration control the
various items, board bricking issues, encryption, and dependence on
Xilinx tools and hosts.
The reasons are:
1. A single binary image means retesting of each part. Dependence of
software on the output of the Xilinx hardware tool means any new bitfile
generates a new new ps7_init.[ch] which may or may not have changed so
this means a new FSBL and this flows down the chain of binaries.
2. A single BOOT.BIN image means an upgrade can brick the board. If on
an SD card any update could corrupt the DOSFS so to avoid this you need
a multi-partition configuration and BOOT.BIN is static and it loads your
executable from a different partition you can update or fall back to a
known "factory" image if that fails. On a QSPI flash boot you do not
want to change the BOOT.BIN with the FSBL because a power fail bricks
the board.
3. The FSBL needs to be encrypted to enter secure mode and this means
the key to encrypt needs to be available to the software team. The issue
is the PL bitfile and the FSBL use the same key so every software build
needs to know the key used to encrypt the bitfile and some places are
very protective of the bitfile key.
4. The Zynq projects I work on have no software dependence to Xilinx's
SDK other than bootgen to create BOOT.BIN. All code on the Zynq is built
with RTEMS tools including the FSBL. This means the projects can control
whole the process and are not subject to changes in SDK.
Further points to note...
The relationship between the hardware tools and the SDK has in the past
been fluid. Xilinx have considered this an internal set of interfaces
they can change. The Zynq has changed this and they now recognise the
need to better to control these interfaces. We have seen large changes
in the names of defines and variables in the ps7_init.h and parameter
files breaking code dependent on them. This has been discussed with
Xilinx and they are aware and working on it. We welcome this effort from
them.
Bootgen is a closed source and limited to Windows and Linux. This is
unfortunate for users like me who do not support either. I have to have
a VM with Windows and 40G of stuff installed to run a single executable.
The bootgen tool is a fairly basic ELF to binary format packager with
(IMO) a few too many options but it does contain some logic to encrypt
the FSBL and other data and the exact byte sequence to get the PL to
pass this data through the AES/HMAC hardware is under NDA and I refuse
to accept the NDA documentation because I could not create an open
source version if I figure out the magic.
> This seems to work OK for the RTEMS demo programs. But, some notes in
> the RTEMS BSP's history and source code suggest that this may be
> insufficient. In particular, there are notes referring to the need for
> the application to specify the system clock frequency, UART freq, and/or
> MMU tables, presumably based on the exported hardware definitions and/or
> Xilinx BSP for the processor.
These are managed using weak symbols. If you define the function etc in
your application the linker will select it over the default in RTEMS.
This lets you provide a suitable clock freq and MMU. Grep the BSP for weak.
>
> My questions are:
>
> - Does the Xilinx BSP's C environment conflict with the RTEMS C
> environment? A Xilinx BSP's libxil.a is compiled by default with a
> Xilinx-provided toolchain (arm-xilinx-eabi-tool), while RTEMS is built
> with an rtems-specific toolchain. Is it sufficient to simply rebuild
> the Xilinx BSP with the RTEMS toolchain instead?
You cannot mix these. You must import into your application Xilinx BSP
code and build with the RTEMS tools and the same options RTEMS is built
with. Further to this we cannot openly share this code because of the
license. Privately sharing could be possible if both parties have
installed the SDK and meet the license but I am not 100% sure plus this
just creates a black market for this code. I have been working with
Xilinx for over 18 months on this topic and we currently seem to have
stalled for various reasons.
> - To what extent can you perform custom setup tasks that rely on the
> Xilinx BSP by modifying their FSBL?
I currently use a local boot loader that started out as a version of the
FSBL but is now a long way from it. I only use the RTEMS tools and
depend on as little of the Xilinx BSP code as I can. I know SLAC also
have invested in a custom version of the FSBL to suite their needs.
Xilinx do support uboot however this is GPLv3 and I will not use it for
this reason. The MicroMonitor (umon) project and Ed Sutter the umon
project lead have recently joined to the RTEMS project [1]. Long term I
hope we can use umon to build an open source suitability licensed boot
loader for the Zynq so we can avoid this costly process of everyone
repeating the need to create a custom boot loader.
[1] https://lists.rtems.org/mailman/listinfo/umon-devel
> Conversely, what Xilinx
> BSP-specific tasks must be performed by the RTEMS application instead?
> The RTEMS BSP seems to be sufficient to run simple applications like
> 'ticker' without pulling in the Xilinx BSP at all.
This depends on your system level design. Projects I work on have
stripped the boot loader to just enough logic to manage factory fall
back type functionality, runtime error recovery, and loading a binary
RTEMS kernel based on a text configuration file. Drivers like the clock
and console are in the BSP, the network driver is supported in the RTEMS
libbsd project which means the new network stack and support for
checksum off loading, and I2C drivers are in the kernel. SPI is not
supported in the kernel (I am using QSPI flash) but might be in libbsd.
We also load bitfiles into the PL once RTEMS is running from a QSPI
based JFFS file system so we do not need software to depend on specific
bitfiles.
>
> - Is it reasonable to maintain the Xilinx FSBL + RTEMS application
> separation?
Yes it is possible but you need to manage the whole process and
dependence on Xilinx's SDK and what that means in the future.
I choose to follow a path separation so software can follow its own
path. A new SDK release from Xilinx does not effect any code I have
running on a Zynq.
> It seems to work OK with their tools that way. Or does it
> seem better in practice to integrate the FSBL's functionality into an
> RTEMS-hosted application?
As I said this is a system design and management issue as much as anything.
Chris
More information about the users
mailing list