This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RedBoot porting
- To: ecos-discuss at sources dot redhat dot com
- Subject: [ECOS] RedBoot porting
- From: Grant Edwards <grante at visi dot com>
- Date: Fri, 5 Jan 2001 11:52:21 -0600
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