RE: [ECOS] networking support for my eCos application

RE: [ECOS] networking support for my eCos application

[C B]

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


Wow.  Thanks for the quick response.

I'm using the 2.0 release of eCos, not the latest from CVS although I can easily switch if you think it may be part of my problem (or future ones...)

My exported config is attached.

Thanks,
Chris



> Date: Fri, 2 Nov 2007 12:41:25 -0600
> From: gary@mlbassoc.com
> To: csb_80@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] networking support for my eCos application
>
> C B wrote:
>> I'm new to eCos and am trying to get some simple networking capabilities into an application that I've inherited. The eCos configuration I have appears to have the networking package included and yet when I attempt to link my application against the eCos libs I get several 'undefined reference' type errors. In particular:
>>
>> undefined reference to 'init_all_network_interfaces'
>> undefined reference to 'eth0_up'
>> undefined reference to 'eth0_bootp_data'
>> undefined reference to 'inet_ntoa'
>>
>> It's some simple ftp client side stuff that is generating these errors but all I'd really like to be able to do is create and read data from a socket.
>>
>> I'm using the eCos Configuration Tool Version 2.11 in Windows XP and everything in the configuration builds fine. In the configuration view I have 'Basic networking framework' with 'INET support' checked under it, and 'OpenBSD TCP/IP Stack' and 'FTP client' also there.
>>
>> I've tried to provide the summary of what I'm doing but please ask if there is something I've left out that would be valuable. I've searched the archives and google'd a bunch but I'm unable to figure out a simple explanation for why the networking stuff doesn't seem to make it into my config.
>
> It doesn't look like the network has been configured.
>
> What eCos sources are you using (latest from anon CVS is recommended)
> Can you send your actual configuration? (use File->Export)
>
> Also, you probably should be using the FreeBSD network stack
> as the OpenBSD stack is very old and no longer maintained.
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook – together at last.  Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033

[-- Attachment #2: eCos_config.ecm --]
[-- Type: text/plain, Size: 9226 bytes --]

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    eb9261 ;
    template    eb9261-net ;
    package -hardware CYGPKG_HAL_ARM current ;
    package -hardware CYGPKG_HAL_ARM_AT91 current ;
    package -hardware CYGPKG_HAL_ARM_AT91SAM9261 current ;
    package -hardware CYGPKG_IO_SERIAL_ARM_AT91 current ;
    package -hardware CYGPKG_IO_SPI current ;
    package -hardware CYGPKG_DEVS_SPI_ARM_AT91 current ;
    package -hardware CYGPKG_DEVS_SPI_ARM_EB9261 current ;
    package -hardware CYGPKG_DEVS_AT45_DATAFLASH_SPI current ;
    package -hardware CYGPKG_DEVS_ETH_EB9261 current ;
    package -hardware CYGPKG_DEVS_ETH_DAVICOM_DM9000A current ;
    package -template CYGPKG_HAL current ;
    package -template CYGPKG_IO current ;
    package -template CYGPKG_IO_SERIAL current ;
    package -template CYGPKG_INFRA current ;
    package -template CYGPKG_ISOINFRA current ;
    package -template CYGPKG_KERNEL current ;
    package -template CYGPKG_MEMALLOC current ;
    package -template CYGPKG_LIBC current ;
    package -template CYGPKG_LIBC_TIME current ;
    package -template CYGPKG_LIBC_STDLIB current ;
    package -template CYGPKG_LIBC_STRING current ;
    package -template CYGPKG_LIBC_I18N current ;
    package -template CYGPKG_LIBC_SETJMP current ;
    package -template CYGPKG_LIBC_STARTUP current ;
    package -template CYGPKG_LIBC_STDIO current ;
    package -template CYGPKG_LIBM current ;
    package -template CYGPKG_POSIX current ;
    package -template CYGPKG_IO_WATCHDOG current ;
    package -template CYGPKG_IO_WALLCLOCK current ;
    package -template CYGPKG_ERROR current ;
    package -template CYGPKG_IO_FILEIO current ;
    package -template CYGPKG_NET current ;
    package -template CYGPKG_NET_OPENBSD_STACK current ;
    package -template CYGPKG_IO_ETH_DRIVERS current ;
    package -template CYGPKG_NET_FTPCLIENT current ;
    package -template CYGPKG_CPULOAD current ;
};

cdl_option CYGSEM_HAL_INSTALL_MMU_TABLES {
    user_value 0
};

cdl_component CYGDBG_HAL_DIAG_TO_DEBUG_CHAN {
    user_value 0
    inferred_value 0
};

cdl_component CYGSEM_HAL_ENABLE_DCACHE_ON_STARTUP {
    inferred_value 0
};

cdl_option CYGSEM_HAL_ENABLE_ICACHE_ON_STARTUP {
    inferred_value 0
};

cdl_option CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT {
    inferred_value 0
};

cdl_option CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT {
    inferred_value 0
};

cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE {
    user_value 1
};

cdl_option CYGSEM_HAL_USE_ROM_MONITOR {
    user_value 1 GDB_stubs
    inferred_value 0 ""
};

cdl_option CYGHWR_HAL_ARM_AT91_FIQ {
    user_value 1
    inferred_value 1
};

cdl_option CYGBLD_HAL_ARM_AT91_TIMER_TC {
    inferred_value 0
};

cdl_option CYGBLD_HAL_ARM_AT91_TIMER_PIT {
    inferred_value 1
};

cdl_option CYGBLD_HAL_ARM_AT91_SERIAL_DBG {
    inferred_value 1
};

cdl_option CYGBLD_HAL_ARM_AT91_SERIAL_UART {
    inferred_value 0
};

cdl_component CYG_HAL_STARTUP {
    user_value RAM
    inferred_value ROMRAM
};

cdl_component CYGPKG_IO_SERIAL_DEVICES {
    inferred_value 1
};

cdl_option CYGBLD_ISO_CTYPE_HEADER {
    inferred_value 1 <cyg/libc/i18n/ctype.inl>
};

cdl_option CYGBLD_ISO_ERRNO_CODES_HEADER {
    inferred_value 1 <cyg/error/codes.h>
};

cdl_option CYGBLD_ISO_ERRNO_HEADER {
    inferred_value 1 <cyg/error/errno.h>
};

cdl_option CYGBLD_ISO_STDIO_FILETYPES_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_STREAMS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FILEOPS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FILEACCESS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FORMATTED_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_CHAR_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_DIRECT_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FILEPOS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_ERROR_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDLIB_STRCONV_HEADER {
    inferred_value 1 <cyg/libc/stdlib/atox.inl>
};

cdl_option CYGBLD_ISO_STDLIB_ABS_HEADER {
    inferred_value 1 <cyg/libc/stdlib/abs.inl>
};

cdl_option CYGBLD_ISO_STDLIB_DIV_HEADER {
    inferred_value 1 <cyg/libc/stdlib/div.inl>
};

cdl_option CYGBLD_ISO_STRERROR_HEADER {
    inferred_value 1 <cyg/error/strerror.h>
};

cdl_option CYGBLD_ISO_STRTOK_R_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_LOCALE_FUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_BSD_FUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/bsdstring.h>
};

cdl_option CYGBLD_ISO_STRING_MEMFUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_STRFUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRUCTTIMEVAL_HEADER {
    inferred_value 1 <cyg/posix/sys/time.h>
};

cdl_option CYGBLD_ISO_POSIX_TIMER_TYPES_HEADER {
    inferred_value 1 <cyg/posix/time.h>
};

cdl_option CYGBLD_ISO_POSIX_CLOCK_TYPES_HEADER {
    inferred_value 1 <cyg/posix/time.h>
};

cdl_option CYGBLD_ISO_C_TIME_TYPES_HEADER {
    inferred_value 1 <cyg/libc/time/time.h>
};

cdl_option CYGBLD_ISO_POSIX_TIMERS_HEADER {
    inferred_value 1 <cyg/posix/time.h>
};

cdl_option CYGBLD_ISO_POSIX_CLOCKS_HEADER {
    inferred_value 1 <cyg/posix/time.h>
};

cdl_option CYGBLD_ISO_C_CLOCK_FUNCS_HEADER {
    inferred_value 1 <cyg/libc/time/time.h>
};

cdl_option CYGBLD_ISO_SIGNAL_NUMBERS_HEADER {
    inferred_value 1 <cyg/posix/signal.h>
};

cdl_option CYGBLD_ISO_SIGNAL_IMPL_HEADER {
    inferred_value 1 <cyg/posix/signal.h>
};

cdl_option CYGBLD_ISO_SETJMP_HEADER {
    inferred_value 1 <cyg/libc/setjmp/setjmp.h>
};

cdl_option CYGBLD_ISO_SIGSETJMP_HEADER {
    inferred_value 1 <cyg/posix/sigsetjmp.h>
};

cdl_option CYGBLD_ISO_DIRENT_HEADER {
    inferred_value 1 <cyg/fileio/dirent.h>
};

cdl_option CYGBLD_ISO_PTHREADTYPES_HEADER {
    inferred_value 1 <cyg/posix/types.h>
};

cdl_option CYGBLD_ISO_PMUTEXTYPES_HEADER {
    inferred_value 1 <cyg/posix/muttypes.h>
};

cdl_option CYGBLD_ISO_BSDTYPES_HEADER {
    inferred_value 1 <sys/bsdtypes.h>
};

cdl_option CYGBLD_ISO_UTSNAME_HEADER {
    inferred_value 1 <cyg/posix/utsname.h>
};

cdl_option CYGBLD_ISO_SEMAPHORES_HEADER {
    inferred_value 1 <cyg/posix/semaphore.h>
};

cdl_option CYGBLD_ISO_PTHREAD_IMPL_HEADER {
    inferred_value 1 <cyg/posix/pthread.h>
};

cdl_option CYGBLD_ISO_PTHREAD_MUTEX_HEADER {
    inferred_value 1 <cyg/posix/mutex.h>
};

cdl_option CYGBLD_ISO_POSIX_LIMITS_HEADER {
    inferred_value 1 <cyg/posix/limits.h>
};

cdl_option CYGBLD_ISO_OPEN_MAX_HEADER {
    inferred_value 1 <cyg/fileio/limits.h>
};

cdl_option CYGBLD_ISO_NAME_MAX_HEADER {
    inferred_value 1 <cyg/fileio/limits.h>
};

cdl_option CYGBLD_ISO_DNS_HEADER {
    inferred_value 1 <cyg/ns/dns/dns.h>
};

cdl_option CYGBLD_ISO_NETDB_PROTO_HEADER {
    inferred_value 1 <net/netdb.h>
};

cdl_option CYGBLD_ISO_NETDB_SERV_HEADER {
    inferred_value 1 <net/netdb.h>
};

cdl_option CYGIMP_KERNEL_SCHED_SORTED_QUEUES {
    inferred_value 1
};

cdl_option CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE {
    inferred_value 1
};

cdl_component CYGSEM_KERNEL_SCHED_ASR_SUPPORT {
    inferred_value 1
};

cdl_option CYGSEM_KERNEL_SCHED_ASR_GLOBAL {
    inferred_value 1
};

cdl_component CYGPKG_KERNEL_THREADS_DESTRUCTORS {
    inferred_value 1
};

cdl_option CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT {
    inferred_value 0
};

cdl_component CYGPKG_NET_TFTP {
    user_value 0
};

cdl_component CYGPKG_NET_DHCP {
    user_value 0
};

cdl_component CYGHWR_NET_DRIVER_ETH0_MANUAL {
    user_value 0
};

cdl_component CYGHWR_NET_DRIVER_ETH0_BOOTP {
    user_value 0
};

cdl_component CYGHWR_NET_DRIVER_ETH0_ADDRS {
    user_value 1
};

cdl_option CYGHWR_NET_DRIVER_ETH0_ADDRS_IP {
    user_value 10.1.4.3
};

cdl_option CYGHWR_NET_DRIVER_ETH0_ADDRS_BROADCAST {
    user_value 10.1.4.255
};

cdl_option CYGHWR_NET_DRIVER_ETH0_ADDRS_GATEWAY {
    user_value 10.1.4.1
};

cdl_option CYGHWR_NET_DRIVER_ETH0_ADDRS_SERVER {
    user_value 10.1.4.1
};



[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] networking support for my eCos application

[Gary Thomas]

C B wrote:
> Wow.  Thanks for the quick response.
> 
> I'm using the 2.0 release of eCos, not the latest from CVS although I can easily switch if you think it may be part of my problem (or future ones...)

Yes, I would definitely suggest that you update to the CVS tree
(release 2.0 is nearing 5 years old!)

Once you've done that, I'd also suggest that you try some simple
things.  This sequence should work and generate a test that you
can try on your hardware:
  % ecosconfig new eb9261 net
  % ecosconfig tree
  % make; make -C net/common/current tests TESTS=tests/ping_test

Note: it's not clear to me why your tree has its own 'eb9261-net'
template as this should not be necessary.  Using .ecm files is
a much better approach.

n.b. of course you can do the steps above using the config tool,
but using ecosconfig is much more concise and easier to explain :-)

>> Date: Fri, 2 Nov 2007 12:41:25 -0600
>> From: gary@mlbassoc.com
>> To: csb_80@hotmail.com
>> CC: ecos-discuss@ecos.sourceware.org
>> Subject: Re: [ECOS] networking support for my eCos application
>>
>> C B wrote:
>>> I'm new to eCos and am trying to get some simple networking capabilities into an application that I've inherited. The eCos configuration I have appears to have the networking package included and yet when I attempt to link my application against the eCos libs I get several 'undefined reference' type errors. In particular:
>>>
>>> undefined reference to 'init_all_network_interfaces'
>>> undefined reference to 'eth0_up'
>>> undefined reference to 'eth0_bootp_data'
>>> undefined reference to 'inet_ntoa'
>>>
>>> It's some simple ftp client side stuff that is generating these errors but all I'd really like to be able to do is create and read data from a socket.
>>>
>>> I'm using the eCos Configuration Tool Version 2.11 in Windows XP and everything in the configuration builds fine. In the configuration view I have 'Basic networking framework' with 'INET support' checked under it, and 'OpenBSD TCP/IP Stack' and 'FTP client' also there.
>>>
>>> I've tried to provide the summary of what I'm doing but please ask if there is something I've left out that would be valuable. I've searched the archives and google'd a bunch but I'm unable to figure out a simple explanation for why the networking stuff doesn't seem to make it into my config.
>> It doesn't look like the network has been configured.
>>
>> What eCos sources are you using (latest from anon CVS is recommended)
>> Can you send your actual configuration? (use File->Export)
>>
>> Also, you probably should be using the FreeBSD network stack
>> as the OpenBSD stack is very old and no longer maintained.


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

RE: [ECOS] networking support for my eCos application

[C B]

Gary,

I think I'm missing something here.  I checked out the latest from CVS without any issues but when I tried 'ecosconfig new eb9261 net' I got a bunch of warnings about version subdirectory 'XXX' does not have a CDL script and no valid version subdirectories and finally and error 'Unknown target eb9261'  (out is included below).
 
I tried configuring things with configtool and that was even more confusing.  I tried building a template based on an ARM eval board (PID) but it wouldn't let me add any packages to the template (e.g. AT91 ethernet driver) nor was there any obvious way to create a new template.  The error I got when trying to add a package was 'add and remove hardware packages by selecting a new hardware template'.
 
I also notice that trying to create a new platform with configtool provides a dialog box with several fields but regardless of what I fill in the ok button is never enabled.
 
I was just hoping to be able to create an eCos configuration for an ARM 9 based evaluation board but I seem to be missing something fundamental in how these things are setup.  Is there any documentation that takes a new user through the process?
 
Thanks,
Chris
 
----------- part of the output from 'ecosconfig new eb9261 net' ---------------------
 
ecos.db, package CYGPKG_HAL: warning
    Version subdirectory `common' does not have a CDL script `hal.cdl'.
ecos.db, package CYGPKG_HAL: warning
    This package does not have any valid version subdirectories.
ecos.db, package CYGPKG_INFRA: warning
    Version subdirectory `infra' does not have a CDL script `infra.cdl'.
ecos.db, package CYGPKG_INFRA: warning
    This package does not have any valid version subdirectories.
ecos.db, package CYGPKG_IO: warning
    Version subdirectory `common' does not have a CDL script `io.cdl'.
ecos.db, package CYGPKG_IO: warning
    This package does not have any valid version subdirectories.
ecos.db, package CYGPKG_IO_SERIAL: warning
    Version subdirectory `serial' does not have a CDL script `io_serial.cdl'.
ecos.db, package CYGPKG_IO_SERIAL: warning
    This package does not have any valid version subdirectories.
ecos.db, package CYGPKG_IO_CAN: warning
    Version subdirectory `can' does not have a CDL script `io_can.cdl'.
...
...
(a bunch more in here I've removed for brevity)
...
...
ecos.db, package CYGPKG_FS_FAT: warning
    Version subdirectory `fat' does not have a CDL script `fatfs.cdl'.
ecos.db, package CYGPKG_FS_FAT: warning
    This package does not have any valid version subdirectories.
ecos.db, package CYGPKG_NET_LWIP: warning
    Version subdirectory `lwip_tcpip' does not have a CDL script `cdl/lwip_net.cdl'.
ecos.db, package CYGPKG_NET_LWIP: warning
    This package does not have any valid version subdirectories.
ecos.db, package CYGPKG_ATHTTPD: warning
    Version subdirectory `athttpd' does not have a CDL script `httpd.cdl'.
ecos.db, package CYGPKG_ATHTTPD: warning
    This package does not have any valid version subdirectories.
Unknown target eb9261

 
 
----------------------- end output ------------------------------------------



> Date: Fri, 2 Nov 2007 13:07:44 -0600
> From: gary@mlbassoc.com
> To: csb_80@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] networking support for my eCos application
>
> C B wrote:
>> Wow. Thanks for the quick response.
>>
>> I'm using the 2.0 release of eCos, not the latest from CVS although I can easily switch if you think it may be part of my problem (or future ones...)
>
> Yes, I would definitely suggest that you update to the CVS tree
> (release 2.0 is nearing 5 years old!)
>
> Once you've done that, I'd also suggest that you try some simple
> things. This sequence should work and generate a test that you
> can try on your hardware:
> % ecosconfig new eb9261 net
> % ecosconfig tree
> % make; make -C net/common/current tests TESTS=tests/ping_test
>
> Note: it's not clear to me why your tree has its own 'eb9261-net'
> template as this should not be necessary. Using .ecm files is
> a much better approach.
>
> n.b. of course you can do the steps above using the config tool,
> but using ecosconfig is much more concise and easier to explain :-)
>
>>> Date: Fri, 2 Nov 2007 12:41:25 -0600
>>> From: gary@mlbassoc.com
>>> To: csb_80@hotmail.com
>>> CC: ecos-discuss@ecos.sourceware.org
>>> Subject: Re: [ECOS] networking support for my eCos application
>>>
>>> C B wrote:
>>>> I'm new to eCos and am trying to get some simple networking capabilities into an application that I've inherited. The eCos configuration I have appears to have the networking package included and yet when I attempt to link my application against the eCos libs I get several 'undefined reference' type errors. In particular:
>>>>
>>>> undefined reference to 'init_all_network_interfaces'
>>>> undefined reference to 'eth0_up'
>>>> undefined reference to 'eth0_bootp_data'
>>>> undefined reference to 'inet_ntoa'
>>>>
>>>> It's some simple ftp client side stuff that is generating these errors but all I'd really like to be able to do is create and read data from a socket.
>>>>
>>>> I'm using the eCos Configuration Tool Version 2.11 in Windows XP and everything in the configuration builds fine. In the configuration view I have 'Basic networking framework' with 'INET support' checked under it, and 'OpenBSD TCP/IP Stack' and 'FTP client' also there.
>>>>
>>>> I've tried to provide the summary of what I'm doing but please ask if there is something I've left out that would be valuable. I've searched the archives and google'd a bunch but I'm unable to figure out a simple explanation for why the networking stuff doesn't seem to make it into my config.
>>> It doesn't look like the network has been configured.
>>>
>>> What eCos sources are you using (latest from anon CVS is recommended)
>>> Can you send your actual configuration? (use File->Export)
>>>
>>> Also, you probably should be using the FreeBSD network stack
>>> as the OpenBSD stack is very old and no longer maintained.
>
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews

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

Re: [ECOS] networking support for my eCos application

[Andrew Lunn]

On Mon, Nov 05, 2007 at 11:10:59AM -0500, C B wrote:
> 
> 
> Gary,
> 
> I think I'm missing something here.  I checked out the latest from
> CVS without any issues but when I tried 'ecosconfig new eb9261 net'
> I got a bunch of warnings about version subdirectory 'XXX' does not
> have a CDL script and no valid version subdirectories and finally
> and error 'Unknown target eb9261' (out is included below).

That is probably to do with incompatibilities with the cygwin you have
and the config tool. Grab the latest snapshot from the eCosCentric.com
DevZone.
  
> I tried configuring things with configtool and that was even more
> confusing.  I tried building a template based on an ARM eval board
> (PID) but it wouldn't let me add any packages to the template
> (e.g. AT91 ethernet driver) nor was there any obvious way to create
> a new template.  The error I got when trying to add a package was
> 'add and remove hardware packages by selecting a new hardware
> template'.

You are not allowed to add hardware packages to a target. The AT91 eth
driver would not work with the PID, since it is for the on chip
ethernet you find in the AT91SAM7 devices. This is one reason adding
hardware packages are not allowed!
  
> I also notice that trying to create a new platform with configtool
> provides a dialog box with several fields but regardless of what I
> fill in the ok button is never enabled.

I don't use the config tool, but i don't see how that can work. You
need to edit the ecos.db and add a new target. Use the others as an
example.

> I was just hoping to be able to create an eCos configuration for an
> ARM 9 based evaluation board but I seem to be missing something
> fundamental in how these things are setup.  Is there any
> documentation that takes a new user through the process?

Look at the section:

target integrator_arm9

for an ARM9 example.

    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

Re: [ECOS] networking support for my eCos application

[Andrew Lunn]

On Mon, Nov 05, 2007 at 10:53:52PM -0500, C B wrote:
> 
> > Date: Mon, 5 Nov 2007 19:42:57 +0100> From: andrew@lunn.ch> To: csb_80@hotmail.com> CC: ecos-discuss@ecos.sourceware.org> Subject: Re: [ECOS] networking support for my eCos application> >
> > > I think I'm missing something here. I checked out the latest from> > CVS without any issues but when I tried 'ecosconfig new eb9261 net'> > I got a bunch of warnings about version subdirectory 'XXX' does not> > have a CDL script and no valid version subdirectories and finally> > and error 'Unknown target eb9261' (out is included below).> > That is probably to do with incompatibilities with the cygwin you have> and the config tool. Grab the latest snapshot from the eCosCentric.com> DevZone.
>  
> Thanks for your response Andrew.  Once I get past these initial configuration issues I'm looking forward to working with eCos.
>  
> Even running this on a linux VM I get the unknown target error.  Am I missing a step in setting up a new target?

eb9261 is not a target in anonymous cvs. You said you inherited this
code from somebody else. My guess is she has added a new target to
ecos.db and some new packages into the tree.

The easiest way forward is to copy these packages into your anonymous
CVS checkout and add the target entry to the ecos.db.

    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

RE: [ECOS] networking support for my eCos application

[C B]

> Yes, I would definitely suggest that you update to the CVS tree
> (release 2.0 is nearing 5 years old!)
>
> Once you've done that, I'd also suggest that you try some simple
> things. This sequence should work and generate a test that you
> can try on your hardware:
> % ecosconfig new eb9261 net
> % ecosconfig tree
> % make; make -C net/common/current tests TESTS=tests/ping_test

Thanks for your help (Andrew & Gary).  I think I'm getting closer.

I got the latest eCos from CVS and the latest configtool & ecosconfig from ecoscentric.com.  I copied the relevant hardware info from the ecos.db that I have to the one I checked out of CVS.  I'm able to succesfully perform each of the commands above.

But, when I try to compile and link my own code I still get these undefined references when I try to link with the eCos libs I've built:

 >>> undefined reference to 'init_all_network_interfaces'
 >>> undefined reference to 'eth0_up'
 >>> undefined reference to 'eth0_bootp_data'
 >>> undefined reference to 'inet_ntoa'

The command that gives those errors:
     arm-elf-ld -L"C:\cygwin\opt\ecos\ecos-cvs\tmp\install\lib" -L"C:\cygwin\opt\ecos\ecos-cvs\tmp\net\common\current" -L"C:\cygwin\opt\ecos\gnutools\arm-elf\arm-elf\lib" -L"C:\cygwin\opt\ecos\gnutools\arm-elf\lib\gcc-lib\arm-elf\3.2.1" -Ttarget.ld  -o"Simple.exe"  ./simple.o

The ping_test calls init_all_network_interfaces() so I'm not sure why it's not found.

Chris



_________________________________________________________________
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews

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

Re: [ECOS] networking support for my eCos application

[Andrew Lunn]

On Thu, Nov 08, 2007 at 03:00:59PM -0500, C B wrote:
> 
> 
> > Yes, I would definitely suggest that you update to the CVS tree
> > (release 2.0 is nearing 5 years old!)
> >
> > Once you've done that, I'd also suggest that you try some simple
> > things. This sequence should work and generate a test that you
> > can try on your hardware:
> > % ecosconfig new eb9261 net
> > % ecosconfig tree
> > % make; make -C net/common/current tests TESTS=tests/ping_test
> 
> Thanks for your help (Andrew & Gary).  I think I'm getting closer.
> 
> I got the latest eCos from CVS and the latest configtool &
> ecosconfig from ecoscentric.com.  I copied the relevant hardware
> info from the ecos.db that I have to the one I checked out of CVS.
> I'm able to succesfully perform each of the commands above.
> 
> But, when I try to compile and link my own code I still get these
> undefined references when I try to link with the eCos libs I've
> built:
>  >>> undefined reference to 'init_all_network_interfaces'
>  >>> undefined reference to 'eth0_up'
>  >>> undefined reference to 'eth0_bootp_data'
>  >>> undefined reference to 'inet_ntoa'

It sounds like you don't have the CYGPKG_NET package in your
configuration. However that would be strange, the net template always
includes it.

Do an 

ecosconfig export foo.ecm

and post foo.ecm. 

Also check that net/common/current/src/inet_ntoa.c is getting
compiled and it is in the library install/lib/libtarget.a

    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

[ECOS] Re: networking support for my eCos application

[John Dallaway]

Chris

C B wrote:

> But, when I try to compile and link my own code I still get these undefined references when I try to link with the eCos libs I've built:
> 
>  >>> undefined reference to 'init_all_network_interfaces'
>  >>> undefined reference to 'eth0_up'
>  >>> undefined reference to 'eth0_bootp_data'
>  >>> undefined reference to 'inet_ntoa'
> 
> The command that gives those errors:
>      arm-elf-ld -L"C:\cygwin\opt\ecos\ecos-cvs\tmp\install\lib" -L"C:\cygwin\opt\ecos\ecos-cvs\tmp\net\common\current" -L"C:\cygwin\opt\ecos\gnutools\arm-elf\arm-elf\lib" -L"C:\cygwin\opt\ecos\gnutools\arm-elf\lib\gcc-lib\arm-elf\3.2.1" -Ttarget.ld  -o"Simple.exe"  ./simple.o
> 
> The ping_test calls init_all_network_interfaces() so I'm not sure why it's not found.

I suggest you look at the command line arguments which the eCos build
system used to successfully link the ping test. Try linking your own
code similarly at a command line prompt and, assuming the linker
succeeds, work backwards to see which switches make the difference.

For a start, you should be using "-nostdlib" in your link command and
you should need to explicitly reference only the lib directory in your
eCos install tree.

John Dallaway
eCosCentric Limited

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

[ECOS] RE: networking support for my eCos application

[C B]

Ugh.  I had somehow specified arm-elf-ld rather than arm-elf-gcc as the linker.  Using arm-elf-gcc fixed the problem.  Thanks again for everyone's help.
 
Chris



> Date: Fri, 9 Nov 2007 09:21:54 +0000
> From: jld@ecoscentric.com
> To: csb_80@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: networking support for my eCos application
>
> Chris
>
> C B wrote:
>
>> But, when I try to compile and link my own code I still get these undefined references when I try to link with the eCos libs I've built:
>>
>>>>> undefined reference to 'init_all_network_interfaces'
>>>>> undefined reference to 'eth0_up'
>>>>> undefined reference to 'eth0_bootp_data'
>>>>> undefined reference to 'inet_ntoa'
>>
>> The command that gives those errors:
>> arm-elf-ld -L"C:\cygwin\opt\ecos\ecos-cvs\tmp\install\lib" -L"C:\cygwin\opt\ecos\ecos-cvs\tmp\net\common\current" -L"C:\cygwin\opt\ecos\gnutools\arm-elf\arm-elf\lib" -L"C:\cygwin\opt\ecos\gnutools\arm-elf\lib\gcc-lib\arm-elf\3.2.1" -Ttarget.ld -o"Simple.exe" ./simple.o
>>
>> The ping_test calls init_all_network_interfaces() so I'm not sure why it's not found.
>
> I suggest you look at the command line arguments which the eCos build
> system used to successfully link the ping test. Try linking your own
> code similarly at a command line prompt and, assuming the linker
> succeeds, work backwards to see which switches make the difference.
>
> For a start, you should be using "-nostdlib" in your link command and
> you should need to explicitly reference only the lib directory in your
> eCos install tree.
>
> John Dallaway
> eCosCentric Limited

_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

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

RE: [ECOS] RE: networking support for my eCos application

[C B]

So of course once I was able to compile and link everything I attempted to run a simple HelloWorld program on my target hardware.

Using the older eCos config that I inherited I was able use arm-elf-egb to load the program and then execute it and view the output in RedBoot.  I tried following the same process only this time I compiled & linked against my new eCos config and I got no output.  I noticed that the older version was getting a different start address that than new and took a look at the target.ld files for each of the two and they were more different than I expected.  In particular I was surprised that the specification of the memory layout was

MEMORY
{
    ram : ORIGIN = 0x20000000, LENGTH = 0x00C00000
    rom : ORIGIN = 0x20C00000, LENGTH = 0x00400000
    sram : ORIGIN = 0x00000100, LENGTH = 0x00023F00
}

versus this for the older (working) version:

MEMORY
{
    ram : ORIGIN = 0x20000000, LENGTH = 0x02000000
    sram : ORIGIN = 0x00000000, LENGTH = 0x00024000
}


Can anyone provide a little clarification on how these files are generated and what I may have screwed up in my config.

Thank you.


> From: csb_80@hotmail.com
> To: jld@ecoscentric.com
> CC: ecos-discuss@ecos.sourceware.org
> Date: Fri, 9 Nov 2007 08:32:07 -0500
> Subject: [ECOS] RE: networking support for my eCos application
>
>
> Ugh. I had somehow specified arm-elf-ld rather than arm-elf-gcc as the linker. Using arm-elf-gcc fixed the problem. Thanks again for everyone's help.
>
> Chris
>
>
>
>> Date: Fri, 9 Nov 2007 09:21:54 +0000
>> From: jld@ecoscentric.com
>> To: csb_80@hotmail.com
>> CC: ecos-discuss@ecos.sourceware.org
>> Subject: Re: networking support for my eCos application
>>
>> Chris
>>
>> C B wrote:
>>
>>> But, when I try to compile and link my own code I still get these undefined references when I try to link with the eCos libs I've built:
>>>
>>>>>> undefined reference to 'init_all_network_interfaces'
>>>>>> undefined reference to 'eth0_up'
>>>>>> undefined reference to 'eth0_bootp_data'
>>>>>> undefined reference to 'inet_ntoa'
>>>
>>> The command that gives those errors:
>>> arm-elf-ld -L"C:\cygwin\opt\ecos\ecos-cvs\tmp\install\lib" -L"C:\cygwin\opt\ecos\ecos-cvs\tmp\net\common\current" -L"C:\cygwin\opt\ecos\gnutools\arm-elf\arm-elf\lib" -L"C:\cygwin\opt\ecos\gnutools\arm-elf\lib\gcc-lib\arm-elf\3.2.1" -Ttarget.ld -o"Simple.exe" ./simple.o
>>>
>>> The ping_test calls init_all_network_interfaces() so I'm not sure why it's not found.
>>
>> I suggest you look at the command line arguments which the eCos build
>> system used to successfully link the ping test. Try linking your own
>> code similarly at a command line prompt and, assuming the linker
>> succeeds, work backwards to see which switches make the difference.
>>
>> For a start, you should be using "-nostdlib" in your link command and
>> you should need to explicitly reference only the lib directory in your
>> eCos install tree.
>>
>> John Dallaway
>> eCosCentric Limited
>
> _________________________________________________________________
> Peek-a-boo FREE Tricks & Treats for You!
> http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook – together at last.  Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033

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

Re: [ECOS] RE: networking support for my eCos application

[Andrew Lunn]

> MEMORY
> {
>     ram : ORIGIN = 0x20000000, LENGTH = 0x00C00000
>     rom : ORIGIN = 0x20C00000, LENGTH = 0x00400000
>     sram : ORIGIN = 0x00000100, LENGTH = 0x00023F00
> }
> 
> versus this for the older (working) version:
> 
> MEMORY
> {
>     ram : ORIGIN = 0x20000000, LENGTH = 0x02000000
>     sram : ORIGIN = 0x00000000, LENGTH = 0x00024000
> }
> 
> 
> Can anyone provide a little clarification on how these files are generated and what I may have screwed up in my config.

The linker file is derived from you hal include/pkgconf/*.ldi files.

My guess is your working binary is a RAM startup application, but your
new application is a ROM startup. Take a look at the value of
CYG_HAL_STARTUP in your working and none working configuration.

                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

RE: [ECOS] RE: networking support for my eCos application

[C B]

Brilliant!  Changing the CYG_HAL_STARTUP to RAM seems to resolve the issue I was having.  However, rather than seeing the expected output from my simple HelloWorld program that I see with my older version of eCos I get the following output:

------------------------- begin output -------------------------
RedBoot> go 0x20020040
[cyg_net_init] Init: mbinit(0x00000000)
[cyg_net_init] Init: cyg_net_init_devs(0x00000000)
Init device 'dm9000_eth0'
-------------------------- end output ---------------------------

Thoughts?

Thanks again!


> Date: Fri, 9 Nov 2007 19:55:42 +0100
> From: andrew@lunn.ch
> To: csb_80@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] RE: networking support for my eCos application
>
>> MEMORY
>> {
>> ram : ORIGIN = 0x20000000, LENGTH = 0x00C00000
>> rom : ORIGIN = 0x20C00000, LENGTH = 0x00400000
>> sram : ORIGIN = 0x00000100, LENGTH = 0x00023F00
>> }
>>
>> versus this for the older (working) version:
>>
>> MEMORY
>> {
>> ram : ORIGIN = 0x20000000, LENGTH = 0x02000000
>> sram : ORIGIN = 0x00000000, LENGTH = 0x00024000
>> }
>>
>>
>> Can anyone provide a little clarification on how these files are generated and what I may have screwed up in my config.
>
> The linker file is derived from you hal include/pkgconf/*.ldi files.
>
> My guess is your working binary is a RAM startup application, but your
> new application is a ROM startup. Take a look at the value of
> CYG_HAL_STARTUP in your working and none working configuration.
>
> Andrew

_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook – together at last.  Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033

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

Re: [ECOS] RE: networking support for my eCos application

[Gary Thomas]

C B wrote:
> 
> Brilliant!  Changing the CYG_HAL_STARTUP to RAM seems to resolve the issue I was having.  However, rather than seeing the expected output from my simple HelloWorld program that I see with my older version of eCos I get the following output:
> 
> ------------------------- begin output -------------------------
> RedBoot> go 0x20020040
> [cyg_net_init] Init: mbinit(0x00000000)
> [cyg_net_init] Init: cyg_net_init_devs(0x00000000)
> Init device 'dm9000_eth0'
> -------------------------- end output ---------------------------
> 
> Thoughts?

How did you connect to RedBoot to initiate this session?  If it's
via the network, then you are probably experiencing problems due to
the fact that RedBoot and your application have to share the same
hardware.  If this is the case, you'll need (somehow) to arrange that
the RedBoot connection and your application use separate IP addresses
(this is part of how RedBoot can separate what traffic goes to the
debug session and what goes to the application).

Another problem which can come up [again when you connect to RedBoot
via network] is when the driver in the eCos application tries to print
debug messages *while the driver/hardware is being initialized*.  In
this case, it's wise to make sure that CYGPKG_NET_FORCE_SERIAL_CONSOLE
is set which will force any debug messages which happen during system
initialization to a serial console (keeps the RedBoot network driver
from getting confused).  Try running your application from a serial
console - if it works, then this is an issue for you.

> 
>> Date: Fri, 9 Nov 2007 19:55:42 +0100
>> From: andrew@lunn.ch
>> To: csb_80@hotmail.com
>> CC: ecos-discuss@ecos.sourceware.org
>> Subject: Re: [ECOS] RE: networking support for my eCos application
>>
>>> MEMORY
>>> {
>>> ram : ORIGIN = 0x20000000, LENGTH = 0x00C00000
>>> rom : ORIGIN = 0x20C00000, LENGTH = 0x00400000
>>> sram : ORIGIN = 0x00000100, LENGTH = 0x00023F00
>>> }
>>>
>>> versus this for the older (working) version:
>>>
>>> MEMORY
>>> {
>>> ram : ORIGIN = 0x20000000, LENGTH = 0x02000000
>>> sram : ORIGIN = 0x00000000, LENGTH = 0x00024000
>>> }
>>>
>>>
>>> Can anyone provide a little clarification on how these files are generated and what I may have screwed up in my config.
>> The linker file is derived from you hal include/pkgconf/*.ldi files.
>>
>> My guess is your working binary is a RAM startup application, but your
>> new application is a ROM startup. Take a look at the value of
>> CYG_HAL_STARTUP in your working and none working configuration.
>>
>> Andrew
> 
> _________________________________________________________________
> Windows Live Hotmail and Microsoft Office Outlook – together at last.  Get it now.
> http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033
> 


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

RE: [ECOS] RE: networking support for my eCos application

[C B]

I have been running via the console so hopefully this won't be an issue for me going forward.  I did find my problem and posted what I found.  Turns out that in porting over my older configs I didn't realize that the new var_io.h was redefining things I had already defined.
 
Thanks for the constructive feedback Gary!



> Date: Mon, 12 Nov 2007 05:27:01 -0700
> From: gary@mlbassoc.com
> To: csb_80@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] RE: networking support for my eCos application
>
> C B wrote:
>>
>> Brilliant! Changing the CYG_HAL_STARTUP to RAM seems to resolve the issue I was having. However, rather than seeing the expected output from my simple HelloWorld program that I see with my older version of eCos I get the following output:
>>
>> ------------------------- begin output -------------------------
>> RedBoot> go 0x20020040
>> [cyg_net_init] Init: mbinit(0x00000000)
>> [cyg_net_init] Init: cyg_net_init_devs(0x00000000)
>> Init device 'dm9000_eth0'
>> -------------------------- end output ---------------------------
>>
>> Thoughts?
>
> How did you connect to RedBoot to initiate this session? If it's
> via the network, then you are probably experiencing problems due to
> the fact that RedBoot and your application have to share the same
> hardware. If this is the case, you'll need (somehow) to arrange that
> the RedBoot connection and your application use separate IP addresses
> (this is part of how RedBoot can separate what traffic goes to the
> debug session and what goes to the application).
>
> Another problem which can come up [again when you connect to RedBoot
> via network] is when the driver in the eCos application tries to print
> debug messages *while the driver/hardware is being initialized*. In
> this case, it's wise to make sure that CYGPKG_NET_FORCE_SERIAL_CONSOLE
> is set which will force any debug messages which happen during system
> initialization to a serial console (keeps the RedBoot network driver
> from getting confused). Try running your application from a serial
> console - if it works, then this is an issue for you.
>
>>
>>> Date: Fri, 9 Nov 2007 19:55:42 +0100
>>> From: andrew@lunn.ch
>>> To: csb_80@hotmail.com
>>> CC: ecos-discuss@ecos.sourceware.org
>>> Subject: Re: [ECOS] RE: networking support for my eCos application
>>>
>>>> MEMORY
>>>> {
>>>> ram : ORIGIN = 0x20000000, LENGTH = 0x00C00000
>>>> rom : ORIGIN = 0x20C00000, LENGTH = 0x00400000
>>>> sram : ORIGIN = 0x00000100, LENGTH = 0x00023F00
>>>> }
>>>>
>>>> versus this for the older (working) version:
>>>>
>>>> MEMORY
>>>> {
>>>> ram : ORIGIN = 0x20000000, LENGTH = 0x02000000
>>>> sram : ORIGIN = 0x00000000, LENGTH = 0x00024000
>>>> }
>>>>
>>>>
>>>> Can anyone provide a little clarification on how these files are generated and what I may have screwed up in my config.
>>> The linker file is derived from you hal include/pkgconf/*.ldi files.
>>>
>>> My guess is your working binary is a RAM startup application, but your
>>> new application is a ROM startup. Take a look at the value of
>>> CYG_HAL_STARTUP in your working and none working configuration.
>>>
>>> Andrew
>>
>> _________________________________________________________________
>> Windows Live Hotmail and Microsoft Office Outlook – together at last. Get it now.
>> http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033
>>
>
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------

_________________________________________________________________
Help yourself to FREE treats served up daily at the Messenger Café. Stop by today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline

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

[ECOS] Adding xscale support to my eCos config

[C B]

  Coming from a long background developing Applications in Java to the embedded world is quite a switch so please bear with me.  I've got an eCos configuration working based on the latest from CVS for an ARM9 based target from Atmel.  I've written simple applications in C, linked against the eCos libs and successfully executed them on my target.  So, my question:  My target supports an extended DSP instruction set (xscale).  I see an xscale package in the eCos I've checked out but it is not clear to me how I get from my current eCos configuration to one in which I can make calls from my C application to make use of the xscale instruction set.  I would appreciate any hints.  Thanks!
_________________________________________________________________
Climb to the top of the charts!  Play Star Shuffle:  the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct

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

Re: [ECOS] Adding xscale support to my eCos config

[Andrew Lunn]

On Wed, Nov 14, 2007 at 08:19:46AM -0500, C B wrote:
> 
> 

> Coming from a long background developing Applications in Java to the
> embedded world is quite a switch so please bear with me.  I've got
> an eCos configuration working based on the latest from CVS for an
> ARM9 based target from Atmel.  I've written simple applications in
> C, linked against the eCos libs and successfully executed them on my
> target.  So, my question: My target supports an extended DSP
> instruction set (xscale).  I see an xscale package in the eCos I've
> checked out but it is not clear to me how I get from my current eCos
> configuration to one in which I can make calls from my C application
> to make use of the xscale instruction set.  I would appreciate any
> hints.  Thanks!

Isn't this just a compiler issue? So long as the compile knows you are
using an xscale with these extra instructions, it should use them.

Look what flags are passed to the compiler, in particular march. 

If you want to explicitly call these xscale instructions, you will
need to do inline/out of line assembly language programming, or find a
library from somewhere which has wrapped them up in something easier
to use.

   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

Re: [ECOS] Adding xscale support to my eCos config

[Mark Salter]

On Wed, 2007-11-14 at 14:30 +0100, Andrew Lunn wrote:
> On Wed, Nov 14, 2007 at 08:19:46AM -0500, C B wrote:
> > 
> > 
> 
> > Coming from a long background developing Applications in Java to the
> > embedded world is quite a switch so please bear with me.  I've got
> > an eCos configuration working based on the latest from CVS for an
> > ARM9 based target from Atmel.  I've written simple applications in
> > C, linked against the eCos libs and successfully executed them on my
> > target.  So, my question: My target supports an extended DSP
> > instruction set (xscale).  I see an xscale package in the eCos I've
> > checked out but it is not clear to me how I get from my current eCos
> > configuration to one in which I can make calls from my C application
> > to make use of the xscale instruction set.  I would appreciate any
> > hints.  Thanks!
> 
> Isn't this just a compiler issue? So long as the compile knows you are
> using an xscale with these extra instructions, it should use them.
> 

If you are referring to the MMX-like extensions on some XScale cpus,
then a properly configured toolchain will support those instructions
via gcc's vector instruction extensions. A prebuilt toolchain with
these capabilities can be found at:

 ftp://ftp.ges.redhat.com/private/gnupro-xscale-030422

That's an old toolchain, but the necessary bits were all contributed
upstream.

--Mark



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

RE: [ECOS] Adding xscale support to my eCos config

[C B]

Yes, I believe it should just be a compiler issue.

I'll have to look into the 'march' flag but I had tried to compile my application with -mcpu=xscale and I got an error message saying that libtarget.a uses FPA instructions where as my app uses VFP instructions.  So, I assumed I need to similarly modify how I build eCos but it's not clear to me at the moment where to make that change (at least within the configtool).


> Date: Wed, 14 Nov 2007 14:30:44 +0100
> From: andrew@lunn.ch
> To: csb_80@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] Adding xscale support to my eCos config
>
> On Wed, Nov 14, 2007 at 08:19:46AM -0500, C B wrote:
>>
>>
>
>> Coming from a long background developing Applications in Java to the
>> embedded world is quite a switch so please bear with me. I've got
>> an eCos configuration working based on the latest from CVS for an
>> ARM9 based target from Atmel. I've written simple applications in
>> C, linked against the eCos libs and successfully executed them on my
>> target. So, my question: My target supports an extended DSP
>> instruction set (xscale). I see an xscale package in the eCos I've
>> checked out but it is not clear to me how I get from my current eCos
>> configuration to one in which I can make calls from my C application
>> to make use of the xscale instruction set. I would appreciate any
>> hints. Thanks!
>
> Isn't this just a compiler issue? So long as the compile knows you are
> using an xscale with these extra instructions, it should use them.
>
> Look what flags are passed to the compiler, in particular march.
>
> If you want to explicitly call these xscale instructions, you will
> need to do inline/out of line assembly language programming, or find a
> library from somewhere which has wrapped them up in something easier
> to use.
>
> Andrew

_________________________________________________________________
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews

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

Re: [ECOS] Adding xscale support to my eCos config

[Gary Thomas]

C B wrote:
> 
> Yes, I believe it should just be a compiler issue.
> 
> I'll have to look into the 'march' flag but I had tried to compile my application with -mcpu=xscale and I got an error message saying that libtarget.a uses FPA instructions where as my app uses VFP instructions.  So, I assumed I need to similarly modify how I build eCos but it's not clear to me at the moment where to make that change (at least within the configtool).

Did you rebuild eCos using these same settings?

>> Date: Wed, 14 Nov 2007 14:30:44 +0100
>> From: andrew@lunn.ch
>> To: csb_80@hotmail.com
>> CC: ecos-discuss@ecos.sourceware.org
>> Subject: Re: [ECOS] Adding xscale support to my eCos config
>>
>> On Wed, Nov 14, 2007 at 08:19:46AM -0500, C B wrote:
>>>
>>> Coming from a long background developing Applications in Java to the
>>> embedded world is quite a switch so please bear with me. I've got
>>> an eCos configuration working based on the latest from CVS for an
>>> ARM9 based target from Atmel. I've written simple applications in
>>> C, linked against the eCos libs and successfully executed them on my
>>> target. So, my question: My target supports an extended DSP
>>> instruction set (xscale). I see an xscale package in the eCos I've
>>> checked out but it is not clear to me how I get from my current eCos
>>> configuration to one in which I can make calls from my C application
>>> to make use of the xscale instruction set. I would appreciate any
>>> hints. Thanks!
>> Isn't this just a compiler issue? So long as the compile knows you are
>> using an xscale with these extra instructions, it should use them.
>>
>> Look what flags are passed to the compiler, in particular march.
>>
>> If you want to explicitly call these xscale instructions, you will
>> need to do inline/out of line assembly language programming, or find a
>> library from somewhere which has wrapped them up in something easier
>> to use.
>>
>> Andrew

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

RE: [ECOS] Adding xscale support to my eCos config

[C B]

Yes, I rebuilt eCos with the same -mcpu=xscale option.


> Date: Wed, 14 Nov 2007 08:23:11 -0700
> From: gary@mlbassoc.com
> To: csb_80@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] Adding xscale support to my eCos config
>
> C B wrote:
>>
>> Yes, I believe it should just be a compiler issue.
>>
>> I'll have to look into the 'march' flag but I had tried to compile my application with -mcpu=xscale and I got an error message saying that libtarget.a uses FPA instructions where as my app uses VFP instructions. So, I assumed I need to similarly modify how I build eCos but it's not clear to me at the moment where to make that change (at least within the configtool).
>
> Did you rebuild eCos using these same settings?
>
>>> Date: Wed, 14 Nov 2007 14:30:44 +0100
>>> From: andrew@lunn.ch
>>> To: csb_80@hotmail.com
>>> CC: ecos-discuss@ecos.sourceware.org
>>> Subject: Re: [ECOS] Adding xscale support to my eCos config
>>>
>>> On Wed, Nov 14, 2007 at 08:19:46AM -0500, C B wrote:
>>>>
>>>> Coming from a long background developing Applications in Java to the
>>>> embedded world is quite a switch so please bear with me. I've got
>>>> an eCos configuration working based on the latest from CVS for an
>>>> ARM9 based target from Atmel. I've written simple applications in
>>>> C, linked against the eCos libs and successfully executed them on my
>>>> target. So, my question: My target supports an extended DSP
>>>> instruction set (xscale). I see an xscale package in the eCos I've
>>>> checked out but it is not clear to me how I get from my current eCos
>>>> configuration to one in which I can make calls from my C application
>>>> to make use of the xscale instruction set. I would appreciate any
>>>> hints. Thanks!
>>> Isn't this just a compiler issue? So long as the compile knows you are
>>> using an xscale with these extra instructions, it should use them.
>>>
>>> Look what flags are passed to the compiler, in particular march.
>>>
>>> If you want to explicitly call these xscale instructions, you will
>>> need to do inline/out of line assembly language programming, or find a
>>> library from somewhere which has wrapped them up in something easier
>>> to use.
>>>
>>> Andrew
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------

_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook – together at last.  Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033

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

RE: [ECOS] Adding xscale support to my eCos config

[C B]

Ugh.  For some reason the compile option I thought I had changed in configtool didn't stick.  Once I was able to stick it things seemed to work.


> From: csb_80@hotmail.com
> To: gary@mlbassoc.com
> CC: ecos-discuss@ecos.sourceware.org
> Date: Wed, 14 Nov 2007 11:15:36 -0500
> Subject: RE: [ECOS] Adding xscale support to my eCos config
>
>
> Yes, I rebuilt eCos with the same -mcpu=xscale option.
>
>
>> Date: Wed, 14 Nov 2007 08:23:11 -0700
>> From: gary@mlbassoc.com
>> To: csb_80@hotmail.com
>> CC: ecos-discuss@ecos.sourceware.org
>> Subject: Re: [ECOS] Adding xscale support to my eCos config
>>
>> C B wrote:
>>>
>>> Yes, I believe it should just be a compiler issue.
>>>
>>> I'll have to look into the 'march' flag but I had tried to compile my application with -mcpu=xscale and I got an error message saying that libtarget.a uses FPA instructions where as my app uses VFP instructions. So, I assumed I need to similarly modify how I build eCos but it's not clear to me at the moment where to make that change (at least within the configtool).
>>
>> Did you rebuild eCos using these same settings?
>>
>>>> Date: Wed, 14 Nov 2007 14:30:44 +0100
>>>> From: andrew@lunn.ch
>>>> To: csb_80@hotmail.com
>>>> CC: ecos-discuss@ecos.sourceware.org
>>>> Subject: Re: [ECOS] Adding xscale support to my eCos config
>>>>
>>>> On Wed, Nov 14, 2007 at 08:19:46AM -0500, C B wrote:
>>>>>
>>>>> Coming from a long background developing Applications in Java to the
>>>>> embedded world is quite a switch so please bear with me. I've got
>>>>> an eCos configuration working based on the latest from CVS for an
>>>>> ARM9 based target from Atmel. I've written simple applications in
>>>>> C, linked against the eCos libs and successfully executed them on my
>>>>> target. So, my question: My target supports an extended DSP
>>>>> instruction set (xscale). I see an xscale package in the eCos I've
>>>>> checked out but it is not clear to me how I get from my current eCos
>>>>> configuration to one in which I can make calls from my C application
>>>>> to make use of the xscale instruction set. I would appreciate any
>>>>> hints. Thanks!
>>>> Isn't this just a compiler issue? So long as the compile knows you are
>>>> using an xscale with these extra instructions, it should use them.
>>>>
>>>> Look what flags are passed to the compiler, in particular march.
>>>>
>>>> If you want to explicitly call these xscale instructions, you will
>>>> need to do inline/out of line assembly language programming, or find a
>>>> library from somewhere which has wrapped them up in something easier
>>>> to use.
>>>>
>>>> Andrew
>>
>> --
>> ------------------------------------------------------------
>> Gary Thomas | Consulting for the
>> MLB Associates | Embedded world
>> ------------------------------------------------------------
>
> _________________________________________________________________
> Windows Live Hotmail and Microsoft Office Outlook – together at last.  Get it now.
> http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
Climb to the top of the charts!  Play Star Shuffle:  the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct

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

[ECOS] Performance timing

[C B]

  I'm interested in collecting some performance measures on some of my own functions.  Are there some simple utilities or example for doing this or is looking at tm_basic.cxx the best bet?


_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

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

Re: [ECOS] Performance timing

[Gary Thomas]

C B wrote:
> 
>   I'm interested in collecting some performance measures on some of my own functions.  Are there some simple utilities or example for doing this or is looking at tm_basic.cxx the best bet?

It depends on the scope of what you want to measure.  The
techniques used by tm_basic are good for small things - those
that execute in less than a system tick (typically 10ms), but
using them requires some invasive changes (you have to explicitly
capture start and stop times for a function/segment, etc).

Alternatively, you can turn on system profiling.  All this
requires is a [fairly] high resolution timer and some RAM.
There is no need to modify your code directly.  The data
is gathered into a RAM buffer and then offloaded (the only
method for this currently uses the network and TFTP).  Once
you have the data off the box, it can be analyzed using
standard tools, such as 'gprof'

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

RE: [ECOS] Performance timing

[C B]

System profiling is probably what I need.

Unfortunately there isn't an implementation of the profiling timer for my target.  Any information or guidance available that you're aware of for implementing this?  For what it's worth, my target is a arm based SAM9 variant.

Thanks.


> Date: Fri, 16 Nov 2007 11:14:51 -0700
> From: gary@mlbassoc.com
> To: csb_80@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] Performance timing
>
> C B wrote:
>>
>> I'm interested in collecting some performance measures on some of my own functions. Are there some simple utilities or example for doing this or is looking at tm_basic.cxx the best bet?
>
> It depends on the scope of what you want to measure. The
> techniques used by tm_basic are good for small things - those
> that execute in less than a system tick (typically 10ms), but
> using them requires some invasive changes (you have to explicitly
> capture start and stop times for a function/segment, etc).
>
> Alternatively, you can turn on system profiling. All this
> requires is a [fairly] high resolution timer and some RAM.
> There is no need to modify your code directly. The data
> is gathered into a RAM buffer and then offloaded (the only
> method for this currently uses the network and TFTP). Once
> you have the data off the box, it can be analyzed using
> standard tools, such as 'gprof'
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------

_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook – together at last.  Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033

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

Re: [ECOS] Performance timing

[Mike Arthur]

On Nov 16, 2007 1:47 PM, C B <csb_80@hotmail.com> wrote:
>
> System profiling is probably what I need.
>
> Unfortunately there isn't an implementation of the profiling timer for my target.  Any information or guidance available that you're aware of for implementing this?

The eCos Reference Manual has this functionality documented:
http://ecos.sourceware.org/docs-latest/ref/gprof.html

It's pretty straight forward to implement with in your HAL.  You'll
need a spare hardware timer to use for your instrumentation.  Try
looking in other HALs that use the profile timer as an example.

You need to setup two functions to implement the profile instrumentation:
1.) int hal_enable_profile_timer(int resolution)
       * Initializes hardware timer and ISR.
2.) unsigned int profile_isr(CYG_ADDRWORD vector, CYG_ADDRWORD data,
HAL_SavedRegisters *regs)
      * Saves current program counter
      * Handles timer hardware

Good luck!
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

RE: [ECOS] Performance timing

[C B]

Thanks Mike.  That was very helpful.

I guess my hope that I'd be able to make a simple call to get the time before and after my timed event was a little naive... :)



> Date: Fri, 16 Nov 2007 13:55:28 -0600
> From: arth2219@gmail.com
> To: csb_80@hotmail.com
> Subject: Re: [ECOS] Performance timing
> CC: gary@mlbassoc.com; ecos-discuss@ecos.sourceware.org
>
> On Nov 16, 2007 1:47 PM, C B  wrote:
>>
>> System profiling is probably what I need.
>>
>> Unfortunately there isn't an implementation of the profiling timer for my target. Any information or guidance available that you're aware of for implementing this?
>
> The eCos Reference Manual has this functionality documented:
> http://ecos.sourceware.org/docs-latest/ref/gprof.html
>
> It's pretty straight forward to implement with in your HAL. You'll
> need a spare hardware timer to use for your instrumentation. Try
> looking in other HALs that use the profile timer as an example.
>
> You need to setup two functions to implement the profile instrumentation:
> 1.) int hal_enable_profile_timer(int resolution)
> * Initializes hardware timer and ISR.
> 2.) unsigned int profile_isr(CYG_ADDRWORD vector, CYG_ADDRWORD data,
> HAL_SavedRegisters *regs)
> * Saves current program counter
> * Handles timer hardware
>
> Good luck!
> Mike

_________________________________________________________________
Your smile counts. The more smiles you share, the more we donate.  Join in.
www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline

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

Re: [ECOS] Performance timing

[Gary Thomas]

C B wrote:
> Thanks Mike.  That was very helpful.
>
> I guess my hope that I'd be able to make a simple call to get the time before and after my timed event was a little naive... :)
>
>
>   

This is certainly still possible.  It's pretty easy to extract the
pertinent code/functions
from tm_basic.  You just have to remember what you are actually
measuring - if
just knowing how long it takes to run a certain function is what you're
after, then
this will do fine.

One caveat: tm_basic's timing method falls apart if the function
requires more than
one system clock tick to accomplish.  If you suspect this to be the
case, you'll have
to capture the value of cyg_current_time() as well as HAL_CLOCK_READ().
>   
>> Date: Fri, 16 Nov 2007 13:55:28 -0600
>> From: arth2219@gmail.com
>> To: csb_80@hotmail.com
>> Subject: Re: [ECOS] Performance timing
>> CC: gary@mlbassoc.com; ecos-discuss@ecos.sourceware.org
>>
>> On Nov 16, 2007 1:47 PM, C B  wrote:
>>     
>>> System profiling is probably what I need.
>>>
>>> Unfortunately there isn't an implementation of the profiling timer for my target. Any information or guidance available that you're aware of for implementing this?
>>>       
>> The eCos Reference Manual has this functionality documented:
>> http://ecos.sourceware.org/docs-latest/ref/gprof.html
>>
>> It's pretty straight forward to implement with in your HAL. You'll
>> need a spare hardware timer to use for your instrumentation. Try
>> looking in other HALs that use the profile timer as an example.
>>
>> You need to setup two functions to implement the profile instrumentation:
>> 1.) int hal_enable_profile_timer(int resolution)
>> * Initializes hardware timer and ISR.
>> 2.) unsigned int profile_isr(CYG_ADDRWORD vector, CYG_ADDRWORD data,
>> HAL_SavedRegisters *regs)
>> * Saves current program counter
>> * Handles timer hardware
>>
>>     
-- 
Gary Thomas
Capt, CAP CO-021
home/office: (970) 352-4947,  cell: (970) 481-5112


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

[ECOS] eCos compatible with arm-elf-gcc version 4.1.1?

[C B]

  I am successfully able to build the latest eCos from CVS using arm-elf-gcc version 3.2.1 that I got from eCosCentric.  In order to take advantage of some additional instructions for my target I was attempting to update to arm-elf-gcc version 4.1.1 but I'm not able to build eCos now.  I'm using the configtool in Windows XP and the only change is that I'm pointing to a new set of build tools.  The error I'm getting looks like this:


...
headers finished
make -r -C hal/arm/arch/current arm.inc
make[1]: Entering directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/test_build/hal/arm/arch/current'
arm-elf-gcc.exe: /opt/ecos/ecos-cvs/ecos/packages/hal/arm/arch/current/src/hal_mk_defs.c: No such file or directory
arm-elf-gcc -finline-limit=7000 -mcpu=arm9tdmi -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef  -g -O2 -ffunction-sections -fdata-sections  -fno-exceptions    -I/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/test_install/include -I/opt/ecos/ecos-cvs/ecos/packages/hal/arm/arch/current -I/opt/ecos/ecos-cvs/ecos/packages/hal/arm/arch/current/src -I/opt/ecos/ecos-cvs/ecos/packages/hal/arm/arch/current/tests -I. -Wp,-MD,arm.tmp -o hal_mk_defs.tmp -S /opt/ecos/ecos-cvs/ecos/packages/hal/arm/arch/current/src/hal_mk_defs.c
arm-elf-gcc.exe: no input files
make[1]: Leaving directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/test_build/hal/arm/arch/current'
make[1]: *** [arm.inc] Error 1
make: Leaving directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/test_build'
make: *** [build] Error 2


Is gcc 4.x not supported or am I missing something else?  If not, is 3.2.1 (which is fairly old) that latest?

Thanks!

_________________________________________________________________
Put your friends on the big screen with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007

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

Re: [ECOS] eCos compatible with arm-elf-gcc version 4.1.1?

[Lars Poeschel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>   I am successfully able to build the latest eCos from CVS using  
> arm-elf-gcc version 3.2.1 that I got from eCosCentric.  In order to  
> take advantage of some additional instructions for my target I was  
> attempting to update to arm-elf-gcc version 4.1.1 but I'm not able  
> to build eCos now.  I'm using the configtool in Windows XP and the  
> only change is that I'm pointing to a new set of build tools.  The  
> error I'm getting looks like this:
>
>
> ...
> headers finished
> make -r -C hal/arm/arch/current arm.inc
> make[1]: Entering directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/ 
> test_build/hal/arm/arch/current'
> arm-elf-gcc.exe: /opt/ecos/ecos-cvs/ecos/packages/hal/arm/arch/ 
> current/src/hal_mk_defs.c: No such file or directory

As you can see here, the compiler is not able to find a source file.  
This is not a problem of gcc, but of your configuration.
Check your ECOS_REPOSITORY shell variable,
check that you set up your build environment with this variable,
and finally check that all source files are in place, propably you  
have to update your local cvs tree.

> arm-elf-gcc -finline-limit=7000 -mcpu=arm9tdmi -Wall -Wpointer- 
> arith -Wstrict-prototypes -Winline -Wundef  -g -O2 -ffunction- 
> sections -fdata-sections  -fno-exceptions    -I/ecos-c/cygwin/opt/ 
> ecos/ecos-cvs/tmp3/test_install/include -I/opt/ecos/ecos-cvs/ecos/ 
> packages/hal/arm/arch/current -I/opt/ecos/ecos-cvs/ecos/packages/ 
> hal/arm/arch/current/src -I/opt/ecos/ecos-cvs/ecos/packages/hal/arm/ 
> arch/current/tests -I. -Wp,-MD,arm.tmp -o hal_mk_defs.tmp -S /opt/ 
> ecos/ecos-cvs/ecos/packages/hal/arm/arch/current/src/hal_mk_defs.c
> arm-elf-gcc.exe: no input files

Here you can see again, that the source file was not found.

> make[1]: Leaving directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/ 
> test_build/hal/arm/arch/current'
> make[1]: *** [arm.inc] Error 1
> make: Leaving directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/ 
> test_build'
> make: *** [build] Error 2
>
>
> Is gcc 4.x not supported or am I missing something else?  If not,  
> is 3.2.1 (which is fairly old) that latest?

Generally ecos should build for gcc4.x.

Lars

P.S.: Next time, don't answer to a previous mail, if you start a new  
thread!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFHRYyb3m3cZ1XsbwcRAkZmAJ9rVreAajPn5/AaEMgSZjYEfuzMJgCeOTqZ
rz2HBEmZ4HsllpSaAEGsACk=
=wTd1
-----END PGP SIGNATURE-----

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

RE: [ECOS] eCos compatible with arm-elf-gcc version 4.1.1?

[C B]

Sorry about mixing up the threads.
 
My configuration works perfectly with gcc 3.2.1.  No problems finding any files or building eCos.  The ONLY thing that I changed was to point the build tools at the 4.1.1 version of gcc and suddenly it can't find files that are in fact there.  Seems like a problem related to gcc 4.1.1 in some way.




> CC: ecos-discuss@ecos.sourceware.org
> From: larsi@wh2.tu-dresden.de
> Subject: Re: [ECOS] eCos compatible with arm-elf-gcc version 4.1.1?
> Date: Thu, 22 Nov 2007 15:05:12 +0100
> To: csb_80@hotmail.com
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> I am successfully able to build the latest eCos from CVS using
>> arm-elf-gcc version 3.2.1 that I got from eCosCentric. In order to
>> take advantage of some additional instructions for my target I was
>> attempting to update to arm-elf-gcc version 4.1.1 but I'm not able
>> to build eCos now. I'm using the configtool in Windows XP and the
>> only change is that I'm pointing to a new set of build tools. The
>> error I'm getting looks like this:
>>
>>
>> ...
>> headers finished
>> make -r -C hal/arm/arch/current arm.inc
>> make[1]: Entering directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/
>> test_build/hal/arm/arch/current'
>> arm-elf-gcc.exe: /opt/ecos/ecos-cvs/ecos/packages/hal/arm/arch/
>> current/src/hal_mk_defs.c: No such file or directory
>
> As you can see here, the compiler is not able to find a source file.
> This is not a problem of gcc, but of your configuration.
> Check your ECOS_REPOSITORY shell variable,
> check that you set up your build environment with this variable,
> and finally check that all source files are in place, propably you
> have to update your local cvs tree.
>
>> arm-elf-gcc -finline-limit=7000 -mcpu=arm9tdmi -Wall -Wpointer-
>> arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-
>> sections -fdata-sections -fno-exceptions -I/ecos-c/cygwin/opt/
>> ecos/ecos-cvs/tmp3/test_install/include -I/opt/ecos/ecos-cvs/ecos/
>> packages/hal/arm/arch/current -I/opt/ecos/ecos-cvs/ecos/packages/
>> hal/arm/arch/current/src -I/opt/ecos/ecos-cvs/ecos/packages/hal/arm/
>> arch/current/tests -I. -Wp,-MD,arm.tmp -o hal_mk_defs.tmp -S /opt/
>> ecos/ecos-cvs/ecos/packages/hal/arm/arch/current/src/hal_mk_defs.c
>> arm-elf-gcc.exe: no input files
>
> Here you can see again, that the source file was not found.
>
>> make[1]: Leaving directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/
>> test_build/hal/arm/arch/current'
>> make[1]: *** [arm.inc] Error 1
>> make: Leaving directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/
>> test_build'
>> make: *** [build] Error 2
>>
>>
>> Is gcc 4.x not supported or am I missing something else? If not,
>> is 3.2.1 (which is fairly old) that latest?
>
> Generally ecos should build for gcc4.x.
>
> Lars
>
> P.S.: Next time, don't answer to a previous mail, if you start a new
> thread!
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (Darwin)
>
> iD8DBQFHRYyb3m3cZ1XsbwcRAkZmAJ9rVreAajPn5/AaEMgSZjYEfuzMJgCeOTqZ
> rz2HBEmZ4HsllpSaAEGsACk=
> =wTd1
> -----END PGP SIGNATURE-----

_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007

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

RE: [ECOS] eCos compatible with arm-elf-gcc version 4.1.1?

[C B]

It seems that for some reason (only when I try to build with arm-elf-gcc version 4.x) I get these errors that it can't find the source files but it's trying to include the unix style filesystem /opt/ecos rather than than /ecos-c/cygwin/opt/ecos that is also included in some cases.  Any idea where configtool is getting these paths or why it might differ for gcc4.x?  The files are there and my ECOS_REPOSITORY is properly set but I can't determine from where the reference to /opt/ecos is originating.

> CC: ecos-discuss@ecos.sourceware.org
> From: larsi@wh2.tu-dresden.de
> Subject: Re: [ECOS] eCos compatible with arm-elf-gcc version 4.1.1?
> Date: Thu, 22 Nov 2007 15:05:12 +0100
> To: csb_80@hotmail.com
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> I am successfully able to build the latest eCos from CVS using
>> arm-elf-gcc version 3.2.1 that I got from eCosCentric. In order to
>> take advantage of some additional instructions for my target I was
>> attempting to update to arm-elf-gcc version 4.1.1 but I'm not able
>> to build eCos now. I'm using the configtool in Windows XP and the
>> only change is that I'm pointing to a new set of build tools. The
>> error I'm getting looks like this:
>>
>>
>> ...
>> headers finished
>> make -r -C hal/arm/arch/current arm.inc
>> make[1]: Entering directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/
>> test_build/hal/arm/arch/current'
>> arm-elf-gcc.exe: /opt/ecos/ecos-cvs/ecos/packages/hal/arm/arch/
>> current/src/hal_mk_defs.c: No such file or directory
>
> As you can see here, the compiler is not able to find a source file.
> This is not a problem of gcc, but of your configuration.
> Check your ECOS_REPOSITORY shell variable,
> check that you set up your build environment with this variable,
> and finally check that all source files are in place, propably you
> have to update your local cvs tree.
>
>> arm-elf-gcc -finline-limit=7000 -mcpu=arm9tdmi -Wall -Wpointer-
>> arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-
>> sections -fdata-sections -fno-exceptions -I/ecos-c/cygwin/opt/
>> ecos/ecos-cvs/tmp3/test_install/include -I/opt/ecos/ecos-cvs/ecos/
>> packages/hal/arm/arch/current -I/opt/ecos/ecos-cvs/ecos/packages/
>> hal/arm/arch/current/src -I/opt/ecos/ecos-cvs/ecos/packages/hal/arm/
>> arch/current/tests -I. -Wp,-MD,arm.tmp -o hal_mk_defs.tmp -S /opt/
>> ecos/ecos-cvs/ecos/packages/hal/arm/arch/current/src/hal_mk_defs.c
>> arm-elf-gcc.exe: no input files
>
> Here you can see again, that the source file was not found.
>
>> make[1]: Leaving directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/
>> test_build/hal/arm/arch/current'
>> make[1]: *** [arm.inc] Error 1
>> make: Leaving directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/
>> test_build'
>> make: *** [build] Error 2
>>
>>
>> Is gcc 4.x not supported or am I missing something else? If not,
>> is 3.2.1 (which is fairly old) that latest?
>
> Generally ecos should build for gcc4.x.
>
> Lars
>
> P.S.: Next time, don't answer to a previous mail, if you start a new
> thread!
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (Darwin)
>
> iD8DBQFHRYyb3m3cZ1XsbwcRAkZmAJ9rVreAajPn5/AaEMgSZjYEfuzMJgCeOTqZ
> rz2HBEmZ4HsllpSaAEGsACk=
> =wTd1
> -----END PGP SIGNATURE-----

_________________________________________________________________
Your smile counts. The more smiles you share, the more we donate.  Join in.
www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline

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

RE: [ECOS] eCos compatible with arm-elf-gcc version 4.1.1?

[C B]

Disregard.  Something within my cygwin installation was corrupted.  Re-installing cygwin solved whatever the issue was.


> From: csb_80@hotmail.com
> To: larsi@wh2.tu-dresden.de
> CC: ecos-discuss@ecos.sourceware.org
> Date: Tue, 27 Nov 2007 09:00:05 -0500
> Subject: RE: [ECOS] eCos compatible with arm-elf-gcc version 4.1.1?
>
>
>
> It seems that for some reason (only when I try to build with arm-elf-gcc version 4.x) I get these errors that it can't find the source files but it's trying to include the unix style filesystem /opt/ecos rather than than /ecos-c/cygwin/opt/ecos that is also included in some cases. Any idea where configtool is getting these paths or why it might differ for gcc4.x? The files are there and my ECOS_REPOSITORY is properly set but I can't determine from where the reference to /opt/ecos is originating.
>
>> CC: ecos-discuss@ecos.sourceware.org
>> From: larsi@wh2.tu-dresden.de
>> Subject: Re: [ECOS] eCos compatible with arm-elf-gcc version 4.1.1?
>> Date: Thu, 22 Nov 2007 15:05:12 +0100
>> To: csb_80@hotmail.com
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>> I am successfully able to build the latest eCos from CVS using
>>> arm-elf-gcc version 3.2.1 that I got from eCosCentric. In order to
>>> take advantage of some additional instructions for my target I was
>>> attempting to update to arm-elf-gcc version 4.1.1 but I'm not able
>>> to build eCos now. I'm using the configtool in Windows XP and the
>>> only change is that I'm pointing to a new set of build tools. The
>>> error I'm getting looks like this:
>>>
>>>
>>> ...
>>> headers finished
>>> make -r -C hal/arm/arch/current arm.inc
>>> make[1]: Entering directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/
>>> test_build/hal/arm/arch/current'
>>> arm-elf-gcc.exe: /opt/ecos/ecos-cvs/ecos/packages/hal/arm/arch/
>>> current/src/hal_mk_defs.c: No such file or directory
>>
>> As you can see here, the compiler is not able to find a source file.
>> This is not a problem of gcc, but of your configuration.
>> Check your ECOS_REPOSITORY shell variable,
>> check that you set up your build environment with this variable,
>> and finally check that all source files are in place, propably you
>> have to update your local cvs tree.
>>
>>> arm-elf-gcc -finline-limit=7000 -mcpu=arm9tdmi -Wall -Wpointer-
>>> arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-
>>> sections -fdata-sections -fno-exceptions -I/ecos-c/cygwin/opt/
>>> ecos/ecos-cvs/tmp3/test_install/include -I/opt/ecos/ecos-cvs/ecos/
>>> packages/hal/arm/arch/current -I/opt/ecos/ecos-cvs/ecos/packages/
>>> hal/arm/arch/current/src -I/opt/ecos/ecos-cvs/ecos/packages/hal/arm/
>>> arch/current/tests -I. -Wp,-MD,arm.tmp -o hal_mk_defs.tmp -S /opt/
>>> ecos/ecos-cvs/ecos/packages/hal/arm/arch/current/src/hal_mk_defs.c
>>> arm-elf-gcc.exe: no input files
>>
>> Here you can see again, that the source file was not found.
>>
>>> make[1]: Leaving directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/
>>> test_build/hal/arm/arch/current'
>>> make[1]: *** [arm.inc] Error 1
>>> make: Leaving directory `/ecos-c/cygwin/opt/ecos/ecos-cvs/tmp3/
>>> test_build'
>>> make: *** [build] Error 2
>>>
>>>
>>> Is gcc 4.x not supported or am I missing something else? If not,
>>> is 3.2.1 (which is fairly old) that latest?
>>
>> Generally ecos should build for gcc4.x.
>>
>> Lars
>>
>> P.S.: Next time, don't answer to a previous mail, if you start a new
>> thread!
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.6 (Darwin)
>>
>> iD8DBQFHRYyb3m3cZ1XsbwcRAkZmAJ9rVreAajPn5/AaEMgSZjYEfuzMJgCeOTqZ
>> rz2HBEmZ4HsllpSaAEGsACk=
>> =wTd1
>> -----END PGP SIGNATURE-----
>
> _________________________________________________________________
> Your smile counts. The more smiles you share, the more we donate.  Join in.
> www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
Put your friends on the big screen with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007

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

Re: [ECOS] RE: networking support for my eCos application

[Andrew Lunn]

On Mon, Nov 12, 2007 at 06:46:48AM -0500, C B wrote:
> 
> Brilliant!  Changing the CYG_HAL_STARTUP to RAM resulted in my new version having the same start address, etc. as my older version.  However, when I attempt to run my simple HelloWorld program I get the following output:
>  
> -------------------------- begin output ------------------------
> RedBoot> go 0x20020040[cyg_net_init] Init: mbinit(0x00000000)[cyg_net_init] Init: cyg_net_init_devs(0x00000000)Init device 'dm9000_eth0'
> --------------------------- end output -------------------------

Please try to answer your own questions. Your ROM/RAM start up problem
is not so easy unless you know eCos quite well. However any competent
software engineer should be able to do a grep -r and track this down.

Anyway, here is a hint:

CYGPKG_NET_FREEBSD_LOGGING

        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

RE: [ECOS] RE: networking support for my eCos application

[C B]

Admitedly, this was more difficult for me to track down than your email suggested.  However, I did find the issue and thought I'd post it here in case anyone else comes across similar symptoms:

It seems that between the released version of eCos and the latest from cvs the var_io.h in packages\hal\arm\at91\var\current\include added a bunch of newly defined values.  Some of these values (e.g. AT91_TC) changed values that I had defined elsewhere.  This resulted in the location of the hardware timer for my board being wrongly defined such that calls to HAL_DELAY_US() entered an infinite loop when called from dm9000_reset() causing the program to hang without any visible errors.


> Date: Mon, 12 Nov 2007 13:07:46 +0100
> From: andrew@lunn.ch
> To: csb_80@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] RE: networking support for my eCos application
>
> On Mon, Nov 12, 2007 at 06:46:48AM -0500, C B wrote:
>>
>> Brilliant! Changing the CYG_HAL_STARTUP to RAM resulted in my new version having the same start address, etc. as my older version. However, when I attempt to run my simple HelloWorld program I get the following output:
>>
>> -------------------------- begin output ------------------------
>> RedBoot> go 0x20020040[cyg_net_init] Init: mbinit(0x00000000)[cyg_net_init] Init: cyg_net_init_devs(0x00000000)Init device 'dm9000_eth0'
>> --------------------------- end output -------------------------
>
> Please try to answer your own questions. Your ROM/RAM start up problem
> is not so easy unless you know eCos quite well. However any competent
> software engineer should be able to do a grep -r and track this down.
>
> Anyway, here is a hint:
>
> CYGPKG_NET_FREEBSD_LOGGING
>
> Andrew

_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

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