This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RedBoot and eCos application both using the same network port


> Well, what's meant to happen in the case of both RedBoot and eCos sharing 
> an ethernet device is that RedBoot sets up the eth driver for itself. Then 
> eCos sets it up again with its own eth driver, but when the eCos code 
> receives a packet, common stuff in io/eth/current/src/net/eth_drv.c does a 
> check for if it was a "ctrl-c", and if so hal_ctrlc_check in 
> hal/common/current/src/hal_if.c sets a breakpoint and we enter RedBoot. 
> When RedBoot sends a packet, magic in eth_drv_send() in eth_drv.c also 
> ensures the right stuff happens.
> 
> But the point is, when eCos takes over, RedBoot will use the *eCos* driver 
> for its debug.
> 
> Now the only exception to all this is if you're trying to debug the 
> ethernet driver itself while debugging over ethernet. If that's what 
> you're doing, my response is.... don't ;-).
> 
> Jifl

All I'm trying to do is debug an application which uses the network port
using GDB connected through the same network port.

Progress so far:

The ks32c5000 ethernet driver was printf-ing lots of debug info to
the console - this was causing the board to crash as there was no
connection to the console while the ethernet driver is re-setting up
the network port.  So I quickly removed the diag_printf's from the
driver.

In the file net/bsd_tcpip/current/src/sys/net/if.c, the function
if_attach(ifp) contains a printf which writes 'driver didn't set
ifq_maxlen' to the console.  This has to be commented out also
as the console is not there when the code is executed.

Now gdb can connect to the board and run the application,
including setting breakpoints and stepping through the code.
The board also responds to pings to the IP address I assigned
RedBoot and the IP address I assigned the application.

However, hitting the stop button on the debugger doesn't work
as yet - but I'm still looking into this.

My question:  For the final fix I can add an option to the
ks32c5000 driver CDL to suppress the debug output from the
driver, but how should I stop the if_attach() function from
writing the ''driver didn't set ifq_maxlen'  message out?  Just
remove that line...? Or should the driver be setting this value?

Cheers,
Chris




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]