Quote:
Originally Posted by knc1
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). |
I am aware of much of what you told me. I tried building the toolchain in the amazon source, but make fails after lots of grinding (complaining about a call with O_CREATE that does not have enough parameters).
I did specify softfloat (or softfp) in some attempts, depending on the compiler (older GCC versions default to soft float). The -mcpu options did not work when I tried them, so I switched to -march and -mtune.
I will try more of the options you suggested.
Question, why would the compiler generate floating point code for a "Hello" program? My simplest attempt was a main() that did a "return 42;" and nothing else (and my script displays return code).
I am tempted to drop to ASM and use my own minimal C runtime (i.e. bare metal mode). At least then I know the compiler is not throwing in stuff that makes the loader bail or causes an instruction trap.
Configuring and building a toolchain is all-new to me. I should spend more time reading and less time stumbling around in the dark, in these blind attempts to run custom code on my K1...