Booting another ELF from RTEMS

[Chris Johns]

On 17/4/19 2:38 am, Jonathan Brandmeyer wrote:
> I'm interested in using RTEMS as both a featureful bootloader and as
> my application environment.  Is there a straightforward way to use
> RTEMS as a bootloader itself?
> 
> In principle, the following seems like it should work:
> - Provide a bootloader BSP that links RTEMS into an address range that
> is non-overlapping with the application's load range
> - Provide a standard ELF loader from ... somewhere?  Maybe I can
> borrow some of the RTEMS loader logic to do this?  Maybe the Xilinx
> FSBL can be adapted to the purpose?

I recommend the FSBL in flash not be touched unless the hardware is in a
manufacturing environment where it can be recovered by JTAG if the board is bricked.

I also recommend not placing any bitfiles in the FSBL. A lot of the FSBL from
Xilinx is governed by a requirement to boot a PL based ePCI interface. To do
this the FSBL needs to be loaded and run, a bitfile loaded from flash and a PCI
device made ready to enumerate within 100msecs. A bitfile in the FSBL means an
update in the bitfile requires updating the FSBL and that could brick the board.
I have the app and bitfile joined and not the bitfile and FSBL.

The FSBL code from Xilinx has golden images and other features but I do not use
them and it does not know how to load from an YAFFS file system.

> - Jump to the ELF's entry point.

ELF is more complicated to load, a binary image is much easier. Why not just
load a binary image created using `objdump`?

> One of the things I'm uncertain about is whether or not the Zynq BSP's
> startup logic is idempotent.  Is there some startup logic that is not
> safe to run twice?

I do not do this so I do not know what the answer is.

> This is something of an X/Y problem.  The real problem I'm trying to
> solve is to provide a safe-mode ROM software image alongside the
> field-programmable software image, where the ROM is capable of
> receiving updates to the field-programmable image.  When my team
> sketched out the concept, it seemed like the most reliable way to do
> this was for the FSBL to unconditionally load the safe-mode image, and
> that the safe-mode image would chain-load into the appropriate
> application image.  But if RTEMS support for chain-loading in this way
> isn't adequate, then the FSBL will have to conditionally load either
> the safe-mode or application image.

I understand the problem space and what you are attempting to do. In
applications for clients on a Zynq I use a custom FSBL to manage this.

I take the lower section of the QSPI flash and call it the factory image, say 2M
or 4M. I then partition this section starting from 0 with the FSBL area followed
by a table. The table defines the remaining content of the factory image. I then
load into the factory flash area an unsecured compressed bitfile image, the
binary image of the executable, and a compressed tar file containing a default
file system image. The table has an entry to each file and a checksum. The
remainder of the flash is a JFFS2 file system. I use jffs-boot [1] to locate
files in the FSBL.

Note:

- When a factory executable boots there may be no valid FFS so you need to
create it and populate it. This is the reason the bitfile etc are in the table.

- Bitfiles are loaded by RTEMS from the file system or factory table.

> Chain-loading is attractive due to some implementation details of the
> flash layout on our project.  I'd rather not go through the process of
> porting and embedding YAFFS into the FSBL if I can avoid it.

U-boot contains YAFFS [2]. Maybe you can see how it does it or you could chain
from the FSBL to a 2nd stage loader, ie u-boot, and then RTEMS from the YAFFS.

Chris

[1] https://ftp.rtems.org/pub/rtems/people/chrisj/jffs2-boot/
[2] https://github.com/u-boot/u-boot/tree/master/fs/yaffs2