RTEMS with post-boot code.
joel at oarcorp.com
Wed Oct 29 16:08:17 UTC 1997
On Wed, 29 Oct 1997, Eric Norum wrote:
> I'm with Robin on this one. Here are the problems I see with the
> jump-table-lookup way of handling things:
> 1) Where do you draw the line at what goes into the table? The
> RTEMS entry points? The libc entry points? The networking entry
> points? The libio entry points?
This approach has not been used recently (AFAIK) with RTEMS. The just
table is provided for RTEMS but I don't know that anyone uses it or that
it has been tested recently. It is painful to use this apprach sometimes.
You still need RTEMS constants and you have to have a layer which maps
every call from C to the jump entry point format.
> 2) Everything gets pulled into the executable (since it is
> impossible to know a-priori which routines will be called).
Well it is in the ROM. If you have ROM space, this is not that bad a
disadvantage. Especially if you avoid the jump table approach and just do
a link against the addresses in ROM.
> 3) There have to be two ways of calling every routine -- directly
> and through the jump-table unless you want to add the jump table
> lookup overhead to every program.
This is a problem. A large maintenance problem more than likely because
this layer would vary form port to port.
> I find that the static-executable, coupled with a BOOTP PROM or BDM
> interface to load that executable, is completely convenient.
> The argument now raised may be, ``but it would be so much quicker to
> test new code''. My counter argument is that, ``RTEMS has no memory
> protection, so if your test code has a bug, in all likelihood you're
> going to trash some important part of RTEMS and have to reload
> anyhow -- or you'll probably *want* to reload RTEMS anyhow since
> you're never quite sure that your new code didn't tromp on something
> important''. Even if all RTEMS is in ROM you still have to worry
> about the integrity of the associated data structures.
That is an issue.
I know of one project which utilized memory management to protect the
stacks from overflow. They submitted the stack allocator extensions. I do
not think they ended protected the workspace although they did talk about
it. You would have to have RTEMS at a different protection level than
application code to protect anything of use.
But if I understand right, the original idea was just to put as much in
ROM as possible to minimize downloads. If something gets trashed, a reset
will bring a stable copy out of ROM and then you can try to debug it
again. I don't think the original intent was necessarily concerned with
being able to switch applicatins without an intervening reset -- although
I agree it would be a good feature. I think it would personally distract
from my ability to debug. Who would know for sure what dmage had been
done by a previous executable.
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
More information about the users