[ECOS] eCos / Redboot network sharing questions

[ECOS] eCos / Redboot network sharing questions

[Barry Wealand]

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

Re: [ECOS] eCos / Redboot network sharing questions

[Andrew Lunn]

On Fri, Oct 07, 2005 at 04:28:21PM +0000, Barry Wealand wrote:
> 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)?

Returning to redboot is not guaranteed to work. Redboot has no idea
what state the application has left the hardware in. It does not know
what interrupts are still active, what DMA engines are still running
etc. And it does not really know how to stop all these and get the
hardware back into a known state. The only reliable way to do this is
a cold reset, but a warn reset will work for most hardware.

When you are doing software development you might be able to live with
Redboot sometimes working correctly when it has been reentered. This
is why the VV call exists. Using it in production is a bad idea. 

Having said all this, making the ethernet drivers work a little more
reliably would be nice. Basically you need to reset the ethernet chip
and driver and then reinitialize it from scratch. Patches welcome.

> (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.)

Are you using different IP addresses for Redboot and the application?

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss