> > It seems to me that you're describing two different problems. > > The first - debugging over the network fails when the network > is saturated. > > Remember that debugging via the network is a cooperating effort. > RedBoot and your eCos application share the same hardware and > if something gets unhappy in this process, then the whole thing > will fail. Given the hardware and it's limitations (e.g. you > don't have a separate ethernet controller and stack, etc. for > debugging), then there is no other way for it to work. One > would have to diagnose the problem, probably using an out of > band tool like JTAG. > > The second problem you describe is an old one. Again, since > the ethernet hardware is being shared, things can get confused, > especially during system startup. What's happening is that the > eCos application is reinitializing the network hardware, but at > the same time, trying to print messages using that same hardware. > This simply can't work. I put a change into the stack (years ago) > that side-steps this by forcing those initialization messages > to go to the raw serial console, rather than via the network. > > A couple of questions: > * What's your target? Motorola MVME6100
> * CPU? MPC7457 1.3GHz > There are many PowerPC choices and > most have their own drivers, etc. It would be nice to know > which one you are having trouble with. We wrote the HAL and the ethernet driver. > * What's the vintage of your eCos source tree. As mentioned, > some of these things have been worked on and may be fixed, just > not in the sources you are using. > We are currently using a release from eCosCentric v2.0.51. We were able to compile a GRUB RedBoot i386 target w/i82559 driver. The i386 target ran heaptest (net template), just a little slower than normal. We did not test the "default" target. Thanks for your help, Mike -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
