From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9972 invoked by alias); 20 Jul 2006 08:21:05 -0000 Received: (qmail 9937 invoked by uid 22791); 20 Jul 2006 08:21:03 -0000 X-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_CP,TW_GX X-Spam-Check-By: sourceware.org Received: from az33egw01.freescale.net (HELO az33egw01.freescale.net) (192.88.158.102) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Jul 2006 08:21:02 +0000 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id k6K8Kx5m012070 for ; Thu, 20 Jul 2006 01:20:59 -0700 (MST) Received: from zwg18exm01.ea.freescale.net (zwg18exm01.ea.freescale.net [10.170.73.30]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id k6K8KvvF007432 for ; Thu, 20 Jul 2006 03:20:58 -0500 (CDT) Received: by zwg18exm01.ea.freescale.net with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Jul 2006 10:20:57 +0200 Message-ID: From: Gerster Jochen-B01096 To: ecos-patches@ecos.sourceware.org Subject: FW: eCos for MPC55xx Date: Thu, 20 Jul 2006 08:21:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-IsSubscribed: yes Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2006-07/txt/msg00023.txt.bz2 Sorry this message never reached the ecos mailing list I send it to myself :Z I found another solution without renaming the memcpy to _memcpy ... -----Original Message----- From: Gerster Jochen-B01096 Sent: Montag, 10. Juli 2006 11:01 To: Gerster Jochen-B01096 Subject: RE: eCos for MPC55xx Hi Good news! I think I found a way to handle the gcc memcpy inline alignment problem without changing any file of the source code by using the gcc command -mstrict-align. I don't know how I could overlook this ?:) Now I will test some configuration but I'm goodwill this has solved the problem. I closed the download link. Thanks for your help! -----Original Message----- From: ecos-patches-owner@ecos.sourceware.org [mailto:ecos-patches-owner@ecos.sourceware.org] On Behalf Of Gerster Jochen-B01096 Sent: Freitag, 7. Juli 2006 09:56 To: ecos-patches@ecos.sourceware.org Subject: RE: eCos for MPC55xx 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 ------------------------------------------------------------