This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

#error " no RESET_ENTRY" ??



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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]