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

[Grant Edwards <grante at visi dot com>]

>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