[ECOS] #error " no RESET_ENTRY" ??

[ECOS] #error " no RESET_ENTRY" ??

[Grant Edwards]

I'm trying to impliment virtual vector support in my HAL, but I
can't get it to build.  I am getting the following error

/opt/ecos/ecos-cvs/ecos/packages/hal/common/current/src/hal_if.c:143: #error " no RESET_ENTRY"

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).

However, hal_if.c demands that a reset entry point be defined
if CYGPRI_HAL_IMPLEMENTS_IF_SERVICES is defined.

Does CYGPRI_HAL_IMPLEMENTS_IF_SERVICES imply
CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS?

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.

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?

ecosconfig seems happy...

-- 
Grant Edwards
grante@visi.com

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

[Jonathan Larmour]

Grant Edwards wrote:
> 
> I'm trying to impliment virtual vector support in my HAL, but I
> can't get it to build.  I am getting the following error
> 
> /opt/ecos/ecos-cvs/ecos/packages/hal/common/current/src/hal_if.c:143: #error " no RESET_ENTRY"
> 
> 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).

It doesn't in current CVS. Perhaps your CVS tree predates virtual vectors
getting added for the edb7xxx (it was 5th July it got added).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

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

[Grant Edwards]

On Wed, Jan 10, 2001 at 12:36:26AM +0000, Jonathan Larmour wrote:

> > I'm trying to impliment virtual vector support in my HAL, but I
> > can't get it to build.  I am getting the following error
> > 
> > /opt/ecos/ecos-cvs/ecos/packages/hal/common/current/src/hal_if.c:143: #error " no RESET_ENTRY"
> > 
> > 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).
> 
> It doesn't in current CVS. Perhaps your CVS tree predates virtual vectors
> getting added for the edb7xxx (it was 5th July it got added).

Vitrual vector support is in my snapshot of the edb7xxx
HAL (it's the one after which I'm modelling mine. My CVS tree
is from about a month ago.  The last entry in the ChangeLog is

2000-11-25  Jonathan Larmour  <jlarmour@redhat.com>

        * pkgconf/rules.mak (mlt_headers): Rewrite to work under Solaris,
        and without excessive rebuilds.

Once I get things into a stabe, working state I might try
updating.

-- 
Grant Edwards
grante@visi.com

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

[Jonathan Larmour]

Grant Edwards wrote:
> 
> On Wed, Jan 10, 2001 at 12:36:26AM +0000, Jonathan Larmour wrote:
> 
> > > I'm trying to impliment virtual vector support in my HAL, but I
> > > can't get it to build.  I am getting the following error
> > >
> > > /opt/ecos/ecos-cvs/ecos/packages/hal/common/current/src/hal_if.c:143: #error " no RESET_ENTRY"
> > >
> > > 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).
> >
> > It doesn't in current CVS. Perhaps your CVS tree predates virtual vectors
> > getting added for the edb7xxx (it was 5th July it got added).
> 
> Vitrual vector support is in my snapshot of the edb7xxx
> HAL (it's the one after which I'm modelling mine. My CVS tree
> is from about a month ago.  The last entry in the ChangeLog is
> 
> 2000-11-25  Jonathan Larmour  <jlarmour@redhat.com>
[snip]

That is recent enough. Perhaps you misread plf_stub.h? It's definitely
after the #endif:

#endif // ifdef CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS

//----------------------------------------------------------------------------
// Reset.

// Try and force the board into a reset state.  Since this hardware
requires
// a "wakeup" signal, we can't just use a watchdog/reset approach.
externC void reset_platform(void);
#define HAL_STUB_PLATFORM_RESET() reset_platform()

#define HAL_STUB_PLATFORM_RESET_ENTRY 0xe0000000



Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

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

[Grant Edwards]

On Wed, Jan 10, 2001 at 04:40:45PM +0000, Jonathan Larmour wrote:

> That is recent enough. Perhaps you misread plf_stub.h? It's
> definitely after the #endif:

Doh! You're right. I screwed up when I copied stuff out of
plf_stub.h.  I don't know how many times I looked at that.

-- 
Grant Edwards
grante@visi.com

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

[Jesper Skov]

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

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

[Grant Edwards]

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

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

[Jesper Skov]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:


>> 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).

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

Yes, something like that. Except there'll be new options to increase
the configuration granularity.

Jesper