Re: eCos for MPC55xx

[Jonathan Larmour <jifl at eCosCentric dot com>]

Hi Gerster,

Gerster Jochen-B01096 wrote:
>  
>
> > > Gerster Jochen-B01096 wrote:
> > >
> > > 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.
>
> > Jonathan Larmour wrote:
> >
> > If it did not work for unaligned accesses on PowerPC in general, then this would have been discovered years ago.
> >
> > Perhaps have the semantics of an opcode in the MPC55xx changed so that 
> > something that used to work for all PowerPC now only works on aligned addresses? If so that wouldn't be good, but it's not beyond the realms of possibility.
>
> The opcode which generates the unaligned access is a simple lwz r28,
> 0xE(r30) (which load the ipaddr out of the ip header) = memcpy(x,x,4) And
> when now r30 + 0xE is unaligned the mpc5553/mpc5554 generates a
> exception(accessing the EBI)! Only the new Tiger mpc5567 supports unaligned
> 32bit access on the EBI And the problem is solved using gcc parameter
> -mstrict-align then the compiler splitt it up

It does look like -mstrict-align is the right solution then.

> Here is the services folder including - the changed cpuload.cxx with
> correct average calculation

Please, for changes to existing packages, you need to provide them as a 
patch, generated by "diff -u5p", preferably against current CVS, although 
your April snapshot will probably be good enough.

For example, if you have the original snapshot in a directory "snap/" and 
your changed version in "changed/", then you could generate a diff for the 
cpuload package with something like:

diff -u5prN snap/packages/services/cpuload 
changed/packages/services/cpuload > cpuload.patch.txt

That should generate a short patch describing only the changes you have 
made. If you find it contains essentially a copy of the whole file, then 
that might be because of windows line endings causing diff to think there 
are changes when there aren't really. To solve that you can add "-w" to 
diff to make it ignore white space changes like that.

Also, just as a reminder since I mentioned this before please avoid 
generating patches for more than one package at a time. If we can have each 
patch as a separate mail, it means we can review and discuss each patch 
separately.

Also, please provide a ChangeLog entry corresponding to your changes. Every 
package has a ChangeLog file you can look at to see how an entry should look.

You can find more assistance on patches at 
http://ecos.sourceware.org/patches.html

As for your new packages i.e. the MPC55xx HALs and drivers, since you were 
having trouble posting to the mailing list, you can upload them via FTP to 
ftp.ecoscentric.com into the /incoming directory. From there I can ensure 
the right things happen. You can try this now, to see if it works, 
otherwise we'll have to find some other way for you to get the packages to 
us. But either way we won't be able to properly put these into eCos until 
we've got the copyright assignment as has been said before.

> - And the new package for the goahead
> webserver. The sourcecode has to be downloaded from goahead
> and has to be unpacked directly in the src subdirectory (I used GoAhead
> WebServer 2.1.8 src)
> http://216.211.138.77/webserver/secure/webserver2.htm?redirect=I+ACCEPT

It's true that we cannot accept the Goahead webserver source code itself 
into the main distribution of eCos due to its non-free licence.  However 
the idea of a placeholder has some merit. Although again it must wait for 
your copyright assignment, this seems a reasonable thing to do to allow 
people to use the GoAhead server easily.

Thanks for contributing!

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
------["The best things in life aren't things."]------      Opinions==mine