Re: [ECOS] #error " no RESET_ENTRY" ??

[Grant Edwards <grante@visi.com>]

On Wed, Jan 10, 2001 at 09:10:57AM +0100, Jesper Skov wrote:

> >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).
> 
> New code should move the reset magic outside of the
> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS. 

Cool. That's what I did to get things to build last night..

> >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.
> 
> I don't want to go through a long explanation here (it'll appear in
> the docs), but the last point will not be possible - or rather, it
> will if you choose to break the abstraction, which is definitely
> possible.

It's only a temporary situation.  I want to continue to use the
old I/O routines while I debug the new ones.

> After I complete my changes, IO will _always_ happen via the virtual
> vector table. Your option will be to claim those vectors in the RAM
> application (thus using serial IO routines in the application) or
> leave them in the ROM monitor's control (using serial IO routines in
> ROM/flash).

IOW, CYGSEM_HAL_VIRTUAL_VECTOR_DIAG will always be true, and
one controls which way things work with CYGPRI_HAL_IMPLEMENTS_IF_SERVICES?

-- 
Grant Edwards
grante@visi.com