RE: [ECOS] Network Support

RE: [ECOS] Network Support

[Zubin Burjor Sethna]

I had a quick look, it seems the development tools are ADA based and you can
only access the on-line docs if you are a support customer. Doesn't sound
very open to me. Have I missed something?

Zubin


> RTEMS (the first(?) Open Source RTOS ;) has a decent TCP/IP stack... and
> has
> a *LOT* of MPC860 people using it. I don't think that anyone has released
> a
> BSP for a generic MPC860 board but I'm sure that getting one together is
> not
> that tough.
> As far as RTOSs go RTEMS is somewhere between eCos and a larger RTOS like
> vxworks for features. Have a look at http://www.oarcorp.com/ for details.
> 
> Dave

RE: [ECOS] Network Support

[David J. Fiddes]

Hi,

> I had a quick look, it seems the development tools are ADA based
> and you can
> only access the on-line docs if you are a support customer. Doesn't sound
> very open to me. Have I missed something?

Yep. 'fraid so. RTEMS has a C *AND* ADA API. The majority of developers go
the C/C++ route. I'm hoping to get a GNU Pascal binding running at some
point this year.

The docs should be available in the free support section...and are available
in a variety of formats for download... at least I had no problems ;)

The licence is GPL with a single exception that by including the OS header
files you do not automatically place your app under the GPL. Many RTEMS
developers(pretty much 100% volunteers) are regular contributers to binutils
and EGCS just like the Cygnus guys( although not as numerous ;)... how much
more open do you want?

Dave

> > RTEMS (the first(?) Open Source RTOS ;) has a decent TCP/IP stack... and
> > has
> > a *LOT* of MPC860 people using it. I don't think that anyone
> has released
> > a
> > BSP for a generic MPC860 board but I'm sure that getting one together is
> > not
> > that tough.
> > As far as RTOSs go RTEMS is somewhere between eCos and a larger
> RTOS like
> > vxworks for features. Have a look at http://www.oarcorp.com/
> for details.

RE: [ECOS] network support

[James Dabbs]

We're interested in evaluating eCos for an embedded network application.  I
am wondering how much work it will be to create a BSP for an Atmel AT91EB40
EVB with a scabbed-on LAN91C110 or LAN91C96.  We will be using UDP/IP over
ethernet, but we need to be a DCHP client and be able to join IP multicast
groups.

1. Is this supported "out-of-the-box"?

2. If not, is it close to anything already supported?

3. Is there a white-paper on BSP development/porting that can give me an
idea of the task to get eCos running in this environment?

Thanks!
James Dabbs

[ECOS] network support

[Fano Ramparany]

I'm testing the tcpip network support on a EDB7212 board. I've looked at

the init_all_network_interfaces source code which suggests that
CYGHWR_NET_DRIVER_ETH0_BOOTP macro should be defined
as a compilation flag. When this is tested I get the messages:
SIOCSIFADDR: Device not configured
BOOTP failed on eth0
What did I wrong? Is there any documentation on how to use the tcpip
stack?
Thanks in advance for any hint.

Fano Ramparany

RE: [ECOS] network support

[Gary Thomas]

On 19-Jan-2001 Fano Ramparany wrote:
> I'm testing the tcpip network support on a EDB7212 board. I've looked at
> 
> the init_all_network_interfaces source code which suggests that
> CYGHWR_NET_DRIVER_ETH0_BOOTP macro should be defined
> as a compilation flag. When this is tested I get the messages:
> SIOCSIFADDR: Device not configured
> BOOTP failed on eth0
> What did I wrong? Is there any documentation on how to use the tcpip
> stack?
> Thanks in advance for any hint.
> 
> Fano Ramparany

Here's the very simplest way to test this (using ecosconfig).

  [gthomas@hermes test2]$ ecosconfig new edb7212 net
  [gthomas@hermes test2]$ ecosconfig tree           
  [gthomas@hermes test2]$ make;make -C net/tcpip/current/ tests TESTS=tests/ping_test

Similar results can be obtained by just using the "net" template and
then enabling/building tests.

Does this sequence [scenario] not work for you?

Re: [ECOS] network support

[Fano Ramparany]

Gary Thomas wrote:

> Here's the very simplest way to test this (using ecosconfig).
>
>   [gthomas@hermes test2]$ ecosconfig new edb7212 net
>   [gthomas@hermes test2]$ ecosconfig tree
>   [gthomas@hermes test2]$ make;make -C net/tcpip/current/ tests TESTS=tests/ping_test
>
> Similar results can be obtained by just using the "net" template and
> then enabling/building tests.
>
> Does this sequence [scenario] not work for you?

I guess this is the linux scenario. We are using the Windows Development tools.
Thus here is our scenario:
We have registered the Networking package using the Package Administration tool, then
using the eCos Configuration tool we have added the Networking package by ticking on
INET support option.
Initialization options for eth0 and eth1 are greyed out, then we can't modify them.
There
status are: Use BOOTP/DHCP and Show BOOTP/DHCP for both eth0 and eth1.
Other options have been set with their default value.
Then we've build the library and the tests.
When running the ping test here is the gdb debugger trace, which makes no mention of the
ping
session I think:

Loading section .rom_vectors, size 0x60 lma 0x8000
Loading section .text, size 0x25b0c lma 0x8060
Loading section .rodata, size 0x14b2 lma 0x2db6c
Loading section .data, size 0xb60 lma 0x2f020
Start address 0x8060 , load size 162686
Transfer rate: 27691 bits/sec, 305 bytes/write.
(gdb) break cyg_test_exit
Breakpoint 1 at 0x8558: file
//C/PROGRA~1/REDHAT~1/eCos/packages/net/tcpip/v1_0b1/tests/ping_test.c, line 74.
(gdb) break cyg_assert_fail
Function "cyg_assert_fail" not defined.
(gdb) break cyg_test_init
Function "cyg_test_init" not defined.
(gdb) cont
Continuing.
Network stack using 65536 bytes for misc space
                    65536 bytes for mbufs
                    131072 bytes for mbuf clusters
Start PING test
... Done

Breakpoint 1, cyg_test_exit ()
    at //C/PROGRA~1/REDHAT~1/eCos/packages/net/tcpip/v1_0b1/tests/ping_test.c:74
74          while (1) ;
(gdb) set cyg_test_is_simulator=0
No symbol "cyg_test_is_simulator" in current context.
(gdb) cont
Continuing.

Breakpoint 1, cyg_test_exit ()
    at //C/PROGRA~1/REDHAT~1/eCos/packages/net/tcpip/v1_0b1/tests/ping_test.c:74
74          while (1) ;
(gdb) *** 15:39:38 Run complete

Re: [ECOS] network support

[Gary Thomas]

On 22-Jan-2001 Fano Ramparany wrote:
> Gary Thomas wrote:
> 
>> Here's the very simplest way to test this (using ecosconfig).
>>
>>   [gthomas@hermes test2]$ ecosconfig new edb7212 net
>>   [gthomas@hermes test2]$ ecosconfig tree
>>   [gthomas@hermes test2]$ make;make -C net/tcpip/current/ tests TESTS=tests/ping_test
>>
>> Similar results can be obtained by just using the "net" template and
>> then enabling/building tests.
>>
>> Does this sequence [scenario] not work for you?
> 
> I guess this is the linux scenario. We are using the Windows Development tools.
> Thus here is our scenario:
> We have registered the Networking package using the Package Administration tool, then
> using the eCos Configuration tool we have added the Networking package by ticking on
> INET support option.
> Initialization options for eth0 and eth1 are greyed out, then we can't modify them.
> There
> status are: Use BOOTP/DHCP and Show BOOTP/DHCP for both eth0 and eth1.
> Other options have been set with their default value.
> Then we've build the library and the tests.
> When running the ping test here is the gdb debugger trace, which makes no mention of the
> ping
> session I think:
>

The way I did this using the Windows Config Tool was
  Build->Templates
    Hardware = Cirrus Logic development board
    Packages = net

This selection is equivalent to the 'ecosconfig' steps above.  All of the appropriate
options are automatically enabled and it should "just work".

Re: [ECOS] network support

[Fano Ramparany]

Gary Thomas wrote:

> The way I did this using the Windows Config Tool was
>   Build->Templates
>     Hardware = Cirrus Logic development board
>     Packages = net
>
> This selection is equivalent to the 'ecosconfig' steps above.  All of the appropriate
> options are automatically enabled and it should "just work".

Thank you for your reply. I've done this exactly but I still have a problem running the
ping_test example.
There is no session trace:

<<output begins here>>
...
Start address 0x8060 , load size 162686
Transfer rate: 28293 bits/sec, 305 bytes/write.
(gdb) break cyg_test_exit
Breakpoint 1 at 0x8558: file
//C/PROGRA~1/REDHAT~1/eCos/packages/net/tcpip/v1_0b1/tests/ping_test.c, line 74.
(gdb) break cyg_assert_fail
Function "cyg_assert_fail" not defined.
(gdb) break cyg_test_init
Function "cyg_test_init" not defined.
(gdb) cont
Continuing.
Network stack using 65536 bytes for misc space
                    65536 bytes for mbufs
                    131072 bytes for mbuf clusters
Start PING test
... Done

Breakpoint 1, cyg_test_exit ()
    at //C/PROGRA~1/REDHAT~1/eCos/packages/net/tcpip/v1_0b1/tests/ping_test.c:74
74          while (1) ;
(gdb) set cyg_test_is_simulator=0
No symbol "cyg_test_is_simulator" in current context.
(gdb) cont
Continuing.

Breakpoint 1, cyg_test_exit ()
    at //C/PROGRA~1/REDHAT~1/eCos/packages/net/tcpip/v1_0b1/tests/ping_test.c:74
74          while (1) ;
(gdb) *** 11:30:51 Run complete
...
<<output ends here>>

I then had a look at the configuration file.
Below is the part of the "ecc" file related the network
drivers. All variables related to the NET_DRIVERS are assigned
a 0 value.
In the (Windows NT) eCos Configuration Tool, the items Initialization
options for 'eth0', are greyed out, and thus can't be
modified.
Do you have any hint about what I'm doing wrong?

<<ecc file exceprt begins here>>
...
# <
# <
# Network drivers
#
cdl_interface CYGHWR_NET_DRIVERS {
    # This value cannot be modified here.
    # Current_value: 0
};

# Does the hardware provide an 'eth0' device?
#
cdl_interface CYGHWR_NET_DRIVER_ETH0 {
    # This value cannot be modified here.
    # Current_value: 0

    # The following properties are affected by this value
    # component CYGHWR_NET_DRIVER_ETH0_SETUP_OPTIONS
    #     ActiveIf: (CYGHWR_NET_DRIVER_ETH0 == 1)
};

# Initialization options for 'eth0'
#
cdl_component CYGHWR_NET_DRIVER_ETH0_SETUP_OPTIONS {
    # This option is not active
    # ActiveIf constraint: (CYGHWR_NET_DRIVER_ETH0 == 1)
    #     CYGHWR_NET_DRIVER_ETH0 == 0
    #   --> 0

    # There is no associated value.
};

# >
# Initialization options for 'eth0'
#
cdl_interface CYGHWR_NET_DRIVER_ETH0_SETUP {
    # Implemented by CYGHWR_NET_DRIVER_ETH0_MANUAL, inactive, disabled
    # Implemented by CYGHWR_NET_DRIVER_ETH0_BOOTP, inactive, enabled
    # Implemented by CYGHWR_NET_DRIVER_ETH0_ADDRS, inactive, disabled
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_SETUP_OPTIONS is not active

    # This value cannot be modified here.
    # Current_value: 0
    # Requires: 1 == CYGHWR_NET_DRIVER_ETH0_SETUP
    #     CYGHWR_NET_DRIVER_ETH0_SETUP == 0
    #   --> 0

    # The following properties are affected by this value
    # interface CYGHWR_NET_DRIVER_ETH0_SETUP
    #     Requires: 1 == CYGHWR_NET_DRIVER_ETH0_SETUP
};

# Initialize 'eth0' manually?
#
cdl_component CYGHWR_NET_DRIVER_ETH0_MANUAL {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_SETUP_OPTIONS is not active

    # Flavor: bool
    # No user value, uncomment the following line to provide one.
    # user_value 0
    # value_source default
    # Default value: 0
};

# Use BOOTP/DHCP to initialize 'eth0'?
#
cdl_component CYGHWR_NET_DRIVER_ETH0_BOOTP {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_SETUP_OPTIONS is not active

    # Flavor: bool
    # No user value, uncomment the following line to provide one.
    # user_value 1
    # value_source default
    # Default value: 1
};

# >
# Show BOOTP/DHCP initialization values?
#
cdl_option CYGHWR_NET_DRIVER_ETH0_BOOTP_SHOW {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_BOOTP is not active

    # Flavor: bool
    # No user value, uncomment the following line to provide one.
    # user_value 1
    # value_source default
    # Default value: 1
};

# <
# Address setups for 'eth0'
#
cdl_component CYGHWR_NET_DRIVER_ETH0_ADDRS {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_SETUP_OPTIONS is not active

    # Flavor: bool
    # No user value, uncomment the following line to provide one.
    # user_value 0
    # value_source default
    # Default value: 0
};

# >
# IP address for 'eth0'
#
cdl_option CYGHWR_NET_DRIVER_ETH0_ADDRS_IP {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is disabled

    # Flavor: data
    # No user value, uncomment the following line to provide one.
    # user_value 192.168.1.2
    # value_source default
    # Default value: 192.168.1.2
};

# Network mask address for 'eth0'
#
cdl_option CYGHWR_NET_DRIVER_ETH0_ADDRS_NETMASK {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is disabled

    # Flavor: data
    # No user value, uncomment the following line to provide one.
    # user_value 255.255.255.0
    # value_source default
    # Default value: 1
};

# <
# Address setups for 'eth0'
#
cdl_component CYGHWR_NET_DRIVER_ETH0_ADDRS {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_SETUP_OPTIONS is not active

    # Flavor: bool
    # No user value, uncomment the following line to provide one.
    # user_value 0
    # value_source default
    # Default value: 0
};

# >
# IP address for 'eth0'
#
cdl_option CYGHWR_NET_DRIVER_ETH0_ADDRS_IP {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is disabled

    # Flavor: data
    # No user value, uncomment the following line to provide one.
    # user_value 192.168.1.2
    # value_source default
    # Default value: 192.168.1.2
};

# Network mask address for 'eth0'
#
cdl_option CYGHWR_NET_DRIVER_ETH0_ADDRS_NETMASK {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is disabled

    # Flavor: data
    # No user value, uncomment the following line to provide one.
    # user_value 255.255.255.0
    # value_source default
    # Default value: 255.255.255.0
};

# Broadcast address for 'eth0'
#
cdl_option CYGHWR_NET_DRIVER_ETH0_ADDRS_BROADCAST {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is disabled

    # Flavor: data
    # No user value, uncomment the following line to provide one.
    # user_value 192.168.1.255
    # value_source default
    # Default value: 192.168.1.255
};

# Gateway/router IP address for 'eth0'
#
cdl_option CYGHWR_NET_DRIVER_ETH0_ADDRS_GATEWAY {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is disabled

    # Flavor: data
    # No user value, uncomment the following line to provide one.
    # user_value 192.168.1.101
    # value_source default
    # Default value: 192.168.1.101
};

# Server IP address for 'eth0'
#
cdl_option CYGHWR_NET_DRIVER_ETH0_ADDRS_SERVER {
    # This option is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is not active
    # The parent CYGHWR_NET_DRIVER_ETH0_ADDRS is disabled

    # Flavor: data
    # No user value, uncomment the following line to provide one.
    # user_value 192.168.1.101
    # value_source default
    # Default value: 192.168.1.101
};
...
<<ecc file exceprt ends here>>

Re: [ECOS] network support

[Gary Thomas]

On 30-Jan-2001 Fano Ramparany wrote:
> I then had a look at the configuration file.
> Below is the part of the "ecc" file related the network
> drivers. All variables related to the NET_DRIVERS are assigned
> a 0 value.
> In the (Windows NT) eCos Configuration Tool, the items Initialization
> options for 'eth0', are greyed out, and thus can't be
> modified.
> Do you have any hint about what I'm doing wrong?
> 

This is definitely your problem.  Did you create this configuration
from scratch?  I just tried this, starting fresh, selecting the
Cirrus Logic development board + "net" template - AT ONE TIME - and
it came out perfectly.

  Build->Templates->Hardware = Cirrus Logic Development Board
                    Packages = net

What sources are you building from?  If non anonCVS, then you might 
consider trying that.

Here's an excerpt [from the same point as yours]:
# <
# Network drivers
#
cdl_interface CYGHWR_NET_DRIVERS {
    # Implemented by CYGPKG_DEVS_ETH_ARM_EDB7XXX, active, enabled
    # This value cannot be modified here.
    # Flavor: data
    # Current_value: 1

    # The following properties are affected by this value
    # component CYGPKG_NET_DHCP
    #     ActiveIf: (CYGHWR_NET_DRIVERS > 0)
};

# Does the hardware provide an 'eth0' device?
#
cdl_interface CYGHWR_NET_DRIVER_ETH0 {
    # Implemented by CYGPKG_DEVS_ETH_ARM_EDB7XXX, active, enabled
    # This value cannot be modified here.
    # Flavor: data
    # Current_value: 1

    # The following properties are affected by this value
    # component CYGHWR_NET_DRIVER_ETH0_SETUP_OPTIONS
    #     ActiveIf: (CYGHWR_NET_DRIVER_ETH0 == 1)
};

Re: [ECOS] network support

[Fano Ramparany]

Gary Thomas wrote:

> On 30-Jan-2001 Fano Ramparany wrote:
> > I then had a look at the configuration file.
> > Below is the part of the "ecc" file related the network
> > drivers. All variables related to the NET_DRIVERS are assigned
> > a 0 value.
> > In the (Windows NT) eCos Configuration Tool, the items Initialization
> > options for 'eth0', are greyed out, and thus can't be
> > modified.
> > Do you have any hint about what I'm doing wrong?
> >
>
> This is definitely your problem.  Did you create this configuration
> from scratch?  I just tried this, starting fresh, selecting the
> Cirrus Logic development board + "net" template - AT ONE TIME - and
> it came out perfectly.
>

I don't have the "net" package available as an option package in
the Build->Template... dialog box. Instead  I do
a Cirrus Logic development board + "all" template. Then I
do I Build->Packages.. and select the "Networking" package which
I "Add>>" to the configuration. This adds the Networking node in
the configuration tree (with thoses "initialization option for eth0"
subnodes greyed out).

May be the TCP/IP package installation was not properly made.
But what I did for this purpose was
Red Hat eCos -> Package Administration Tool
then click on "Add.." and select the "net-1.0b1.epk" from the
"Open eCos Package Files" file selector.
Is this OK?

Fano

>   Build->Templates->Hardware = Cirrus Logic Development Board
>                     Packages = net
>
> What sources are you building from?  If non anonCVS, then you might
> consider trying that.

I'm using the distribution version (v1.3.1 release for eCos and
v1.0b1 release for the TCP/IP stack).

Re: [ECOS] network support

[Gary Thomas]

On 30-Jan-2001 Fano Ramparany wrote:
>>   Build->Templates->Hardware = Cirrus Logic Development Board
>>                     Packages = net
>>
>> What sources are you building from?  If non anonCVS, then you might
>> consider trying that.
> 
> I'm using the distribution version (v1.3.1 release for eCos and
> v1.0b1 release for the TCP/IP stack).

Can you please try using anonCVS?  These releases you are using are
incredibly old - in fact, I don't even think they have network support
for the Cirrus Logic board in them (they date from March 2000 or so)!!

Re: [ECOS] network support

[Lewin A.R.W. Edwards]

> > I'm using the distribution version (v1.3.1 release for eCos and
> > v1.0b1 release for the TCP/IP stack).
>
>Can you please try using anonCVS?  These releases you are using are
>incredibly old - in fact, I don't even think they have network support
>for the Cirrus Logic board in them (they date from March 2000 or so)!!

They don't have any network support in them at all, I understood that was 
in the net-1.0b1 archive. I have that installed, but haven't tried to do 
anything with it yet.

(I am running the same version of eCos as above, not keen to upgrade right 
now; I haven't yet been able to compile anything I ever downloaded using CVS).

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] network support

[Gary Thomas]

On 30-Jan-2001 Lewin A.R.W. Edwards wrote:
> 
>> > I'm using the distribution version (v1.3.1 release for eCos and
>> > v1.0b1 release for the TCP/IP stack).
>>
>>Can you please try using anonCVS?  These releases you are using are
>>incredibly old - in fact, I don't even think they have network support
>>for the Cirrus Logic board in them (they date from March 2000 or so)!!
> 
> They don't have any network support in them at all, I understood that was 
> in the net-1.0b1 archive. I have that installed, but haven't tried to do 
> anything with it yet.
> 

The net.epk file will add the basic networking, but I'm pretty sure that it
does not add any/all of the drivers for the various architectures.

> (I am running the same version of eCos as above, not keen to upgrade right 
> now; I haven't yet been able to compile anything I ever downloaded using CVS).

Have you actually tried building eCos from anonCVS (or is this just your
experience in general)?  Most of our users are using anonCVS and I know of
no problems with it.

Re: [ECOS] network support

[Lewin A.R.W. Edwards]

> >> > I'm using the distribution version (v1.3.1 release for eCos and
> >>
> >>incredibly old - in fact, I don't even think they have network support
> >>for the Cirrus Logic board in them (they date from March 2000 or so)!!
> >
> > They don't have any network support in them at all, I understood that was
> > in the net-1.0b1 archive. I have that installed, but haven't tried to do
>
>The net.epk file will add the basic networking, but I'm pretty sure that it
>does not add any/all of the drivers for the various architectures.

Well, when I added it (manually, it wouldn't work with the graphical 
configuration tool), I got a new package "Cirrus Logic ethernet driver", 
description "Ethernet driver for Cirrus EDB7xxx development boards".

> > now; I haven't yet been able to compile anything I ever downloaded 
> using CVS).
>
>Have you actually tried building eCos from anonCVS (or is this just your
>experience in general)?  Most of our users are using anonCVS and I know of
>no problems with it.

Well, it is my experience in general. When I was trying to get a working 
set of ARM tools to compile eCos, I tried getting all the latest - gcc as 
well as eCos - and failed miserably with all sorts of errors I didn't have 
time to analyze. I prefer to wait for someone to archive up his working 
source tree, call it a snapshot, and make it available for download. It 
also means I don't have to wrestle with the cvs client program.

The eCos version I'm running brings up the board OK, and that's good enough 
for the working demo I need to show next week. I've been working on 
optimizing my DOS and ISO9660 filesystems, and porting my JPEG and MPEG-1 
decoders, and that has kept me happily occupied.

The product I'm working on right now is the low-end version that doesn't 
use networking, so I don't see any reason to try to jump through blazing 
hoops to get the latest greatest eCos version downloaded and working. It 
will probably go to manufacturing with 1.3.1 in it.

The higher-end versions with Ethernet.. well, I'll cross that bridge when I 
come to it.

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] network support

[Fano Ramparany]

I have installed the eCos jan. 30, 2001 snapshot  from ftp.skynet.ie
and the Configtool version 1.3.1.2 available from redhat

I can configure and compile the library and the ping_test correctly.
But whenever I run the ping_test application (load and execute through
serial line connection) it immediately catches an interrupt
(arm-elf-gdb trace:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x50 in ?? ())

Somebody told me to try removing the JP45 jumper on my EDB7212 board,
but this doesn't solve the problem. I have some doubt about the eCos
library
itself, as running the hello test example give rise to the same interrupt

with the same arm-elf-gdb trace than with the ping_test application.
(althought  the ethernet cable is not connected to the board).

Fano

Gary Thomas wrote:

> On 30-Jan-2001 Fano Ramparany wrote:
> >>   Build->Templates->Hardware = Cirrus Logic Development Board
> >>                     Packages = net
> >>
> >> What sources are you building from?  If non anonCVS, then you might
> >> consider trying that.
> >
> > I'm using the distribution version (v1.3.1 release for eCos and
> > v1.0b1 release for the TCP/IP stack).
>
> Can you please try using anonCVS?  These releases you are using are
> incredibly old - in fact, I don't even think they have network support
> for the Cirrus Logic board in them (they date from March 2000 or so)!!

Re: [ECOS] network support

[Gary Thomas]

What are you using for bootstrap firmware on the board?

If you're not using RedBoot, can you try it?

On 13-Feb-2001 Fano Ramparany wrote:
> I have installed the eCos jan. 30, 2001 snapshot  from ftp.skynet.ie
> and the Configtool version 1.3.1.2 available from redhat
> 
> I can configure and compile the library and the ping_test correctly.
> But whenever I run the ping_test application (load and execute through
> serial line connection) it immediately catches an interrupt
> (arm-elf-gdb trace:
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x50 in ?? ())
> 
> Somebody told me to try removing the JP45 jumper on my EDB7212 board,
> but this doesn't solve the problem. I have some doubt about the eCos
> library
> itself, as running the hello test example give rise to the same interrupt
> 
> with the same arm-elf-gdb trace than with the ping_test application.
> (althought  the ethernet cable is not connected to the board).
> 
> Fano
> 
> Gary Thomas wrote:
> 
>> On 30-Jan-2001 Fano Ramparany wrote:
>> >>   Build->Templates->Hardware = Cirrus Logic Development Board
>> >>                     Packages = net
>> >>
>> >> What sources are you building from?  If non anonCVS, then you might
>> >> consider trying that.
>> >
>> > I'm using the distribution version (v1.3.1 release for eCos and
>> > v1.0b1 release for the TCP/IP stack).
>>
>> Can you please try using anonCVS?  These releases you are using are
>> incredibly old - in fact, I don't even think they have network support
>> for the Cirrus Logic board in them (they date from March 2000 or so)!!

Re: [ECOS] network support

[Fano Ramparany]

Gary Thomas wrote:

> What are you using for bootstrap firmware on the board?

I'm using gdb-stubs.

> If you're not using RedBoot, can you try it?

I just tried but unfortunately here are the problems I run into:

Using the windows eCos configuration tool, from the CirrusLogic
hardware / net packages eCos configuration, I've added the redboot
package. Then when rebuilding the library I get the following
error:

arm-elf-gcc -c  -I//F/OS/ECos/CirrusConf/netrb300101_install/include
-I//C/PROGRA~1/REDHAT~1/eCos/packages/redboot/curr
ent -I//C/PROGRA~1/REDHAT~1/eCos/packages/redboot/current/src
-I//C/PROGRA~1/REDHAT~1/eCos/packages/redboot/current/tes
ts -I. -I//C/PROGRA~1/REDHAT~1/eCos/packages/redboot/current/src/net/
-mcpu=arm7tdmi -Wall -Wpointer-arith -Wstrict-pro
totypes -Winline -Wundef -Woverloaded-virtual -g -O2 -ffunction-sections
-fdata-sections -fno-rtti -fno-exceptions -fvt
able-gc -finit-priority -Wp,-MD,src/net/enet.tmp -o src/net/redboot_enet.o
//C/PROGRA~1/REDHAT~1/eCos/packages/redboot/
current/src/net/enet.c
In file included from
//F/OS/ECos/CirrusConf/netrb300101_install/include/machine/endian.h:66,
                 from
//F/OS/ECos/CirrusConf/netrb300101_install/include/sys/bsdtypes.h:106,
                 from
//F/OS/ECos/CirrusConf/netrb300101_install/include/sys/types.h:137,
                 from
//F/OS/ECos/CirrusConf/netrb300101_install/include/sys/param.h:118,
                 from
//F/OS/ECos/CirrusConf/netrb300101_install/include/eth_drv.h:63,
                 from
//C/PROGRA~1/REDHAT~1/eCos/packages/redboot/current/src/net/enet.c:48:
//F/OS/ECos/CirrusConf/netrb300101_install/include/sys/endian.h:237: warning:
`htons' redefined
//F/OS/ECos/CirrusConf/netrb300101_install/include/net/net.h:75: warning: this
is the location of the previous definiti
on
//F/OS/ECos/CirrusConf/netrb300101_install/include/sys/endian.h:238: warning:
`htonl' redefined
//F/OS/ECos/CirrusConf/netrb300101_install/include/net/net.h:74: warning: this
is the location of the previous definiti
on
In file included from
//F/OS/ECos/CirrusConf/netrb300101_install/include/eth_drv.h:63,
                 from
//C/PROGRA~1/REDHAT~1/eCos/packages/redboot/current/src/net/enet.c:48:
//F/OS/ECos/CirrusConf/netrb300101_install/include/sys/param.h:120:
sys/simplelock.h: No such file or directory
//F/OS/ECos/CirrusConf/netrb300101_install/include/sys/param.h:132:
sys/syslimits.h: No such file or directory
//F/OS/ECos/CirrusConf/netrb300101_install/include/sys/param.h:162:
sys/signal.h: No such file or directory
In file included from
//F/OS/ECos/CirrusConf/netrb300101_install/include/eth_drv.h:63,
                 from
//C/PROGRA~1/REDHAT~1/eCos/packages/redboot/current/src/net/enet.c:48:
//F/OS/ECos/CirrusConf/netrb300101_install/include/sys/param.h:202: warning:
`CLBYTES' redefined
//F/OS/ECos/CirrusConf/netrb300101_install/include/machine/param.h:72:
warning: this is the location of the previous de
finition
//F/OS/ECos/CirrusConf/netrb300101_install/include/sys/param.h:208: warning:
`CLSIZE' is not defined
In file included from
//F/OS/ECos/CirrusConf/netrb300101_install/include/eth_drv.h:64,
                 from
//C/PROGRA~1/REDHAT~1/eCos/packages/redboot/current/src/net/enet.c:48:
//F/OS/ECos/CirrusConf/netrb300101_install/include/sys/socket.h:156: warning:
`AF_INET' redefined
//F/OS/ECos/CirrusConf/netrb300101_install/include/net/net.h:106: warning:
this is the location of the previous definit
ion
In file included from
//F/OS/ECos/CirrusConf/netrb300101_install/include/eth_drv.h:69,
                 from
//C/PROGRA~1/REDHAT~1/eCos/packages/redboot/current/src/net/enet.c:48:
//F/OS/ECos/CirrusConf/netrb300101_install/include/netinet/in.h:269: warning:
`INADDR_ANY' redefined
//F/OS/ECos/CirrusConf/netrb300101_install/include/net/net.h:107: warning:
this is the location of the previous definit
ion
make[1]: *** [src/net/enet.o.d] Error 1
make[1]: Leaving directory
`/f/OS/ECos/CirrusConf/netrb300101_build/redboot/current'
make: *** [build] Error 2

...
Any hints?
So at the moment I'm simply trying to compile from  CirrusLogic hardware / net
package (without network support)
to see if I can get the edb7212_redboot_ROM.bin file built. Doing that raises
several conflicts which I let the
eCos Configuration Tool resolve with its suggested solutions. Right now
compilation is proceeding...

Fano

Re: [ECOS] network support

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

On 14-Feb-2001 Fano Ramparany wrote:
> Any hints?
> So at the moment I'm simply trying to compile from  CirrusLogic hardware / net
> package (without network support)
> to see if I can get the edb7212_redboot_ROM.bin file built. Doing that raises
> several conflicts which I let the
> eCos Configuration Tool resolve with its suggested solutions. Right now
> compilation is proceeding...
> 

Building RedBoot is quite simple.

Using 'ecosconfig'
  % ecosconfig new edb7212 redboot
  % ecosconfig add flash eth_drivers
  % ecosconfig tree
  % make

Using the ConfigTool
  Select Build->Templates
    Hardware Platform = Cirrus Logic Development Board
    Template = RedBoot

  Select Build->Packages
    Add 'Generic FLASH memory support'

  Select Build->Packages
    Add 'Common ethernet support'

  Adjust platform details for EDB7212


Or, just use the attached binary image.

[-- Attachment #2: redboot_EDB7212_ROM.bin --]
[-- Type: application/octet-stream, Size: 83876 bytes --]

Re: [ECOS] network support

[Fano Ramparany]

Gary Thomas wrote:

> Using the ConfigTool
>   Select Build->Templates
>     Hardware Platform = Cirrus Logic Development Board
>     Template = RedBoot
>
>   Select Build->Packages
>     Add 'Generic FLASH memory support'
>
>   Select Build->Packages
>     Add 'Common ethernet support'
>
>   Adjust platform details for EDB7212
>
> Or, just use the attached binary image

Thank you for your help and short response time, Gary,
I've built redboot.bin using the indications for ConfigTool
(windows based) you give, loaded it into the flash. To
test it I run an hyperterminal (bauds 34800, 8-n-1).
When I ureset+wakeup the board, the terminal remains
idle, and the diag1 led doesn't light on. When I use
the redboot_EDB7212_ROM.bin binary image you've
attached to your message instead, things get better (diag1
led lights on) but I get the following error message on my
hyperterminal screen:

 +
RedBoot(tm) debug environment - built 14:11:28, Oct 26 2000
Platform: Cirrus Logic EDB7212 (ARM 720T)
Copyright (C) 2000, Red Hat, Inc.

RAM: 0x00000000-0x00fd7000
FLASH: 0xe0000000 - 0xe1000000, 128 blocks of 0x00020000 bytes ea.
FLASH configuration checksum error or invalid key
Can't get BOOTP info - network disabled!
RedBoot>

Do you know what did I wrong?

In case this might help: if instead of running an hyperterminal, I use a cygwin
bash shell from which I run arm-elf-gdb I can
load and execute he hello test example correctly.

Fano

Re: [ECOS] network support

[Gary Thomas]

On 14-Feb-2001 Fano Ramparany wrote:
> Gary Thomas wrote:
> 
>> Using the ConfigTool
>>   Select Build->Templates
>>     Hardware Platform = Cirrus Logic Development Board
>>     Template = RedBoot
>>
>>   Select Build->Packages
>>     Add 'Generic FLASH memory support'
>>
>>   Select Build->Packages
>>     Add 'Common ethernet support'
>>
>>   Adjust platform details for EDB7212
>>
>> Or, just use the attached binary image
> 
> Thank you for your help and short response time, Gary,
> I've built redboot.bin using the indications for ConfigTool
> (windows based) you give, loaded it into the flash. To
> test it I run an hyperterminal (bauds 34800, 8-n-1).
> When I ureset+wakeup the board, the terminal remains
> idle, and the diag1 led doesn't light on. When I use
> the redboot_EDB7212_ROM.bin binary image you've
> attached to your message instead, things get better (diag1
> led lights on) but I get the following error message on my
> hyperterminal screen:
> 
>  +
> RedBoot(tm) debug environment - built 14:11:28, Oct 26 2000
> Platform: Cirrus Logic EDB7212 (ARM 720T)
> Copyright (C) 2000, Red Hat, Inc.
> 
> RAM: 0x00000000-0x00fd7000
> FLASH: 0xe0000000 - 0xe1000000, 128 blocks of 0x00020000 bytes ea.
> FLASH configuration checksum error or invalid key
> Can't get BOOTP info - network disabled!
> RedBoot>

This seems to be fine to me :-)

Now, you'll want to run the 'fconfig' command to set up your board's
environment, including setting the ethernet hardware address (ESA)
and IP selections.

In any case, you should be able to treat this just like you did the
simple stubs.  Connect via GDB and you're off.

> 
> Do you know what did I wrong?

Did you set the startup type to ROM?  This is not forced for RedBoot like
it would be for simple stubs (I forgot to mention it).

> 
> In case this might help: if instead of running an hyperterminal, I use a cygwin
> bash shell from which I run arm-elf-gdb I can
> load and execute he hello test example correctly.
> 
> Fano
> 

Re: [ECOS] network support

[Lewin A.R.W. Edwards]

Hello Gary,

> Now, you'll want to run the 'fconfig' command to set up your board's
> environment, including setting the ethernet hardware address (ESA)
> and IP selections.

I tried the redboot image you sent, out of interest. I hit similar problems to
Fano's when I tried building redboot using the patch you sent me. I think I probably
didn't change the startup type, but your image works fine of course so I won't
investigate that at this time.

I've got a couple of questions though:

I thought the MAC address was factory-programmed into the EEPROM that's attached to
the CS8900A Ethernet chip. Why does redboot require me to specify one manually? (I
have no idea what it is). If I put some garbage into that field, will redboot only
store that in its own local config info, or will it also trash the EEPROM that's on
the Crystal chip?

As yet I haven't got networking working, though it is building and loading OK.


-- Lewin A.R.W. Edwards (Embedded Engineer)              * Linux system
Work:     http://www.digi-frame.com/
Personal: http://www.larwe.com/ and http://www.zws.com/

Re: [ECOS] network support

[Gary Thomas]

On 14-Feb-2001 Lewin A.R.W. Edwards wrote:
> Hello Gary,
> 
> I thought the MAC address was factory-programmed into the EEPROM that's attached to
> the CS8900A Ethernet chip. Why does redboot require me to specify one manually? (I
> have no idea what it is). If I put some garbage into that field, will redboot only
> store that in its own local config info, or will it also trash the EEPROM that's on
> the Crystal chip?
> 

The EEPROM isn't really supported (contributions welcome, of course) because none
of the boards provided to us by Cirrus Logic has working EEPROMs on them.  In fact,
the boards I have have a totally incorrect chip soldered where the EEPROM belongs :-(

Re: [ECOS] network support

[Lewin A.R.W. Edwards]

> > I thought the MAC address was factory-programmed into the EEPROM that's 
> attached to
> > the CS8900A Ethernet chip. Why does redboot require me to specify one 
> manually? (I
>
>The EEPROM isn't really supported (contributions welcome, of course) 
>because none
>of the boards provided to us by Cirrus Logic has working EEPROMs on 
>them.  In fact,

Tres bizarre!

Am I correct in assuming then that I can choose any value I like, as long 
as it's unique?

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] network support

[Gary Thomas]

On 14-Feb-2001 Lewin A.R.W. Edwards wrote:
> 
> 
>> > I thought the MAC address was factory-programmed into the EEPROM that's 
>> attached to
>> > the CS8900A Ethernet chip. Why does redboot require me to specify one 
>> manually? (I
>>
>>The EEPROM isn't really supported (contributions welcome, of course) 
>>because none
>>of the boards provided to us by Cirrus Logic has working EEPROMs on 
>>them.  In fact,
> 
> Tres bizarre!
> 
> Am I correct in assuming then that I can choose any value I like, as long 
> as it's unique?

Yes.  In fact, it really only needs to be unique within your LAN, since
hardware addresses do not cross through gateways.

Re: [ECOS] network support

[Robin Farine]

Hi Lewin,

> On 14-Feb-2001 Lewin A.R.W. Edwards wrote:
> > 
> > 
> >> > I thought the MAC address was factory-programmed into the EEPROM that's 
> >> attached to
> >> > the CS8900A Ethernet chip. Why does redboot require me to specify one 
> >> manually? (I
> >>
> >>The EEPROM isn't really supported (contributions welcome, of course) 
> >>because none
> >>of the boards provided to us by Cirrus Logic has working EEPROMs on 
> >>them.  In fact,
> > 
> > Tres bizarre!
> > 
> > Am I correct in assuming then that I can choose any value I like, as long 
> > as it's unique?
> 
> Yes.  In fact, it really only needs to be unique within your LAN, since
> hardware addresses do not cross through gateways.

But be sure to set the two least significant bits as zeros! For instance, a MAC
address such as 05:10:20:30:40:50 would cause some problems because of the 05
that means a group address.

Re: [ECOS] network support

[Fano Ramparany]

Gary Thomas wrote:

> > I've built redboot.bin using the indications for ConfigTool
> > (windows based) you give, loaded it into the flash. To
> > test it I run an hyperterminal (bauds 34800, 8-n-1).
> > When I ureset+wakeup the board, the terminal remains
> > idle, and the diag1 led doesn't light on. ...
> >
> > Do you know what did I wrong?
>
> Did you set the startup type to ROM?  This is not forced for RedBoot like
> it would be for simple stubs (I forgot to mention it).

You're right, I changed the startup type from RAM to ROM, and this worked
fine.

Thank you

Fano

Re: [ECOS] network support

[Fano Ramparany]

Gary Thomas wrote:

> Here's the very simplest way to test this (using ecosconfig).
>
>   [gthomas@hermes test2]$ ecosconfig new edb7212 net
>   [gthomas@hermes test2]$ ecosconfig tree
>   [gthomas@hermes test2]$ make;make -C net/tcpip/current/ tests TESTS=tests/ping_test
>
> Similar results can be obtained by just using the "net" template and
> then enabling/building tests.
>
> Does this sequence [scenario] not work for you?

I guess this is the linux scenario. We use the Windows eCos develt environment.
Thus we have registered the network support package using the eCos Package
administration tool, added the network package using the Configuration tool.
We have ticked the INET support option and left all other options as they
as set by default ("Use BOOTP/DHCP to initial 'eth0'. The same for 'eth1').
Then we build the library and the tests.
When running the ping_test we get the following trace, which I think missed
the ping session information:

...
Loading section .rom_vectors, size 0x60 lma 0x8000
Loading section .text, size 0x25b0c lma 0x8060
Loading section .rodata, size 0x14b2 lma 0x2db6c
Loading section .data, size 0xb60 lma 0x2f020
Start address 0x8060 , load size 162686
Transfer rate: 27691 bits/sec, 305 bytes/write.
(gdb) break cyg_test_exit
Breakpoint 1 at 0x8558: file
//C/PROGRA~1/REDHAT~1/eCos/packages/net/tcpip/v1_0b1/tests/ping_test.c, line 74.
(gdb) break cyg_assert_fail
Function "cyg_assert_fail" not defined.
(gdb) break cyg_test_init
Function "cyg_test_init" not defined.
(gdb) cont
Continuing.
Network stack using 65536 bytes for misc space
                    65536 bytes for mbufs
                    131072 bytes for mbuf clusters
Start PING test
... Done

Breakpoint 1, cyg_test_exit ()
    at //C/PROGRA~1/REDHAT~1/eCos/packages/net/tcpip/v1_0b1/tests/ping_test.c:74
74          while (1) ;
(gdb) set cyg_test_is_simulator=0
No symbol "cyg_test_is_simulator" in current context.
(gdb) cont
Continuing.

Breakpoint 1, cyg_test_exit ()
    at //C/PROGRA~1/REDHAT~1/eCos/packages/net/tcpip/v1_0b1/tests/ping_test.c:74
74          while (1) ;
(gdb) *** 15:39:38 Run complete

Re: [ECOS] Network Support

[Wendell Thompson]

Has anyone looked into porting the XINU stack to eCos? The license for XINU
allows free commercial use and it's well documented.

Wendell Thompson

-----Original Message-----
From: David J. Fiddes <D.J@fiddes.surfaid.org>
To: ecos-discuss@cygnus.com <ecos-discuss@cygnus.com>
Date: Wednesday, February 10, 1999 3:23 PM
Subject: RE: [ECOS] Network Support


>Hi,
>
>> Does this mean that there is *no* IP support is eCOS?
>> I amplanning on making extensive use of the networking
>> capabilities of the MPC860T. Does this mean purchasing
>> commercial stacks?
>>
>> Has anyone ever done this?
>
>I know this is the wrong forum but....
>
>RTEMS (the first(?) Open Source RTOS ;) has a decent TCP/IP stack... and
has
>a *LOT* of MPC860 people using it. I don't think that anyone has released a
>BSP for a generic MPC860 board but I'm sure that getting one together is
not
>that tough.
>As far as RTOSs go RTEMS is somewhere between eCos and a larger RTOS like
>vxworks for features. Have a look at http://www.oarcorp.com/ for details.
>
>Dave
>
>

Re: [ECOS] Network Support

[Rick Leir]

I would look at the code in FreeBSD, or a derivative called PicoBSD.
Get there via www.freebsd.org.  The downside is that you might have to 
wade through all sorts of IPV6 and IPSec and Mbone stuff.  The upside 
is that you might need all that stuff!

cheers -- Rick

Wendell Thompson wrote:
> 
> Has anyone looked into porting the XINU stack to eCos? The license for XINU
> allows free commercial use and it's well documented.
> 
> Wendell Thompson
> 
> -----Original Message-----
> From: David J. Fiddes <D.J@fiddes.surfaid.org>
> >> Does this mean that there is *no* IP support is eCOS?
> >> I amplanning on making extensive use of the networking

-- 
Rick Leir,  Hymarc 3D Vision Systems      (613) 727 1584 x214
Fast, precise laser scanners.             http://www.hymarc.com/

RE: [ECOS] Network Support

[David J. Fiddes]

Hi,

> I would look at the code in FreeBSD, or a derivative called PicoBSD.
> Get there via www.freebsd.org.  The downside is that you might have to
> wade through all sorts of IPV6 and IPSec and Mbone stuff.  The upside
> is that you might need all that stuff!

The RTEMS port of the FreeBSD stack wasn't too tough to do(although I didn't
do it :). It performs extremely well... A eCos port would probably be quite
easy.

Dave

Re: [ECOS] Network Support

[Gordon McFadden]

On Sat, 6 Feb 1999 weatp@syntron.com wrote:
> 
>      Any idea when we are likely to see some network support in eCOS? 
>      Specifically, a UDP/TCP sockets layer.
>      
>      Thanks
>      Peter Weatherall
>      weatp@syntron.com
> 
> 


Hmmm...

Does this mean that there is *no* IP support is eCOS?
I amplanning on making extensive use of the networking 
capabilities of the MPC860T. Does this mean purchasing
commercial stacks?

Has anyone ever done this?

Gord
--
gmcfadden@westsoft-systems.com
http://www.westsoft-systems.com

Real Time Programming and System Development

RE: [ECOS] Network Support

[David J. Fiddes]

Hi,

> Does this mean that there is *no* IP support is eCOS?
> I amplanning on making extensive use of the networking
> capabilities of the MPC860T. Does this mean purchasing
> commercial stacks?
>
> Has anyone ever done this?

I know this is the wrong forum but....

RTEMS (the first(?) Open Source RTOS ;) has a decent TCP/IP stack... and has
a *LOT* of MPC860 people using it. I don't think that anyone has released a
BSP for a generic MPC860 board but I'm sure that getting one together is not
that tough.
As far as RTOSs go RTEMS is somewhere between eCos and a larger RTOS like
vxworks for features. Have a look at http://www.oarcorp.com/ for details.

Dave

Re: [ECOS] Network Support

[Brendan Simon]

"David J. Fiddes" wrote:

> I know this is the wrong forum but....
>
> RTEMS (the first(?) Open Source RTOS ;) has a decent TCP/IP stack... and has
> a *LOT* of MPC860 people using it. I don't think that anyone has released a
> BSP for a generic MPC860 board but I'm sure that getting one together is not
> that tough.
> As far as RTOSs go RTEMS is somewhere between eCos and a larger RTOS like
> vxworks for features. Have a look at http://www.oarcorp.com/ for details.
>
> Dave

Jay Monkman wrote a generic BSP for the 860 and was going to submit it OAR Corp
for inclusion with RTEMS 4.  I'm not sure if it ever made it.  I used his alpha
release with a pre-release beta RTEMS 4.  It worked after a bit of massaging.
He has a new one now but I haven't tried it.  Join the RTEMS mailing list (via
http://www.oarcorp.com ) if you want to discuss this further.

ftp://tempest.ece.uiuc.edu/pub/mpc860/rtems

Brendan Simon.

[ECOS] Network Support

[weatp]

     Any idea when we are likely to see some network support in eCOS? 
     Specifically, a UDP/TCP sockets layer.
     
     Thanks
     Peter Weatherall
     weatp@syntron.com

Re: [ECOS] Network Support

[Bart Veer]

>>>>> "weatp" == weatp  <weatp@syntron.com> writes:

    weatp> Any idea when we are likely to see some network support in
    weatp> eCOS? Specifically, a UDP/TCP sockets layer.
     
There has already been one port of a TCP/IP stack to eCos, done by
EBS, http://www.etcbin.com/ . This is a commercial product, not open
source. I suspect that some other stacks, both proprietary and open
source ones, will become available in due course.

Bart Veer // eCos net maintainer