Geekmaster's adventures in K1 spelunking

[geekmaster]

I just discovered that some "search commands" are typed on the K1 keypad while in the settings menu:

411 gives a bunch of nice info, but what interest me at this point is:
"Kindle Version: Linux version 2.6.10-lab126 (build@voyager) (gcc version 3.4.2) #1 Wed Jan 28 19:02:06 PST 2009"

If I am going to try another GCC, that one should be next. Though in reality, hunting for a build tool that creates K1-compatible code is no longer any fun. At all...

[knc1]

Originally Posted by geekmaster

I just discovered that some "search commands" are typed on the K1 keypad while in the settings menu:

411 gives a bunch of nice info, but what interest me at this point is:
"Kindle Version: Linux version 2.6.10-lab126 (build@voyager) (gcc version 3.4.2) #1 Wed Jan 28 19:02:06 PST 2009"

If I am going to try another GCC, that one should be next. Though in reality, hunting for a build tool that creates K1-compatible code is no longer any fun. At all...

Unless you find a Lab126 posting of their toolchain - none other will work - you can give up that search now.

See my earlier post from today on the subject - you have to duplicate the A/L toolchain without having the component (uClibc, Kernel, gcc) configuration files.

It should be doable - but will take some work and don't expect to find a 'magic bullet' that lets you skip duplicating their toolchain.

[geekmaster]

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

[geekmaster]

Originally Posted by knc1

Unless you find a Lab126 posting of their toolchain - none other will work - you can give up that search now.

See my earlier post from today on the subject - you have to duplicate the A/L toolchain without having the component (uClibc, Kernel, gcc) configuration files.

It should be doable - but will take some work and don't expect to find a 'magic bullet' that lets you skip duplicating their toolchain.

Thanks. My search for a magic bullet has been fruitless, pointless, frustrating, and a unhealthy. I have no idea how to duplicate missing config files -- I barely understand config files even when they ARE provided. I need to study that first, it seems. Most of my career (even when programming for unix-ish machines) was done using CP/M or MS-DOS or Windows machines for the build tools. The unix-ish (or more commonly bare metal with no firmware other than mine) systems were just the target, and I have plugged in too many thousands of EPROMS over the years. So yeah, my lifetime coding reflexes do not work well here unless I have a toolchain that "just works" without thinking about it instead of thinking about my application...

I will be done posting here for a bit while I study, but I will keep an eye out for anything y'all post to this thread. A working toolchain would be nice...

[knc1]

Originally Posted by geekmaster

Thanks. My search for a magic bullet has been fruitless, pointless, frustrating, and a unhealthy. I have no idea how to duplicate missing config files -- I barely understand config files even when they ARE provided. I need to study that first, it seems. Most of my career (even when programming for unix-ish machines) was done using CP/M or MS-DOS or Windows machines for the build tools. The unix-ish (or more commonly bare metal with no firmware other than mine) systems were just the target, and I have plugged in too many thousands of EPROMS over the years. So yeah, my lifetime coding reflexes do not work well here unless I have a toolchain that "just works" without thinking about it instead of thinking about my application...

I will be done posting here for a bit while I study, but I will keep an eye out for anything y'all post to this thread. A working toolchain would be nice...

Reverse engineering a (menu) config file:

One of those things I putter around on when bored with life.
Also one of the things I have never finished.
But the basics are:

Going forward with menuconfig (kernel, busybox, uClibc, buildroot, etc):

You want feature: "Churn Butter on Wednesday" -
Find in menuconfig menus and then set to: 'yes' -
When the makefile is later run -
Finding symbol: CBW_CONFIG='y' it adds to the string OBJS-Y += cbw.o -
Later in the makefile processing all objects mentioned in the OBJS-Y (string) symbol are built -

Each *.o file built has its own set of (run-time) symbols.

The final <whatever> being built has an accumulation of symbols from each of its components.

So to reverse the process:

First a little prep work -
make allyes
that **should** (but will not) build every possible *.o in its tree

Now run a script (using a language that supports associative keyes) to list (using a standard elf tool) sysmbols in each *.o.
Make a catalog (when you find an entry point symbol cbw_init, do):
cbw_init: cbw.o, CBW_CONFIG=y, etc. etc. etc.

Now run a script on the final <whatever> was built -
For each symbol found, look it up in the above catalog, append the configuration symbol (CBW_CONFIG=y) to the output list you are building.

With an object like uClibc.so - ELF tools will give you the symbol list and details -

For the K1's kernel (also built with menuconfig):
cat /proc/kallsyms
while the kernel is running (do it now - before we both forget).
(/proc/kallsyms contains a list of symbols from every *.o = 'y' or 'm' when the kernel was built)

[donB006]

Kindle used denx? I found this finally.
I would schedule several months at least if I wanted to learn how to do this, and I don't.

ftp://ftp.denx.de/pub/eldk/4.0/arm-linux-x86/iso/

[geekmaster]

Meh... Okay. This K1 project seems like a dead end. Getting a toolchain working based on configs lab12 did not supply seems like opening a combination lock in the dark. I have better things to do...

[geekmaster]

Originally Posted by donB006

Kindle used denx? I found this finally.
I would schedule several months at least if I wanted to learn how to do this, and I don't.

ftp://ftp.denx.de/pub/eldk/4.0/arm-linux-x86/iso/

I tried ELDK. No go...

I think knc1 is right about needing the same configs lab126 used...

Think of the cool stuff I could share if I had spent this many hours developing stuff for newer kindles, where we already have toolchains that work, instead of this...

[knc1]

Originally Posted by geekmaster

I tried ELDK. No go...

I think knc1 is right about needing the same configs lab126 used...

That comes from a comment you made (and I had forgotten about) of how uClibc is not compatible from version-to-version.
It must be re-built.

In fact, since it is so highly configurable, it can be in-compatible from build-to-build of the same version.

Aboriginal Linux is probably a (currently maintained) alternative to ELDK for a native build environment.
http://landley.net/aboriginal/about.html

[NullNix]

[QUOTE=geekmaster;3315820]

PHP Code:

mint17-32 K1 # uclibc/bin/busybox
/lib/ld-uClibc.so.0: No such file or directory
mint17-32 K1 # file uclibc/lib/ld-uClibc.so.0
uclibc/lib/ld-uClibc.so.0: symbolic link to 'ld-uClibc-0.9.29.so' 
mint17-32 K1 # file uclibc/lib/ld-uClibc-0.9.29.so
uclibc/lib/ld-uClibc-0.9.29.so: ELF 32-bit LSB  shared object, ARM, EABI4 version 1 (SYSV), dynamically linked, stripped
mint17-32 K1 # 


Well, the reason why this isn't working is simple enough -- the ELF interpreter specified by uclibc/bin/busybox is /lib/ld-uClibc.so.0. That is an absolute path, and no searching is done: the kernel just executes it directly. An ld.so in a different directory, let alone one with a different name, will never be found by this process.

But uClibc is highly reconfigurable: as noted, without the config Amazon used, it's probably best to statically link everything, so you don't depend on the God-knows-what libc config Amazon have used. If you can't get that to work, you'll never be able to get the considerably more complex dynamic linking case to work.

[geekmaster]

Originally Posted by NullNix

Well, the reason why this isn't working is simple enough -- the ELF interpreter specified by uclibc/bin/busybox is /lib/ld-uClibc.so.0. That is an absolute path, and no searching is done: the kernel just executes it directly. An ld.so in a different directory, let alone one with a different name, will never be found by this process.

But uClibc is highly reconfigurable: as noted, without the config Amazon used, it's probably best to statically link everything, so you don't depend on the God-knows-what libc config Amazon have used. If you can't get that to work, you'll never be able to get the considerably more complex dynamic linking case to work.

As I mentioned, I executed those incorrectly just to SEE what they were looking for. On the K1 they run correctly. New stuff I compile does not even put out those error messages, so I do not know what they are looking for. Using ELF tools is something I am not (yet) familiar with. I have *other* hobbies besides this, and fighting with build tools is not (a desirable) part of this hobby. Now if somebody were to pay me to do this, it might be much less painful; my "free" time is too valuable for this...

Regarding getting NEW custom apps running on the K1, I have done static links that work on qemu-arm-static, but not on the K1. They typically segfault or get "illegal instruction" errors (depending on which gcc version was used). The compiler flags have little effect on the results. I think either the flags are not honored in some cases, or the loader is choking on the ELF file in some cases. Not sure -- this is new territory for me (in the past I just USED the tools, and I trusted them; not so much now)...

[geekmaster]

Originally Posted by knc1

...
For the K1's kernel (also built with menuconfig):
cat /proc/kallsyms
while the kernel is running (do it now - before we both forget).
(/proc/kallsyms contains a list of symbols from every *.o = 'y' or 'm' when the kernel was built)

When I tried posting that in a code box, the web browser (or rather, web server thread?) hung when I clicked the MR "preview" button. Too big, so included as compressed attachment (below).

FYI, all those "stl" symbols in that data dump are for the "Sector Translation Layer", which manages all the OneNAND (just a lump of dumb flash memory) write wear-levelling and bad block relocation. The mmc socket does not need this added layer of complexity, because SD cards contain their own (often quite sophisticated) CPU to manage all that out of sight of the hardware application.

BTW, many SD cards are hackable (I even have root shell on one of my SD cards, but logging to flash from that shell, while the SD card is visible to a host PC, is rather hard to sync and sometimes causes file system corruption).

[geekmaster]

Instead of fighting with incompatible ELF files, maybe I should play with custom u-boot images? That might be easier...

[NullNix]

Originally Posted by geekmaster

As I mentioned, I executed those incorrectly just to SEE what they were looking for. On the K1 they run correctly. New stuff I compile does not even put out those error messages, so I do not know what they are looking for. Using ELF tools is something I am not (yet) familiar with. I have *other* hobbies besides this, and fighting with build tools is not (a desirable) part of this hobby. Now if somebody were to pay me to do this, it might be much less painful; my "free" time is too valuable for this...

What I'd try is an objdump -dS (using the right toolchain's objdump, obviously) and do some hex arithmetic from the faulting dmesg (if any) to see what instruction it's whining about. If you figure that out, I can have a look at GCC and see why it's generating that instruction, and how to stop it. (I enjoy toolchain stuff like little else, which means I'm one of those tiresome people whose hobby is also their job!)

If there is no faulting dmesg, then since there's no gdb binary on this platform (and we can't build a gdb stub for remote debugging until we can build a binary that works), then it gets much harder to figure out what's causing this. But if we can figure out what instruction is triggering this SIGILL, we're most of the way there.

The ARM is rather famous for having wild variation in the variety of instructions particular chips accept: I'd bet that at least one that is usually available on ARMv5 isn't available on the one used in the K1.

[geekmaster]

I haven't had difficulty for a variety of ARM dev kits that provide their own toolchain (other than making sure environment variables do not conflict), but I have yet to find a download link for various lab126 toolchains that would be useful for us here...