Quote:
Originally Posted by geekmaster
Okay, as I added in an edit, I can now chroot into the rootfs copied from the gumstix jffs image. It was missing qemu-arm-static. Installing gcc into it will be nontrivial however. Some of the problem before was that my linux mint got somehow hosed, and it took multiple reboots to fix it (even x11 failed on the first reboot). Seems to be working okay now...
But no real hopes of things compiled in this uclibc-based gumstix rootfs to actually work in the K1, because static binaries copied FROM this image to the K1 failed.
I need to do something else for awhile. No more experimenting. Reading. Kindle source code. Again... (I am fed up with trying to build something for the K1). Code build for K2 and newer works just fine. What is so "special" about the K1? Does arm-gcc ignore the "-march=armv5te -mtune=xscale" switches or something (illegal instruction)? I suppose I need to actually disassemble the binary and see if it compiled correctly (though it does run in qemu-arm-static just fine).
|
going way back to the start of this - -
what fpu option(s) are you giving the compiler?
ARMv5TE has floating point registers,
xScale does not.
Early ARM processors had a 26-bit program counter, newer (including ARMv5) have 32-bit program counters.
The early GCC series 3 compilers (which Amazon/Lab126 where using - ref: their source tarball for v-1.2) still had options for program counter size.
The early series 3 compilers also recognized -mcpu=xscale
(which might just 'fix' all of the above things in one shot - but don't bet on it).
Ref (same/similar as A/L):
https://gcc.gnu.org/onlinedocs/gcc-3...#ARM%20Options
From the information I posted about your Busybox -
A starting point would be (it does not hurt to specify what (might) be the default - since A/L does not ship the gcc config they used (which might change the default) better safe than sorry):
-mapcs-32 \
-mno-sched-prolog \ # make it possible to find the prolog code(s)
-msoft-float \ # read the cautions about this - you'll need to build uClibc from Amazon/Lab126 sources to match and to provide the software floating point.
-mcpu=xscale \
-O0 # make disassembly readable
The above should be your starting point, there may be additional options needed to match Amazon/Lab126 code.
Review your compiler testing - discard any testing done without at least the above options provided.
You will have to build (or re-build) your toolchain to match Amazon/Lab126 -
Meaning you need to reverse engineer the uClibc configuration options from the library symbols present in the K1's build of libc.
There will be no shorter route to working K1 binaries until you do duplicate the Amazon/Lab126/uClibc toolchain (and do it without them providing the configuration files).