Geekmaster's adventures in K1 spelunking

[geekmaster]

Originally Posted by knc1

-mtune=xscale -mno-unaligned-access

The compiler said "cc1.exe: error: invalid option `no-unaligned-access'".

Just adding "-mtune=xscale" makes the K1 still say "Illegal instruction".

However, that seems better than a segfault or "not found", I think. Now, if we can just sweep out those pesky illegal instructions, all would be well, eh?

EDIT: This is gcc 3.4.4: https://gcc.gnu.org/onlinedocs/gcc-3...M-Options.html
I find it strange that the gcc 3.4.4 docs list -mno-unaligned-access as valid, but the compiler complains and abort...

[geekmaster]

Despite what the docs say, here are the options the compiler says it supports:

C:\SHARE\kindle\K1>"C:\Program Files (x86)\CodeSourcery\Sourcery G++\bin\arm-none-linux-gnueabi-gcc.exe" --target-help

Target specific options:
  -mno-cirrus-fix-invalid-insns Cirrus: Do not break up invalid instruction combinations with NOPs
  -mcirrus-fix-invalid-insns Cirrus: Place NOPs to avoid invalid instruction combinations
  -mcaller-super-interworking Thumb: Assume function pointers may go to non-Thumb aware code
  -mcallee-super-interworking Thumb: Assume non-static functions may be called from ARM code
  -mtpcs-leaf-frame         Thumb: Generate (leaf) stack frames even if not needed
  -mtpcs-frame              Thumb: Generate (non-leaf) stack frames even if not needed
  -mthumb                   Compile for the Thumb not the ARM
  -mlong-calls              Generate call insns as indirect calls, if necessary
  -msingle-pic-base         Do not load the PIC register in function prologues
  -mno-sched-prolog         Do not move instructions into a function's prologue
  -mabort-on-noreturn       Generate a call to abort if a noreturn function returns
  -mthumb-interwork         Support calls between Thumb and ARM instruction sets
  -mwords-little-endian     Assume big endian bytes, little endian words
  -mlittle-endian           Assume target CPU is configured as little endian
  -mbig-endian              Assume target CPU is configured as big endian
  -mapcs-reentrant          Generate re-entrant, PIC code
  -mapcs-float              Pass FP arguments in FP registers
  -mpoke-function-name      Store function names in object code
  -mapcs-frame              Generate APCS conformant stack frames
  -mtp=                     Specify how to access the thread pointer
  -mhard-float              Alias for -mfloat-abi=hard
  -msoft-float              Alias for -mfloat-abi=soft
  -mabi=                    Specify an ABI
  -mpic-register=           Specify the register to be used for PIC addressing
  -mstructure-size-boundary= Specify the minimum bit alignment of structures
  -mfloat-abi=              Specify if floating point hardware should be used
  -mfpu=                    Specify the name of the target floating point hardware/format
  -march=                   Specify the name of the target architecture
  -mcpu=                    Specify the name of the target CPU
 ARM-specific assembler options:
  -k                      generate PIC code
  -mthumb                 assemble Thumb code
  -mthumb-interwork       support ARM/Thumb interworking
  -mapcs-32               code uses 32-bit program counter
  -mapcs-26               code uses 26-bit program counter
  -mapcs-float            floating point args are in fp regs
  -mapcs-reentrant        re-entrant code
  -matpcs                 code is ATPCS conformant
  -mbig-endian            assemble for big-endian
  -mlittle-endian         assemble for little-endian
  -mapcs-frame            use frame pointer
  -mapcs-stack-check      use stack size checking
  -mcpu=<cpu name>        assemble for CPU <cpu name>
  -march=<arch name>      assemble for architecture <arch name>
  -mfpu=<fpu name>        assemble for FPU architecture <fpu name>
  -mfloat-abi=<abi>       assemble for floating point ABI <abi>
  -meabi=<ver>    assemble for eabi version <ver>
  -EB                     assemble code for a big-endian cpu
  -EL                     assemble code for a little-endian cpu
armelf_linux_eabi:
  -Bgroup               Selects group name lookup rules for DSO
  --disable-new-dtags   Disable new dynamic tags
  --enable-new-dtags    Enable new dynamic tags
  --eh-frame-hdr        Create .eh_frame_hdr section
  -z combreloc          Merge dynamic relocs into one section and sort
  -z defs               Report unresolved symbols in object files.
  -z execstack          Mark executable as requiring executable stack
  -z initfirst          Mark DSO to be initialized first at runtime
  -z interpose          Mark object to interpose all DSOs but executable
  -z loadfltr           Mark object requiring immediate process
  -z muldefs            Allow multiple definitions
  -z nocombreloc        Don't merge dynamic relocs into one section
  -z nocopyreloc        Don't create copy relocs
  -z nodefaultlib       Mark object not to use default search paths
  -z nodelete           Mark DSO non-deletable at runtime
  -z nodlopen           Mark DSO not available to dlopen
  -z nodump             Mark DSO not available to dldump
  -z noexecstack        Mark executable as not requiring executable stack
  -z norelro            Don't create RELRO program header
  -z now                Mark object non-lazy runtime binding
  -z origin             Mark object requiring immediate $ORIGIN processing
                          at runtime
  -z relro              Create RELRO program header
  -z KEYWORD            Ignored for Solaris compatibility
     --thumb-entry=<sym>      Set the entry point to be Thumb symbol <sym>
     --be8                    Oputput BE8 format image
     --target1=rel            Interpret R_ARM_TARGET1 as R_ARM_REL32
     --target1=abs            Interpret R_ARM_TARGET1 as R_ARM_ABS32
     --target2=<type>         Specify definition of R_ARM_TARGET2
     --fix-v4bx               Rewrite BX rn as MOV pc, rn for ARMv4
     --use-blx                Enable use of BLX instructions

[NiLuJe]

Yeah, -mno-unaligned-access is recent-ish (I have the exact info jotted down somewhere).

For a potentially good reason: that was the default before the option was implemenbted (IIRC, pending confirmation).

EDIT: Yup, that's since GCC 4.7 (cf. https://gcc.gnu.org/gcc-4.7/changes.html).

And if you decide to try something up-to-date, I haven't had time to check GCC 6.1 (and the various changes, in particular the aliasing rules changes, don't necessarily make me eager to dive into it until the Gentoo tracker on that front gets thinner) yet, but I've had some wonderfully weird (and broken) experiences with GCC 5.3 until very recently... (That's with the Linaro tree, but, just to be safe, I'm going to recommend staying away from the FSF 5.3.0 release, too).

----

Sorry I can't be of more help, no experience playing w/ K1. I can only reiterate what was already said, the use of µclibc adds an extra layer of "fun" to your cross-compiling hurdles...

[geekmaster]

I see that my seagate goflex_home nas also has arm5te (like the K1). I have root access, and folks have hacks for it -- I will see it some bins from that work on the K1 (or if I can compile natively on it). Perhaps an option...


Nope! They kick out the "not found" error.

[geekmaster]

I think I will probably try this at some point soon:
http://www.uclinux.org/pub/uClinux/arm-elf-tools/gcc-3/

And I plan to try crosstool, now that I have gentoo running in a VM.

This takes a lot of commitment (and a few beers -- coffee was not enough)...

Dammit! I could be doing VR apps for the Oculus store, now that the CV1 (Oculus Rift consumer version VR HMD) is in some Best Buy stores. I have a HUGE (respected) reputation in that community, and could sell my apps based on the reputation alone. Instead I am fixated on kindles, even adding to my collection recently...

My muse leads me astray -- it has no respect for money.. I have been overly fascinated by eink since those magazines came our with eink built into the covers (and had to be shipped in refrigerated boxcars to make the batteries last until the next issue came out). I bought a bunch of them. I know eink inside and out, and it occupies my dreams...

[geekmaster]

And perhaps this is another path to follow:
http://www.uclinux.org/pub/uClinux/arm-tools/RPMS/

[geekmaster]

Well, if I am going to support this device (for free) I guess part of my learning curve will be to study this (and related links): μClinux @ WikiPedia

[donB006]

There might be a future with the VR unlike the K1.

I have never chroot into an arm emulator. I have chroot from a 64bit into a 32bit OS. I have chroot from mips video player with android to mips debian. Here I do a virtual chroot so I don't need to bind mount things except that should be virtually the same anyway.

Here I start from /bin/bash and chroot to /bin/bash, /bin/sh (dash) and /bin/busybox sh (ash). Notice how the prompt changes with the various shells. I don't know if your box has dash. Just try changing the SHELL environment setting as shown here.

root@delldebian:/tmp# 
root@delldebian:/tmp# 
root@delldebian:/tmp# echo $SHELL
/bin/bash
root@delldebian:/tmp# chroot /
root@delldebian:/#
root@delldebian:/# exit
exit
root@delldebian:/tmp# SHELL=/bin/sh
root@delldebian:/tmp# chroot /
# 
# exit
root@delldebian:/tmp# chroot / /bin/sh
# 
# exit
root@delldebian:/tmp# chroot / busybox sh


BusyBox v1.20.2 (Debian 1:1.20.0-7) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/ # 
/ # exit
root@delldebian:/tmp# 
root@delldebian:/tmp#

[geekmaster]

I tried a uclibc buildroot, but it fails. It claims no targets are selected partway into the build, even though I verified everything multiple times (especially targets) in make menuconfig. They provide links to binary toolchains on their home page, but all the links are dead. In the download directory is a doc that says "uClibc does not even attempt to ensure binary compatibility across releases. When a new version of uClibc is released, you may or may not need to recompile all your binaries." Ahh, yeah. Perhaps that is why even uclibc binaries do not work on the K1. Though you would think static compiles would be safe (unless they are only mostly static). Elsewhere it also says that uclibc is highly dependent on your choice of kernel headers, so yeah...

Just like all the other things I tried, promising stuff, but dead ends everywhere...

[geekmaster]

Another new behavior. I did find the uclibc arm rootfs, buried in their download directory (but not where their homepage links). I copied its /bin to my K1. I ran its busybox on my K1. This time I got yet another failure mode:

/mnt/us/bin/busybox: 1: Syntax error: "(" unexpected

There is something strange about the loader on the K1...

And it sucks when simple step-by-step instructions that are self-proclaimed as EASY fail, which has been happening over and over for me. From broken download links, to steps that abort, to stuff not found that is obviously there where it belongs. Hmm... Just bit rot? Or bad luck?

[donB006]

The open source source code for the uClibc and for the linux kernel with headers are also available in the Amazon source code release for the Kindle1. They just don't have any Amazon code.
https://www.amazon.com/gp/help/custo...deId=200203720

I imagine you would also need all of the libraries from the K1 when you link with your own programs. I haven't built much for a long time and never tried buildroot and avoid emulators so can't help there. I am about to have other things to do also. Have fun anyway.

[geekmaster]

I can't build a toolchain that will run in the kindle if I cannot even build a hello program that runs -- unless there is a script-only "binary compiler" that depends only on tools alread in the K1 (like "dd").

And chroot will not work with any of the uclibc rootfs images or files I found. No matter what shell I choose, it says "not found".

And not sure compiling with a uclibc rootfs would work anyway, if binaries from it do not run in my K1.

There is just some huge incompatibility between K1 binaries and everything else. I really wonder how lab126 builds K1 firmware. I think I saw a reference to "scratchbox" somewhere in that mess...

[geekmaster]

Because some of the kindle source code has "Denx" credits in it, I just checked out the ELDK toolchain from Denx, and of course, like all the others, the download links I need are dead. This is just so strange that I see this repeatedly from web sites that still have some recent content.

[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).

[knc1]

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).