This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
eCos / Redboot network sharing questions
- From: Barry Wealand <barry dot wealand at lmco dot com>
- To: ecos-discuss at sourceware dot org
- Cc: "Mills, Ted" <ted dot mills at lmco dot com>
- Date: Fri, 07 Oct 2005 16:28:21 +0000
- Subject: [ECOS] eCos / Redboot network sharing questions
Hi -
We're working with eCos and Redboot on a MIPS-like target. Redboot is
set up to be able to use an ethernet port, and most of our applications
are built against a kernel that's been configured for network use as
well. While attempting to diagnose some difficulties with remote GDB
operation, I observed that after the application starts up, Redboot
performs all of its ethernet operations using the application's device
driver. Further investigation has shown that this sharing takes place
via virtual vector 19. I just spent some time browsing this mailing
list, and it seems like this is the expected behavior.
That said, I have a couple of questions.
(1) It looks like this sharing continues to take place even after the
application has exited and returned to Redboot (via
CYGACC_CALL_IF_MONITOR_RETURN(0)), i.e., Redboot continues to use the
application's device driver. Is this also the expected behavior? If
so, then how does one go about reloading the same application, or
loading another one (via TFTP)? When we attempt to reload the same
application (an S-record download), everything goes fine up until the
initialized data associated with the appication's device driver gets
rewritten by the download, at which point the driver dies (and so does
the download and Redboot). And of course, loading another application
would be even worse, as the driver code (text) would get trashed during
the download. Is this normal? Does this sharing of device drivers ever
get shut down (short of maybe a "reset" command)?
(2) When I use GDB, I can connect to the target, download the program,
set breakpoints, dump memory, etc., just fine initially. I can even
single-step through some of the early startup code in the program. But
if I try to, say, set a breakpoint within the program itself, and run to
that breakpoint, GDB loses touch with the target. I'm guessing that
this happens when this driver sharing begins (presumably somewhere in
the startup code). Since it seems that this sharing of the driver is
normal, I'll assume that we have some other bug to fix here. (As
another data point, if I build the same program against an eCos kernel
with no network stack, I can use GDB to load that program, set
breakpoints wherever I wish, and everything works fine.)
Thanks in advance for any assistance you can provide.
Barry Wealand
barry.wealand@lmco.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss