[ECOS] Questions about GDB Ctrl-C support.

[ECOS] Questions about GDB Ctrl-C support.

[Grant Edwards]

I'm trying to use gdb via serial connection to RedBoot, and
everything works peachy-keen until the point where eCos enables
interrupts.  I can set break-points, single-step, etc. in the
initialization stuff, but once interrupts are enabled, I get
"spurious interrupt" messages complaining about interrupts from
the serial port that RedBoot is using to talk to gdb.

I don't have virtual vectors enabled in my eCos HAL, since I
don't my HAL to depend on RedBoot.  I don't want diag_printf to
do output with calls to RedBoot.

[I'm using a CVS snapshot from December.]

However, I would like to add GDB ctrl-C support to my HAL, and
I'm not sure what I need to do.  I've looked at 

http://sources.redhat.com/ecos/docs-latest/porting/hal-stubs.html

But, that seems to be describing how it works when you're using
the gdb stubs built into the eCos HAL (I'm using the stubs that
are in RedBoot).  It also keeps refering to a "serial driver,"
and I don't know what driver that would be -- there is no eCos
driver for the debug UART -- eCos doesn't even know it exists.

The hal_arch_default_isr() that I have doesn't do anything
except print a "spurious interrupt message". I've looked at the
HAL files for other platforms in my snapshot, and they seem to
be doing stuff with CygMon.

I presume that I need to modify hal_arch_default_isr() to make
a call to RedBoot via the virtual vector table so that it can
service the UART and check for 0x03.  Or do I add a
hal_default_isr() to my HAL, and figure out how to get that
used in place of hal_arch_default_isr()?

Do more recent copies of some of the HALs have examples of what
I need to do in my default_isr routine?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Questions about GDB Ctrl-C support.

[Jonathan Larmour]

Grant Edwards wrote:
> 
> I'm trying to use gdb via serial connection to RedBoot, and
> everything works peachy-keen until the point where eCos enables
> interrupts.  I can set break-points, single-step, etc. in the
> initialization stuff, but once interrupts are enabled, I get
> "spurious interrupt" messages complaining about interrupts from
> the serial port that RedBoot is using to talk to gdb.
> 
> I don't have virtual vectors enabled in my eCos HAL, since I
> don't my HAL to depend on RedBoot.  I don't want diag_printf to
> do output with calls to RedBoot.
> 
> [I'm using a CVS snapshot from December.]

At that age, the likely fix is to include this bit from the current redboot
main.c:

                // Mask interrupts on all channels
                for (i = 0;  i < CYGNUM_HAL_VIRTUAL_VECTOR_NUM_CHANNELS; 
i++) {
                    CYGACC_CALL_IF_SET_CONSOLE_COMM(i);
                    __chan = CYGACC_CALL_IF_CONSOLE_PROCS();
                    CYGACC_COMM_IF_CONTROL( *__chan, __COMMCTL_IRQ_DISABLE
);
                }

just before control is passed to the stub by a breakpoint. Or perhaps the
better thing is to ensure the serial interrupt is masked in the diag init
code.
 
> However, I would like to add GDB ctrl-C support to my HAL, and
> I'm not sure what I need to do.  I've looked at
> 
> http://sources.redhat.com/ecos/docs-latest/porting/hal-stubs.html
> 
> But, that seems to be describing how it works when you're using
> the gdb stubs built into the eCos HAL (I'm using the stubs that
> are in RedBoot).

If you've got a VV enabled HAL, all you need to ensure is that you don't
take over the vector corresponding to the debug channel RX.

>  It also keeps refering to a "serial driver,"
> and I don't know what driver that would be -- there is no eCos
> driver for the debug UART -- eCos doesn't even know it exists.

The diag driver - whatever driver there is for the debug channel.

> The hal_arch_default_isr() that I have doesn't do anything
> except print a "spurious interrupt message". I've looked at the
> HAL files for other platforms in my snapshot, and they seem to
> be doing stuff with CygMon.

Perhaps the ones you've looked at have been only catering for Cygmon.
 
> I presume that I need to modify hal_arch_default_isr() to make
> a call to RedBoot via the virtual vector table so that it can
> service the UART and check for 0x03.  Or do I add a
> hal_default_isr() to my HAL, and figure out how to get that
> used in place of hal_arch_default_isr()?

You call hal_ctrlc_isr_init which lives in hal_if.c from vectors.S - i.e.
the platform HAL shouldn't be involved at all (except for the
implementation of the underlying driver).

hal_default_isr is meant to come from the hal/common's hal_misc.c. In most
cases hal_arch_default_isr (defined in the arch hal usually) shouldn't do
anything except return 0.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] Questions about GDB Ctrl-C support.

[Grant Edwards]

From grante@visi.com Fri Sep  7 11:41:25 2001
From: Grant Edwards <grante@visi.com>
To: Jonathan Larmour <jlarmour@redhat.com>
Subject: Re: [ECOS] Questions about GDB Ctrl-C support.
References: < 20010906164103.A7868@visi.com > < 3B981276.E710F5FA@redhat.com >
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: < 3B981276.E710F5FA@redhat.com >; from jlarmour@redhat.com on Fri, Sep 07, 2001 at 01:19:02AM +0100
X-Mutt-References: < 3B981276.E710F5FA@redhat.com >
X-Mutt-Fcc: =sent
Status: RO
Content-Length: 3082
Lines: 83

On Fri, Sep 07, 2001 at 01:19:02AM +0100, Jonathan Larmour wrote:

> > I don't have virtual vectors enabled in my eCos HAL, since I
> > don't my HAL to depend on RedBoot.  I don't want diag_printf to
> > do output with calls to RedBoot.
> > 
> > [I'm using a CVS snapshot from December.]
> 
> At that age, the likely fix is to include this bit from the
> current redboot main.c: 

[...]

Thanks, I'll make sure I add that.

> just before control is passed to the stub by a breakpoint. Or
> perhaps the better thing is to ensure the serial interrupt is
> masked in the diag init code.

Which diag init code -- in RedBoot or in the eCos app?

If it gets masked during the startup of the eCos app then you
would be required to set a breakpoint before starting the eCos
app or you could never interrupt it (right?).

> If you've got a VV enabled HAL,

I don't enable VV when I build eCos.

I don't want my HAL making calls to RedBoot during normal
operation -- that introduces a dependancy between RedBoot and
eCos app versions.  I'll tolerate that dependancy in the case
where somebody wants to use the RedBoot gdb stubs: if they want
that to work, then they've got to make sure they've got the
proper bootloader version.

> > It also keeps refering to a "serial driver," and I don't know
> > what driver that would be -- there is no eCos driver for the
> > debug UART -- eCos doesn't even know it exists.
> 
> The diag driver - whatever driver there is for the debug channel.

There isn't one. eCos (as linked with my apps) doesn't even
know that channel exists.  RedBoot does, but it's the app that
needs to do something when that interrupt occurs.  What I'm
trying to figure is what needs to be done.

> > The hal_arch_default_isr() that I have doesn't do anything
> > except print a "spurious interrupt message". I've looked at the
> > HAL files for other platforms in my snapshot, and they seem to
> > be doing stuff with CygMon.
> 
> Perhaps the ones you've looked at have been only catering for Cygmon.

Apparently.  I'll look at some newer HALs.

> > I presume that I need to modify hal_arch_default_isr() to make
> > a call to RedBoot via the virtual vector table so that it can
> > service the UART and check for 0x03.  Or do I add a
> > hal_default_isr() to my HAL, and figure out how to get that
> > used in place of hal_arch_default_isr()?
> 
> You call hal_ctrlc_isr_init which lives in hal_if.c from
> vectors.S - i.e. the platform HAL shouldn't be involved at all
> (except for the implementation of the underlying driver).
>
> hal_default_isr is meant to come from the hal/common's
> hal_misc.c. In most cases hal_arch_default_isr (defined in the
> arch hal usually) shouldn't do anything except return 0.

To get hal_misc.c/hal_default_isr() to do "the right thing" it
looks like I need to enabled virtual vector support in my HAL,
which then makes my apps dependant on RedBoot.  I don't think
that's going to be acceptible from a support perspective.
Updating apps is trivial (it's transparent to the customer).
Updating RedBoot is a lot harder (ir requires the customer to
perform a sequence of operations) and it's quite possible to
end up with a box that has to be shipped back to the factory.

I guess I'll have to put something into my HAL to take over the
vector for that channel and do the right thing when it sees a
0x03.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Questions about GDB Ctrl-C support.

[Jesper Skov]

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

>> If you've got a VV enabled HAL,

Grant> I don't enable VV when I build eCos.

Grant> I don't want my HAL making calls to RedBoot during normal
Grant> operation -- that introduces a dependancy between RedBoot and
Grant> eCos app versions.  I'll tolerate that dependancy in the case
Grant> where somebody wants to use the RedBoot gdb stubs: if they want
Grant> that to work, then they've got to make sure they've got the
Grant> proper bootloader version.

VV are not RedBoot (or vice versa). Please read
http://sources.redhat.com/ecos/docs-latest/porting/hal-calling-if.html

In summary: if you want the application to provide all the services,
simply set the options so all vectors are claimed by the application
on startup. RedBoot will not be used then.

Jesper

Re: [ECOS] Questions about GDB Ctrl-C support.

[Grant Edwards]

On Mon, Sep 10, 2001 at 10:47:52AM +0200, Jesper Skov wrote:

> >> If you've got a VV enabled HAL,
> 
> Grant> I don't enable VV when I build eCos.
> 
> Grant> I don't want my HAL making calls to RedBoot during normal
> Grant> operation -- that introduces a dependancy between RedBoot and
> Grant> eCos app versions.  I'll tolerate that dependancy in the case
> Grant> where somebody wants to use the RedBoot gdb stubs: if they want
> Grant> that to work, then they've got to make sure they've got the
> Grant> proper bootloader version.
> 
> VV are not RedBoot (or vice versa). Please read
> http://sources.redhat.com/ecos/docs-latest/porting/hal-calling-if.html

Yes, I've read it.  My understanding is that if I let my eCos
apps use VV services provided by RedBoot, then RedBoot has to
be present in memory, it has to be initialized, and it has to
be a version who's VV interface is comptabile with the VV
interface used by the application.  Is that not true?

> In summary: if you want the application to provide all the
> services, simply set the options so all vectors are claimed by
> the application on startup. RedBoot will not be used then.

But I do want to use RedBoot.  I want to use its GDB stubs.  I
just don't want to use use RedBoot for non-gdb services (printf
output).  I'll look at the VV interface stuff again, but I
didn't see how to enable one without enabling the other.

So I added an ISR to my HAL that checks for CTRL-C and calls
the "add-breakpoint" entry in RedBoot's VV table.  That routine
is the only place my HAL that uses RedBoot, so the only time
you have to have RedBoot present is if you want to use it for
debugging via GDB.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Questions about GDB Ctrl-C support.

[Jesper Skov]

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

>>  VV are not RedBoot (or vice versa). Please read
>> http://sources.redhat.com/ecos/docs-latest/porting/hal-calling-if.html

Grant> Yes, I've read it.  My understanding is that if I let my eCos
Grant> apps use VV services provided by RedBoot, then RedBoot has to
Grant> be present in memory, it has to be initialized, and it has to
Grant> be a version who's VV interface is comptabile with the VV
Grant> interface used by the application.  Is that not true?

True.

>> In summary: if you want the application to provide all the
>> services, simply set the options so all vectors are claimed by the
>> application on startup. RedBoot will not be used then.

Grant> But I do want to use RedBoot.  I want to use its GDB stubs.  I
Grant> just don't want to use use RedBoot for non-gdb services (printf
Grant> output).  I'll look at the VV interface stuff again, but I
Grant> didn't see how to enable one without enabling the other.

Well, the stub uses the debug channel and hence the driver RedBoot
provided for driving that channel. however, the stub code internally
uses VV (IIRC) so you should be able to CLAIM_COMMS in the application
(i.e., the application provides the drivers used by printf) and still
be able to use the GDB support (which will then call into RAM for
printing).

Grant> So I added an ISR to my HAL that checks for CTRL-C and calls
Grant> the "add-breakpoint" entry in RedBoot's VV table.  That routine
Grant> is the only place my HAL that uses RedBoot, so the only time
Grant> you have to have RedBoot present is if you want to use it for
Grant> debugging via GDB.

Is that a run-time option then?

Jesper

Re: [ECOS] Questions about GDB Ctrl-C support.

[Jesper Skov]

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

>>  Well, the stub uses the debug channel and hence the driver RedBoot
>> provided for driving that channel. however, the stub code
>> internally uses VV (IIRC) so you should be able to CLAIM_COMMS in
>> the application (i.e., the application provides the drivers used by
>> printf) and still be able to use the GDB support (which will then
>> call into RAM for printing).

Grant> I'm not sure what you mean by "call into RAM".  Do you mean
Grant> that the GDB stubs in RedBoot will use routines in the eCos
Grant> application (via the VV table) to do I/O to/from GDB?  [In my
Grant> case both RedBoot and the eCos application are in RAM.]

Indeed. The VV table allows calling from RAM to ROM or vice
versa. Effectively removing the need for callee and caller to be in
the same (linker) address space.

Grant> That sounds like a pretty good option.  The app will work even
Grant> w/o RedBoot, but the GDB stubs in RedBoot can still be used to
Grant> load and debug programs.  I'll look at doing that.

Correct.

Grant> No, the ISR is always attached. If an interrupt happens and a
Grant> 0x03 is received it assumes RedBoot is there since nobody else
Grant> ever unmasks that interrupt.  It fails if the RedBoot version
Grant> and the eCos application version are incompatible.

OK.

Jesper

Re: [ECOS] Questions about GDB Ctrl-C support.

[Grant Edwards]

On Tue, Sep 11, 2001 at 05:14:05PM +0200, Jesper Skov wrote:

> >>  Well, the stub uses the debug channel and hence the driver RedBoot
> >> provided for driving that channel. however, the stub code
> >> internally uses VV (IIRC) so you should be able to CLAIM_COMMS in
> >> the application (i.e., the application provides the drivers used by
> >> printf) and still be able to use the GDB support (which will then
> >> call into RAM for printing).

Is CLAIM_COMMS a macro?  My snapshot doesn't have it anywhere.
It also doesn't have *_INHERIT_CONSOLE or *_DIAG_TO_DEBUG_CHAN.
Now that I'm overhauling my HAL, I guess I should update to a
newer snapshot (something I haven't been looking forward to).
I'm not flying to visit a customer (an airline) tomorrow as I
had planned...

> Grant> I'm not sure what you mean by "call into RAM".  Do you mean
> Grant> that the GDB stubs in RedBoot will use routines in the eCos
> Grant> application (via the VV table) to do I/O to/from GDB?  [In my
> Grant> case both RedBoot and the eCos application are in RAM.]
> 
> Indeed. The VV table allows calling from RAM to ROM or vice
> versa. Effectively removing the need for callee and caller to be in
> the same (linker) address space.

When the eCos app takes over the comm channels, is there any
state info that gets lost?  Where is the identity of the diag
channel (1) stored?  Does RedBoot remember (outside of the VV
routines) which channel is in use for debug? Redboot knows
about three serial ports (we'll call them 0,1,2), and it will
have chosen #1 as the debug and console channel since that's
the first one upon which received input.  Since I want the app
to send diag_printf() output to #0, I disable
C_H_V_V_INHERIT_CONSOLE and C_H_DIAG_TO_DEBUG_CHAN, and
configure chan 0 and diag and chan 1 as debug (or something
along those lines.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Questions about GDB Ctrl-C support.

[Jonathan Larmour]

Grant Edwards wrote:
> 
> On Tue, Sep 11, 2001 at 05:14:05PM +0200, Jesper Skov wrote:
> 
> > >>  Well, the stub uses the debug channel and hence the driver RedBoot
> > >> provided for driving that channel. however, the stub code
> > >> internally uses VV (IIRC) so you should be able to CLAIM_COMMS in
> > >> the application (i.e., the application provides the drivers used by
> > >> printf) and still be able to use the GDB support (which will then
> > >> call into RAM for printing).
> 
> Is CLAIM_COMMS a macro?

A CDL option.

>  My snapshot doesn't have it anywhere.
> It also doesn't have *_INHERIT_CONSOLE or *_DIAG_TO_DEBUG_CHAN.
> Now that I'm overhauling my HAL, I guess I should update to a
> newer snapshot (something I haven't been looking forward to).

If you're wondering about these types of things and just want to have a
quick look at the current CVS repo, you could try CVSweb:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/?cvsroot=ecos

> > Grant> I'm not sure what you mean by "call into RAM".  Do you mean
> > Grant> that the GDB stubs in RedBoot will use routines in the eCos
> > Grant> application (via the VV table) to do I/O to/from GDB?  [In my
> > Grant> case both RedBoot and the eCos application are in RAM.]
> >
> > Indeed. The VV table allows calling from RAM to ROM or vice
> > versa. Effectively removing the need for callee and caller to be in
> > the same (linker) address space.
> 
> When the eCos app takes over the comm channels, is there any
> state info that gets lost? 

No.

> Where is the identity of the diag
> channel (1) stored?

A pointer to the current diag channel is stored in the virtual vector
table. But if claiming comms (or not inheriting console) then that will be
overridden to use the default channel. There's no concept anywhere of
trying to preserve the channel number, but using a separate instantiation
of the channel functions (i.e. functions in your program, rather than
RedBoot).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] Questions about GDB Ctrl-C support.

[Grant Edwards]

On Wed, Sep 12, 2001 at 02:28:31AM +0100, Jonathan Larmour wrote:

> >  My snapshot doesn't have it anywhere.
> > It also doesn't have *_INHERIT_CONSOLE or *_DIAG_TO_DEBUG_CHAN.
> > Now that I'm overhauling my HAL, I guess I should update to a
> > newer snapshot (something I haven't been looking forward to).
> 
> If you're wondering about these types of things and just want to have a
> quick look at the current CVS repo, you could try CVSweb:
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/?cvsroot=ecos

I grabbed a copy of the current snapshot, and I'm going to try
to get my HAL running w/ that.

> No.
> 
>> Where is the identity of the diag channel (1) stored?
> 
> A pointer to the current diag channel is stored in the virtual
> vector table. But if claiming comms (or not inheriting
> console) then that will be overridden to use the default
> channel.

That should work, since I'm going to configure the application
HAL to always use one channel for diag and the other for debug
(the third gets taken over by a proper eCos device driver).
RedBoot will use any of the three (or telnet) for a console,
but I'm going to require people to use a particular port for
gdb "remote" connections.

> There's no concept anywhere of trying to preserve the channel
> number, but using a separate instantiation of the channel
> functions (i.e. functions in your program, rather than
> RedBoot).

Cool. Thanks,

-- 
Grant Edwards
grante@visi.com