RE: eCos for MPC55xx

[Gerster Jochen-B01096 <B01096 at freescale dot com>]

Here is the output of the gcc -v
C:\cygwin\opt\ecos\gnutools\powerpc-eabi\bin>powerpc-eabi-gcc.exe -v Reading specs from /opt/ecos/gnutools/powerpc-eabi/bin/../lib/gcc-lib/powerpc-ea
bi/3.2.1/specs
Configured with: /local/demonweb/tools/ecos-gnutools-v1.4/r2/powerpc-eabi/cygwin
/tar_bz2/source/gcc-3.2.1/configure --target=powerpc-eabi --prefix=/local/demonw eb/tools/ecos-gnutools-v1.4/r2/powerpc-eabi/cygwin/tar_bz2/opt/ecos/gnutools/pow
erpc-eabi --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --w ith-gxx-include-dir=/local/demonweb/tools/ecos-gnutools-v1.4/r2/powerpc-eabi/cyg
win/tar_bz2/opt/ecos/gnutools/powerpc-eabi/powerpc-eabi/include
Thread model: single
gcc version 3.2.1

I have download the gnutools from the ecos site

One different is that I use the flag -msoft-float so gcc uses other libs ....

Attached is a picture showing the debugger at the place doing an unaligned access.
You can see that there is no call to the memcpy function from ecos!

Its in the if_ether.c file - function is in_arpinput

0x3fc6c0ba is the address where the src ip-address is found and this address is not aligned to 4byte so no word(32bit) access is allowed

With my patch we simple tricks the compiler, by only changing the function label to _memcpy and so the compiler don't uses its inline memcpy function

Zzz
Ok forget it! NO picture attached, it seems this mailing list doesn't like anything usefull!?!?

So look here
http://service.gmx.net/mc/MyrAaChazs9GWwfVR7FL3nHTjEC9J4
Here you can download the screenshot of the debug window showing one place of the memcpy problem
The source code for the new port including every new file and all changed file


I added a new package to include the GoAhead WebServer source to ecos.
The source isn't included so you have to download it from their webpage
Look at the readme in the services/goahead/.../src directory




-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Donnerstag, 6. Juli 2006 14:37
To: Gerster Jochen-B01096
Cc: ecos-patches@ecos.sourceware.org
Subject: Re: eCos for MPC55xx

Gerster Jochen-B01096 wrote:
> As I said before, the IP-addresses(src/dst) has no fixed offset in the several protocol-headers!
> That means the IP-addresses in the ARP-Header(14) have a different offset as in the IP-Header(12) and so I can't belive the TCP/IP stack regards this.
> 
> The exception is generated by the TCP/IP stack handling a ARP message! So this is ecos code!
> 
> Doing my patch(as described before) everything works fine!
> 
> And my question was?
> Anybody else have/has the same problem using a powerpc?

No, I've not seen this (and I've been running the network stack on eCos for *many* years now)

Exactly what version of GCC are you using?  How was it configured?

Can you point at exactly the source line that you are referring to and the assembly code that gets generated?

> And their solutions.
> 
> 
> Jochen
> 
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Donnerstag, 6. Juli 2006 12:16
> To: Gerster Jochen-B01096
> Cc: Andrew Lunn
> Subject: Re: eCos for MPC55xx
> 
> On Thu, Jul 06, 2006 at 09:56:07AM +0200, Gerster Jochen-B01096 wrote:
>> Hi Andrew
>>
>> Ok so lets start with the memcpy problem, while I take care of the Copyright assignment.
>> Perhaps a new thread?
>>
>> The problem is:
>> The POWERPC gcc compiler (allocated from the ecos site)  optimize 
>> memcpy calls with small length, instead it uses its own inline 
>> function without taking care of aligned access. This is a very very 
>> big problem using the TCP/IP stack because the IP-address is 4byte so 
>> the gcc optimize and the offset of the IP-address in the different 
>> protocol-headers varies. This ends in a exception :(
> 
> The network stack is so setup so that IP addresses in packets are always aligned. So there should not be a problem. Is this user code, or eCos code which is causing problems. If you use char *, not int *, memcpy will be careful and not assume word alignment.
> 
>        Andrew


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