RTEMS with post-boot code.

[Joel Sherrill]

On Thu, 30 Oct 1997, Robin Kirkham wrote:

> 
> 
> > On Wed, 29 Oct 1997, Robin Kirkham wrote:
> > 
> > > On the whole, having used vxWorks for many years, I find the RTEMS way of
> > > bundling the application with whatever parts of an OS it requires into a
> > > single executable unit is in many ways cleaner and easier. Maybe it's not
> > > so good for repeated compile/test/debug cycles, but it is much better for
> > > managing systems in the field. (It is also the traditional embedded systems
> > > approach).
> > 
> > It is easier but forces you to relink the entire application and download
> > it.
> 
> It gives me time to think (seriously!). But I am also improving my downloading
> tools...

I can relate.   I have worked on projects where download time was on the
order of 15 minutes.  On those projects, we relied heavily on the RTEMS
unix port and CPU simulators in conjunction with applicaiton specific
simulators to provide device IO feedback.  These worked well together and
saved an ernormous amount of time.

I like to think that this type of application simulation test environment
is becoming a strong part of our application development consulting. :)

> > GNU ld has some options to do something like "use address -- not
> > object code from this file".  I think using that, you could reuse the code
> > for RTEMS (and maybe other things like C library routines) which are
> > linked into  the monitor.
> 
> I think this may be possible but I don't think it is a lot of help. If I
> understand you correctly, it amounts to doing the relocation fixups on a
> to-be-later-loaded module, using the symbol values of an already-linked
> executable RTEMS with monitor. This is OK until the base executable gets
> changed, then all the loadable modules need to be fixed-up again to suit it.
> 
> You would also have to contrive things so that just about every RTEMS and
> C library function was linked into the base executable, just in case a
> loadable wants it.

You would not necessarily have to put much of the C library in your ROM.
It would reduce the benefits but ...

If you change RTEMS or the C library, then you do have to replace the ROM
but at least that happens less often than downloading tests.  Think what
happens -- you would download one "base image" and then run all 80 RTEMS
tests.  It has already paid for itself and you have not even begun
application testing yet.  If the applciation turns up a BSP or driver bug,
then you do have to repeat.

> > The key problem you will have to face is that RTEMS, the BSP, all device
> > drivers, etc will be in the ROM monitor and already initialized when your
> > application code is downloaded.  So it will have to be configured to
> > include your application requirements.  Plus you have to know what to
> > invoke in the downloaded image to do its application initialization.
> 
> This is an issue in RTEMS, which by design I think favours off-line
> configuration and static linking. In vxWorks all kernel and user objects are
> on the heap, and there are no initial or buil-in limits to the number of any
> of them. This makes the dynamic linking easier. You can invoke any function
> (by name to its command shell) to start the application.

A person on this list has started to investigate some of these dynamic
allocation issues.  If he wants to comment publicly on his ideas, then I
will leave it to him.  Let me just state that no effort has been made to
dynamically install/remove device drivers.  We would be happy to see some
effort in this area.

--joel