From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gary Thomas To: Grant Edwards Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] RedBoot porting Date: Mon, 08 Jan 2001 16:26:00 -0000 Message-id: References: <20010108150612.A11102@visi.com> X-SW-Source: 2001-01/msg00101.html 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.