This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: #error " no RESET_ENTRY" ??
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