RTEMS with post-boot code.

[Chris Johns]

Jacob W Janovetz wrote:
> 
> > Jake,
> > going by what has been written so far - it really looks like what you want
> > is RTEMS to be able to execute an image it gets from <insert-your-favorite-
> > storage-place-here>.  When the application is done, it's done.  Another
> > one could be run afterwards - or maybe at the same time.
> > It sounds like you really are looking for a "real" OS - one that can dynamically
> > load images (programs, executables, whatever-you-want-to-call-it) and
> > run them.  All without rebooting/reloading/restarting/resetting.  Like I said,
> > a "real" OS.  For this, correct me if I'm wrong (I'm sure you will), but wouldn't
> > you need an MMU and code to run it?  Not to mention the CPU to go with
> > it.
> 
>    That certainly seems more along the lines of what I'll be
> trying out.  However, is an MMU really required?  I mean, assuming
> memory protection is out the window.
>

An MMU is not needed.

You need to consider other parts of running downloaded applications
before considering the image format or download means.

I agree with the BOOT ROM idea if it is applicable. It is not always
able to be achieved but if it can it makes life easier.

If you assume you can run-time load any application, RTEMS has other
restrictions which come into play. Joel meantioned this earlier. The
configuration table contains the maximum number of objects for a
particular class that can be created. The classes being tasks,
semaphores, what-ever. Until this issue is resolved you will be in a
situation where the applications are constrained by the configuration
in ROM. Once this issue is resolved another appears. RTEMS keeps the
work-space and the libc heap separate. In my systems I take a
continous block of RAM, and split it. If I need more resources or
stack space or what-ever I need to look at this allocation. I really
need the work-space and libc memory to come from the same heap.

BOOT ROMs or restarting RTEMS after a download do not suffer from
these problems. This is why some people using RTEMS operate this way.

Some more input from a system I worked on:

A way I have started download code is to lower the 'Init' task's
priority to the lowest value and block waiting for a start module
request. The module manager queues the module's name, command line
parameters, and entry point then wakes the Init task. The Init task
updates a table of modules loaded and calls the entry point. The
downloaded image has a crto.o and main. This allow bss to be set to 0,
and static constructors to be called. No data section initialise, just
use what came in the image.

I used a.out as the image format. It is easy to parse. The fixup
records come after the image so they do not need to be buffered. The
header contains the entry point. All I did was malloc the memory for
the image, load it and fix it up. The download method was BOOTP/TFTP
with extended option negotiation to use large packets. I was not
concerned with unloading a module. Reboot was considered the best
option. All hardware and devices reset.
 
Having a couple of copies of libc in the system was an issue earily
on. It the end it provided under 30K or so of code, in a 300K image
(10%). This included compiler support functions such __div32 (or
what-ever they are called).


Regards


-- 
 Chris Johns  Networks, Plessey Asia Pacfic Pty. Ltd.
  mailto:ccj at acm.org    mailto:cjohns at plessey.com.au