[ECOS] RedBoot porting

[Grant Edwards <grante@visi.com>]

I've decided to try to get RedBoot running on our custom
platform to see if it would make a suitable basis for a boot
loader.  After reading through the RedBoot porting docs, I'm a
bit confused.

Is the virtual vector table used to make calls in both
directions (user-app calling ROM and ROM calling user-app)?

Once an eCos app is running, are there one or two virtual
vector tables?

If I do not want RedBoot to provide any services to user
applications, do I still need to implement virtual vector
support in my HAL?  [Having application code depend on services
available in the boot loader is way too high-risk, since there
isn't going to be any way to upgrade the boot loader in the
field.]

There are several statements in hal-calling-if.html from which
I infer that eCos is headed towards dependence on RedBoot (or a
similar ROM monitor) for various services and that in the
future eCos apps will not be stand-alone as they are now:

  "The use of this service is controlled by the option
   CYGSEM_HAL_VIRTUAL_VECTOR_DIAG which is disabled per default
   on most older platforms (thus preserving backwards
   compatibility with older stubs). On newer ports, this option
   should always be set."

  "Note: On old ports the hardwired HAL_DIAG_INIT,
   HAL_DIAG_WRITE_CHAR and HAL_DIAG_READ_CHAR implementations
   will also contain code to O-packetize the output for GDB.
   This should not be adopted for new ports! On new ports the
   ROM monitor is guaranteed to provide the necessary mangling
   via the vector table."

I don't know that I can guarantee that a ROM monitor will be
available for use by my eCos applications. If eCos must be
guaranteed a ROM monitor, this could be a serious problem for
me.

-- 
Grant Edwards
grante@visi.com