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

[Jesper Skov <jskov@redhat.com>]

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