RTEMS with post-boot code.

[Erik Ivanenko]

We have done this ( If memory serves ):

	There is a "program manager" thread on the target hardware. 
	There is a "compilation manager" on the host.  A linker
	script is built so that there are holes for the thread's
	data and text and bss sections. ( prog-text, prog-data,        
prog-bss, in consecutive order. 

	Initially, we incrementally link all part of the application except for
the thread we want to run.  This gives us a single lib that contains ALL
of the other libs. 

	The first pass of the compiler links in the thread.  It's size is
determined from parsing a link map. ( We know the names of the sections
we are loading -- they comprise our "hole" ).

	We pass the size to the program manager. ( we use a udp packet).  The
program manager gets a segment of the appropriate size from RTEMS, and
passes the starting address back to the compilation manager.

	The compilation manager changes the linker script to use the address of
this region as the start of the program sections. ( Recall we have put
them in order, prog-text, prog-data and prog-bss. )  We then recompile
and relink.  Afterwards, we extract only that program section from the
resulting image. ( eg. about 112 bytes for hello world ).  we send this
image down to the program manager, to be loaded into the given region. (
again via UDP )

	Of course, the program manager will create and start the thread, with
the start address equal to the beginning of the region.  This process is
crude, as we currently do not download the thread's parameters, although
that is easily extensible.

	The program manager can currently start, stop, suspend, resume, and
delete the thread, all with appropriate meanings.  It works
beautifully!  We have donwloaded several threads, each of which can be
controlled independently. ( of course the task id is returned to the
compilation manager upon successful create/start etc. )

	The beauty of this approach is that since they all have a separate data
section, there is no name-space pollution between threads.	
Also, one can still share data between threads, by defining the data and
locating it within the linker script.

-- 
Erik Ivanenko,
Supervisor, Controls Services
University of Toronto