From mboxrd@z Thu Jan  1 00:00:00 1970
From: Grant Edwards <grante@visi.com>
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] #error " no RESET_ENTRY"  ??
Date: Tue, 09 Jan 2001 14:48:00 -0000
Message-id: <20010109165157.A16129@visi.com>
X-SW-Source: 2001-01/msg00136.html

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