This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Using the TCP/IP stack from the anonymous CVS server
- To: Jonathan Larmour <jlarmour at redhat dot com>,Richard Wicks <richwicks at home dot com>
- Subject: Re: [ECOS] Using the TCP/IP stack from the anonymous CVS server
- From: Richard Wicks <rich at accetnetwork dot com>
- Date: Tue, 18 Sep 2001 15:28:50 -0700
- Cc: Nicolas dot Lacorne at sun dot com,rich at accetnetwork dot com,ecos-discuss at sourceware dot cygnus dot com
- Organization: Accet Networks
- References: <000801c13fb8$8650a910$090110ac@TRENT> <001101c1405b$8a5a4d60$702cfe18@C1830598A> <3BA7BD91.7AA174D2@redhat.com>
- Reply-To: rich at accetnetwork dot com
On Tuesday 18 September 2001 02:33 pm, Jonathan Larmour wrote:
> Richard Wicks wrote:
> > > Hi ,
> > > Do you use network interface with redboot (and GDB stub)?
> > > In case, if you are not using DHCP, you might check that you you give
> > > two diffirent IP : one for redboot and
> > > one for eCos kernel.
> >
> > This may cause problems with the ARP cache in some machines, especially
> > in switches.
>
> I would hope it wouldn't for anything even slightly modern. Machines with
> multiple IP addresses on the same interface have been around (and working
> fine) for many years now.
I've seen plenty of embedded devices throw up with this but I cannot think of
running into this problem recently since I never use multiple IP addresses.
You're probably right.
> > > You may also try do disable GDB stubs, because there are some problems
> >
> > with
> >
> > > them .
> >
> > GDB cannot be used when the TCP/IP is included? Is this a bug across all
> > platforms or simply the XScale? Working without debug capability will
> > slow down development, are there any known workarounds?
>
> That's not quite right. The restriction is that you cannot include stubs in
> your application when debugging over the network: that's because when you
> do that, the stubs will "claim" the debug channel, which will close your
> TCP connection.
> Jifl
OK - disable the stubs on the application or redboot? Can you tell me how to
do it with ecosconfig?
In either case, right now I'm not even using the ethernet to debug with, only
the serial channel. Still, redboot IS compiled to support debugging over the
network although I'm not using it. I've been having some trouble recompiling
redboot without ethernet support. Here is what I'm doing.
ecosconfig new iq80310 redboot
ecosconfig import redboot_ROM.cfg (included at end of this mail)
ecosconfig remove CYGPKG_DEVS_ETH_ARM_IQ80310
ecosconfig tree
make
The resulting rom causes the board (as well as the entire PC that it's
plugged into) to lockup. If I do not remove CYGPKG_DEVS_ETH_ARM_IQ80310 the
resulting image works fine.
-Rich
------------------
redboot_ROM.cfg (taken from intel's distribution of the redboot source code
located at:
http://developer.intel.com/design/intelxscale/dev_tools/redboot-src.tar.htm)
------------------
cdl_savefile_version 1;
cdl_savefile_command cdl_savefile_version {};
cdl_savefile_command cdl_savefile_command {};
cdl_savefile_command cdl_configuration { description hardware template
package };
cdl_savefile_command cdl_package { value_source user_value wizard_value
inferred_value };
cdl_savefile_command cdl_component { value_source user_value wizard_value
inferred_value };
cdl_savefile_command cdl_option { value_source user_value wizard_value
inferred_value };
cdl_savefile_command cdl_interface { value_source user_value wizard_value
inferred_value };
cdl_configuration eCos {
description "" ;
hardware iq80310 ;
template redboot ;
package -hardware CYGPKG_HAL_ARM current ;
package -hardware CYGPKG_HAL_ARM_IQ80310 current ;
package -hardware CYGPKG_IO_PCI current ;
package -hardware CYGPKG_DEVS_ETH_ARM_IQ80310 current ;
package -hardware CYGPKG_IO_SERIAL_ARM_IQ80310 current ;
package -template CYGPKG_HAL current ;
package -template CYGPKG_INFRA current ;
package -template CYGPKG_REDBOOT current ;
package CYGPKG_IO_FLASH current ;
package CYGPKG_IO_ETH_DRIVERS current ;
package CYGPKG_DEVS_FLASH_IQ80310 current ;
};
cdl_option CYGBLD_BUILD_GDB_STUBS {
user_value 0
};
cdl_option CYGDBG_DEVS_ETH_ARM_IQ80310_CHATTER {
user_value 0
};
cdl_option CYGNUM_DEVS_ETH_ARM_IQ80310_DEV_COUNT {
user_value 1
};
cdl_option CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT {
user_value 0
};
cdl_option CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM {
inferred_value 0
};
cdl_option CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS {
inferred_value 1
};
cdl_option CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT {
inferred_value 1
};
cdl_option CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT {
inferred_value 0
};
cdl_option CYGSEM_HAL_ROM_MONITOR {
user_value 1
};
cdl_option CYGSEM_HAL_USE_ROM_MONITOR {
inferred_value 0 0
};
cdl_component CYG_HAL_STARTUP {
user_value ROM
};
cdl_option CYGBLD_BUILD_REDBOOT {
user_value 1
};
cdl_option CYGSEM_REDBOOT_FLASH_CONFIG {
user_value 1
};
cdl_option CYGSEM_REDBOOT_BSP_SYSCALLS {
inferred_value 1
};
cdl_option CYGBLD_REDBOOT_MIN_IMAGE_SIZE {
inferred_value 0x40000
};
cdl_option CYGNUM_IO_ETH_DRIVERS_NUM_PKT {
user_value 2
};