Booting another ELF from RTEMS

[Jonathan Brandmeyer]

Thanks for sharing your experience.

On Tue, Apr 16, 2019 at 9:54 PM Chris Johns <chrisj at rtems.org> wrote:

> 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.

Totally agree.  The FSBL is definitely considered part of our ROM.

> > - 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`?

Yes, that makes good sense.  I should've thought of that already, so
thanks for the reminder :)

> - 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.

Yeah, that's a possibility.  Whether we can get the image validation
and selection logic done in the scripting system or in their
application layer, Its yet another programming environment to support.
The most attractive part of chain-loading from a ROM RTEMS to a
field-programmable RTEMS is the uniformity of the development
environment.

Another option is to use RTEMS dlopen(), and restrict the scope of our
field updates.  A minimal ROM image would have enough logic in the
kernel to load the filesystem and enumerate the available application
packages, both the safe-mode backup image and reprogrammable images,
and dlopen() the appropriate one based on our update policy.  This is
probably the highest-risk / lowest-development-cost path we could
take, where the risk is increased by locking us into a particular
kernel image.  Its made worse by the fact that we're using RTEMS v5 as
our base on the assumption that a stable release will come out before
our product launch.  If that release doesn't happen, then the initial
units will be shipping off of some unreleased SHA instead of a fully
stabilized release, or we can backport our application to 4.11.3.
That isn't particularly attractive either, since v5 has some fixes
that v4.11 doesn't have, but maybe we can backport those as well.

My actionable question for you is: How likely is a stable v5 series
release in the next 6 months, where "likely" is measured by things
like "we are making it a priority" and/or "we have funding to do so"?
Not trying to make any demands of your team; I'm just trying to make
an informed decision.

Thanks,
-- 
Jonathan Brandmeyer