[ECOS] eCos / Redboot network sharing questions

Andrew Lunn andrew@lunn.ch
Sat Oct 8 08:17:00 GMT 2005


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



More information about the Ecos-discuss mailing list