Hello all,
The TS-7800 is shipped with an EABI Kernel that also supports OABI binaries.
However, the Debian distribution and binaries are OABI ? sarge version.
Therefore, applications cross-compiled with an EABI cross-tool will have to be statically linked in order to work with the default TS-7800 distribution (sarge OABI). These static-linked EABI binaries should have better float-point performance with the TS-7800 EABI kernel. The following is the EABI cross-tool (used by us to cross-compile the kernel):
ftp://oz.embeddedarm.com/ts-7800-linux-sd/cross-toolchains/ts7800-crosstool-linux-gnueabi-2005q3-2.tar.gz
In order to cross-compile using dynamic linking and be able to use the default TS-7800 Debian OABI libraries, one can use the following OABI crosstool:
ftp://oz.embeddedarm.com/ts-7800-linux-sd/cross-toolchains/ts7800-crosstool-linux-oldabi-0.28rc39.tar.bz2
To take full advantage of float-point EABI improvements, one
will need both EABI kernel and userland binaries. With a TS-7800, this can be accomplished by either using a EABI static-linked binary or by installing an EABI filesystem. The EABI Debain port is called armel, which is under testing but is already usable. Etch is not EABI. We have a preliminary EABI debian filesystem available that works fine with the TS-7800:
ftp://oz.embeddedarm.com/ts-7800-linux-sd/distributions/debian-etch-eabi-armel-512MB-oct042007.tar.gz
In the future, when armel is more stable, we plan to release an official debian armel distribution.
For those using the TS-7800 Eclipse IDE: the crosstool we use for that is EABI and Eclipse is configured to create statically-linked binaries. All the binaries found at the location below are EABI statically-linked and were compiled with Eclipse:
ftp://oz.embeddedarm.com/ts-7800-linux-sd/samples/arm-binaries
Regards,
Ronald.
delapluie
<> escreveu: Hey everyone, Just want to thank everyone for your help and information, and point out an error in this post, in case anyone is trying to solve the same problem. The link for the TS Debian Etch distro which has the correct versions of the libraries should be- ftp://ftp.embeddedarm.com/ts-7800-linux-sd/distributions/debian-etch-eabi-armel-512MB-oct042007.tar.gz This is the armel version with full EABI support. I expect if you tried to find the libraries in the Old-ABI version in my incorrect link, they would have the wrong names and would not support EABI compiled applications. I hope to check out the EABI Etch root file system on the 7800, and investigate statically compiling the app soon. For TS, I've got two suggestions- 1. Make the Armel distro the default ASAP 2. In the meanwhile, clearly indicate which cross compiler works with which distro in your getting started docs, and maybe in the file names. The most obvious cross compilers on your web/ftp site are incompatible with the 7800 userland as
shipped! -mike --- In .com, "delapluie" < > wrote:
>
>
> ok, I have identified the major problem, and have a workable solution.
> The cross compiled executables call three shared libraries-
>
> ld-linux.so.3
> libc.so.6
> libm.so.6
>
> The default root file system in the TS-7800 only has ld-linux.so.2,
> and the wrong versions of libc.so.6 and libm.so.6 . So I got the
> Debian Etch root file system from the Technologic ftp server-
>
>
ftp://ftp.embeddedarm.com/ts-7800-linux-sd/distributions/debian-etch-oldabi-jan222008.tar.gz
>
> Unpacked it, and found the libraries. Each of the above files was
a
> symbolic link, pointing respectively to-
>
> ld-2.5.so
> libc-2.5.so
> libm-2.5.so
>
> There is no ld-linux.so.3 on the 7800, so I could just place that file
> directly in /lib. For the other two, if I replace the existing
> versions, the executables that come with the 7800 break. So, as a
> first workaround, I created a /lib/swarm folder (swarm is the project
> I working on), and placed the other two libraries and their symbolic
> links there. Then, it was necessary to change the makefile for my
> applications so that they look in the /lib/swarm directory at run
> time. This was accomplished by adding
>
> -Wl,-rpath /lib/swarm
>
> to the options for gcc when I link the object files.
>
> Performance is now everything I hoped for! Completing one iteration
> of my algorithm went from requiring 54ms to less than
4ms. Whereas
> previously, the vast majority of the time was System Time (assumably
> spent on overhead with the clunky OABI floating point emulation), now
> System Time is almost nothing.
>
> It appears the kernel on my 7800 does just fine with efficient
> floating point emulation, but userland libraries (and the native gcc)
> do not. The cross compilers do just fine, once you provide the
> executables with the requisite versions of the libraries.
>
> Going forward, I'm considering three solutions-
>
> 1. Keep the current technique. A little clunky, but it works.
>
> 2. Statically compile my application. The libraries total about 2MB.
> We're going to need 3-4 executables, which dynamically linked are
> less than 100kB each. Total for 4 would still be less than 10 MB,
> which will be no problem on the 7800's 512MB of flash. Once the build
> environment is configured right, I don't have to do much of anything
> to prep the 7800. We're going to deploy at least 6 of these, so
> that's a nice feature.
>
> 3. Replace the OEM root file system (assumably Debian Sarge) with the
> Debian Etch root file system. This assures perfect sychronization
> between the cross compiler and the userland, and allows us to natively
> compile with comparable results, which might be useful in the field.
> But I'm not terribly keen on replacing the root file system on a pile
> of these boards.
>
> Anyone been running the TS Debian Etch distro? Does it have problems
> I should know about?
>
> By the way, we're putting these in robots-
>
> http://www.orbswarm.com
>
> -mike
>
> --- In .com, "delapluie" <mprados@> wrote:
> >
> >
> > for the cross-compiled executable, I get-
> >
> > :mike1# readelf -h test | grep -i flags
> > Flags: 0x4000002, has entry point,
> > <unrecognized EABI>
> >
> > whereas for the natively compiled executable, which does run (slowly),
> > I get-
> >
> > :kalman# readelf -h test | grep -i flags
> > Flags: 0x2, has entry point, GNU EABI
> >
> > While "unrecognized EABI" is certainly not encouraging, the "GNU EABI"
> > on the working, natively compiled file seems to indicate EABI on my
> > particular 7800... for both kernel and userland?
> >
> > Also, I noticed that the
natively compiled file calls ld-linux.so.2,
> > whereas as the cross compiled file calls ld-linux.so.3, which is not
> > present on my 7800.
> >
> > -mike
> >
> >
> > --- In .com, Christopher Friedt <cfriedt@> wrote:
> > >
> > > delapluie wrote:
> > > > I was unsuccessful in getting the crosstools to work from Ubuntu.
> > > > When I ftp'd my executable to the 7800, and did a "chmod +x
test", I
> > > > keep getting-"-bash: ./test: No such file or directory" If
> anyone has
> > > > any thoughts on this problem, I'd appreciate it.
> > >
> > > You definitely won't be able to run an eabi binary without both an
> eabi
> > > kernel as well as an eabi userland.
> >
>
> > > bash is probably reporting that the binary executable format is
> > > incorrect. (you're probably running an oabi userland and kernel).
> > >
> > > even though 'test' might be compiled to use the eabi, it's not
> going to
> > > work unless you have a compatible userland.
> > >
> > > check out what the output of "readelf -h test | grep -i flags" gives
> > you.
> > >
> > > Chris
> > >
> >
>
Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
__._,_.___
![]()
__,_._,___
|