From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Edwards To: Jesper Skov Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] #error " no RESET_ENTRY" ?? Date: Wed, 10 Jan 2001 07:32:00 -0000 Message-id: <20010110093636.A23362@visi.com> References: <20010109165157.A16129@visi.com> X-SW-Source: 2001-01/msg00153.html 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