This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
#error " no RESET_ENTRY" ??
- To: ecos-discuss at sources dot redhat dot com
- Subject: [ECOS] #error " no RESET_ENTRY" ??
- From: Grant Edwards <grante at visi dot com>
- Date: Tue, 9 Jan 2001 16:51:57 -0600
I'm trying to impliment virtual vector support in my HAL, but I
can't get it to build. I am getting the following error
/opt/ecos/ecos-cvs/ecos/packages/hal/common/current/src/hal_if.c:143: #error " no RESET_ENTRY"
The problem seems to be that my plf_stubs.h file only defines a
reset entry point if CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS is
defined (because that's what the edb7xxx HAL does it).
However, hal_if.c demands that a reset entry point be defined
if CYGPRI_HAL_IMPLEMENTS_IF_SERVICES is defined.
Does CYGPRI_HAL_IMPLEMENTS_IF_SERVICES imply
CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS?
At this point what I'm attempting is
* I don't want GDB stubs in my eCos application.
* I want to fill in the virtual vector table.
* I don't want to do diagnostic I/O via the virtial vector table.
My current configuration is
#undef CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
#define CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT
#define CYGPRI_HAL_IMPLEMENTS_IF_SERVICES
#undef CYGSEM_HAL_VIRTUAL_VECTOR_DIAG
Which means (I think)
Don't include GDB stubs in eCos.
HAL does support virtual vector table.
HAL fills in virtual vector table.
HAL does not call diagnostic I/O routines via virtual vector table.
Is that an illegal configuration?
ecosconfig seems happy...
--
Grant Edwards
grante@visi.com