From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Skov To: Grant Edwards Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] #error " no RESET_ENTRY" ?? Date: Wed, 10 Jan 2001 00:11:00 -0000 Message-id: References: <20010109165157.A16129@visi.com> X-SW-Source: 2001-01/msg00147.html Grant, I'm working on a complete overhaul of this magic. Basic sematics are the same, of course, but there'll be some changes in the way all this gets initialized, giving the user (developer) more control. Unfortunately the work is on the backburner for a while as I address something else. But within next week I hope to commit my changes. >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. FWIW I will rename those HAL_STUB_PLATFORM_RESET* macros to HAL_PLATFORM_RESET* since it's a feature that should not be restricted to stub configurations. The macros should also be moved to some other header file, but that's not going to happen just now. >Does CYGPRI_HAL_IMPLEMENTS_IF_SERVICES imply >CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS? No. >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. 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). >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? It's probably OK. But communication vectors might not get initialized since you disable CYGSEM_HAL_VIRTUAL_VECTOR_DIAG. I'm not sure. It'd work in the new (still-vaporware) world. Jesper