Hi all,
I have similar problem with TS-7260. It's extremely slow doing
floating point calculations (log(), sqrt() function).
I am wondering if I have the same issue on TS-7260 as Mike had on
TS-7800. How can I figure out what libraries are called by cross
compiled executable?
I started with Linux and TS-7260 few months ago. So, I don't have much
experience with cross compiling and gcc.
I am running TS-Linux, cygwin-gcc-3.3.2-glibc-2.3.3 toolchain and I am
using next compile option:
arm-unknown-linux-gnu-cc -lm -Wall -O2 -o Executable MyProgram.c
Thanks in advance,
- Alex
--- In "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 "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 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
> > >
> >
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|