RTEMS with post-boot code.

[Joel Sherrill]

On Wed, 29 Oct 1997, Jacob W Janovetz wrote:

>    This thread sure sparked up some conversation.  I'm currently
> reading through all the notes on this stuff to make a decision.

This has been a nice thread. There are a lot of alternatives. :)

> The original idea was NOT to decrease time downloading.  It was
> to setup a skeletal system (like DOS) which has some useful routines
> (like starting/stopping processes, sending messages, etc) and 
> allows me to send programs from some other source than a ROM
> or a download cable.

I think I am the guilty party of mentioning reduce download time. Sorry.

But at the risk of repeating myself, putting RTEMS + BSP + drivers in the
ROM is not that bad.  Copy it to RAM if speed is critical.  Trim it to
save space if necessary.  [This is probably not as big an issue as we have
made it out to be since RTEMS itself is not all that large.]  Then you
could put your application in a reserved area (like DOS essentially does).

If you wanted, you could do something like this in memory:

vectors
RTEMS RAM image (whatever that turns out to be)
code space
data
bss
heap
workspace

The trick to the DOS boot procedure is that it switches between different
programs which alternatively run either in high or low memory.  I don't
remember the details but it runs one program high or low which loads
another one into the other side of memory and then runs it.  You could do
something similar.

Your ROM loads the non-RTEMS part of the application into the reserved
area for any application.  

This works to download and run 1 applicatton at a time.  At different
times, you could run different applications.

>    This system is not a 'start-it-up-and-let-it-run'
> sort of thing.  It is a flexible system which might be called upon
> to run several different programs at different times.  Just like
> you would never want to store ALL PC programs on a ROM, so I would
> not like to have ALL my programs stored on this ROM.  I want to
> be able to download and unload them from remote (serial/ethernet).
> It is also a potential that others will be developing for this 
> system, thus increasing the number of programs going to it.

If a reset is not acceptable between dowloads, then you will have to
address how to "kick" an application out of memory.  Making sure this is
done cleanly may be a sticky point.

>    The options now are to do what I was talking about (jumptable),
> or finding some other way to start processes while RTEMS is running.

You could run a "monitor" which was based on RTEMS and just have the
application reset RTEMS and start all over.  Alternatively, you would have
to address how to transfer control to it.

>    As an aside, I would not put anything besides OS routines in 
> the jump table.  DOS doesn't have 'printf' included, but it does
> have its disk procedures there...

Sounds reasonable.  But the cost of a jump table approach is the
development of a wrapper for EVERY entry point in RTEMS.  Using the
address-only link option avoids the development of this unportable layer.

--joel
Joel Sherrill                    Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985