Re: [ECOS] RedBoot porting

[Gary Thomas <gthomas@redhat.com>]

On 08-Jan-2001 Grant Edwards wrote:
> 
> I've just started on updating my HAL to be compatible with
> RedBoot. I'm modelling my code on the ebsa285 and edb7xxx HALs
> (they seem to be fairly similar to each other).
> 
> Currently I don't have any GDB stubs in my eCos configuration,
> and no code in my hal_diag.c file to generate 'O' packets for
> daig output.
> 
> I want to add gdb support in my next product -- initially using
> gdb stubs in RedBoot with a fallback position of using gdb
> stubs built into the eCos app.  The packetizing code in
> hal_diag_write_char is still needed if I want to use gdb stubs
> built in to the eCos app, right?

Not if you're using the virtual vector stuff.  It'll come from 
the generic HAL component.  The fact that these routines still
have that support in them is old - i.e. out of date.

> 
> I'm still a little fuzzy on how/when the gdb stubs gain
> control.  If I build an eCos app with gdb stubs, do the stubs
> gain control initially when the app is started, or are they
> dormant until a "control-C" is received on the debugging
> channel?

User programs with stubs included will simply run until they
receive a breakpoint or ^C.  The default stubs, including RedBoot,
simulate this by forcing a breakpoint when they start up.   RedBoot
does this when it sees GDB protocol stuff coming down the serial line.

> 
> I'd like hal_diag_write_char() to not use the packetizing code
> unless there's actually a gdb session active. Is there some way
> the diag output routine can know?

Use the virtual vectors, Luke.

> 
> How do the output routines in RedBoot decide whether to
> packetize output?

It all happens, almost by magic, depending on what's been registered.