Geekmaster's adventures in K1 spelunking

[geekmaster]

Originally Posted by donB006

I have installed gcc into my DXG 2.5.8 and have compiled hello world. See attached.

Actually, could you (please) send me (or post here) your compiled "hello" program, so I can test it on my K1? Thanks...

[geekmaster]

I tried a bunch of different promising toolchains, but to no avail.

But now I think I had SOME possible progress. I downloaded:
https://downloads.gumstix.com/feeds/archive/318M/uclibc/ipk/armv5te/g++_4.1.2-r7_armv5te.ipk
And from that archive I unpacked:
arm-angstrom-linux-uclibcgnueabi-g++
I copied that to my K1, and when running:
/mnt/us/arm-angstrom-linux-uclibcgnueabi-g++ -v
I got a DIFFERENT error message:
can't load library 'libiconv.so.2'

That seems a lot less cryptic than "not found" or "Segmentation fault", which are all I ever saw from anything else NOT copied directly from a K1 rootfs.

Considering that the K1 was largely Gumstix based (even with Gumstix references in the amazon GPL source code), it makes sense that binary packages from a Gumstix website would at least "try" to load and run. I suspect it WOULD run if I could find and install all the missing dependencies.

That seems like a modicum of progress...

With a bit of luck, I *might* be able to compile directly on the K1, but there are probably a ton of dependencies to resolve first.

[geekmaster]

And googling for that "almost" working executable, I found that beagleboard dev kits support that, so perhaps more potentially useable binaries there too:
http://beagleboard.org/linux

The goal being to find some static-compiled build tools that I can use to build more...

[NullNix]

Originally Posted by geekmaster

I built a lenny.ext3 from scratch (using his debootstrap intructions). I loop mounted it and did a qemu-static ch to it from my x86 linux mint. I installed build-essentials for architecture armeabi. I build a hello.c with "gcc -march=arm5te -o hello hello.c". It does not work, just like all the others.

Dynamic shared lib executables say "not found" when executed. Static builds seg fault. Just like always. I wonder if "not found" means it tried to run but could not find some library?

This sounds like the ELF interpreter, which is named in the PT_INTERP segment: libcs use this to name their dynamic linker, and uclibc and glibc are very much *not* compatible in this respect. Indeed, even the toolchains are not compatible: you must build a cross-compiler from *-gnu to *-uclibc if everything is to work (though mostly the failures would be in things like C++ exception handling, which you probably don't care about). Linking with -static would avoid all these problems, but would still give you static binaries linked against glibc, which would be huge: you want to use a cross-compiler to uclibc if you possibly can.

You almost certainly want to exploit the sysroot feature, if you can manage to use a new-enough compiler (which you probably can): <https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html>. This lets you drop a mini-root-directory full of libraries and headers and have GCC just use it and avoid ever using the libraries and headers on your build machine.

GCC still has ARMv5 support, so you should not need to use an ancient compiler: a new toolchain should work fine, as long as you stick with whatever ancient uclibc the K1 is using.

[donB006]

The error message is a good sign those gumstix binaries will work with the Kindle1. The files I was using were built for a newer kernel so they worked on my DXG with 2.6.22 and might not work on the K1 with 2.6.10.

Actually, my hello program was built with libc6 not uclibc so I doubt mine would work unless I built a -static version.

The gcc was able to find the includes without a problem. I had a difficult time finding all of the correct locations for the libraries and finally had to move the crt1.o files to my build directory. These problems might have been due to my symlinks all over the place. I also had some 'sh: file not found' errors from bad linking by 'ld'. I finally compiled only '-c' to the hello.o and then ran 'ld --verbose' separately to track down the library search pathology. I never could get the linker to find the crt1.o type files and just added them to my hello directory to finish linking.

That is cool the gumstix uclibc binaries show some promise.

[knc1]

Unless of course you want to just use newer libraries (or even non-uClibc libraries).

Linux (actually, any ELF system) can support multiple sets of system libraries concurrently.

I published a "HowTo" here on that subject -
See my "ARMhf on Kindle" thread.
Found also in that thread are examples of how to get the loader to report what it is doing (and thereby, what the source of the problem is with a bit more control than --verbose).

All of these trouble reports about trouble building for the K1 xScale processor should be a non-issue.

And the BuildRoot project people added support for multiple system libraries for the use of after-market addition builders at my request.

[geekmaster]

Originally Posted by knc1

Unless of course you want to just use newer libraries (or even non-uClibc libraries).

Linux (actually, any ELF system) can support multiple sets of system libraries concurrently.

I published a "HowTo" here on that subject -
See my "ARMhf on Kindle" thread.
Found also in that thread are examples of how to get the loader to report what it is doing (and thereby, what the source of the problem is with a bit more control than --verbose).

All of these trouble reports about trouble building for the K1 xScale processor should be a non-issue.

And the BuildRoot project people added support for multiple system libraries for the use of after-market addition builders at my request.

It may seem easy in retrospect, but this is all mostly new to new, and I did follow your "HowTo" thread. I made (what I thought were) appropriate substitutions. The resulting executables failed on my K1. I will try again...

[knc1]

Originally Posted by geekmaster

It may seem easy in retrospect, but this is all mostly new to new, and I did follow your "HowTo" thread. I made (what I thought were) appropriate substitutions. The resulting executables failed on my K1. I will try again...

It is really strange that something can give a person of your experience so much trouble.
Your the teacher, not the student.

Could you make a copy of the file system and post it somewhere I could grab a copy?

If you don't have a private place to post it handy, PM me the public key of an ssh key-pair and I'll setup a sftp location for you to push it to on one of my servers.

I don't have a K1, but maybe I can learn from the file system what might be causing you so much trouble.

[geekmaster]

Originally Posted by knc1

It is really strange that something can give a person of your experience so much trouble.
Your the teacher, not the student.

Could you make a copy of the file system and post it somewhere I could grab a copy?

If you don't have a private place to post it handy, PM me the public key of an ssh key-pair and I'll setup a sftp location for you to push it to on one of my servers.

I don't have a K1, but maybe I can learn from the file system what might be causing you so much trouble.

Just poking around in the dark. I have often had problems with missing libraries and depedencies when building linux stuff -- I spend too much time in Windows, and doing win32 development. I am somewhat proficient in bash using very basic linux tools, and I have some (linux 2.4) kernel module experience, but building larger linux things from scratch has always been a difficult challenge. Some linuxish things just have not "clicked" for me -- I am still waiting for that "aha!" moment. I have had struggles like this many times over the years (often with eventual success) -- I just did not publish anything about them. What I am doing here now (letting folks look over my shoulder as I do battle with "unknown unknowns") -- that is a new thing...

I can grab K1 dirs as tarballs, but I have had little success imaging the (useful) partitions. Though I have recently read how the firmware updates build the partitions by sending "cookies" (magic numbers) to the "BL" flash drivers. When partitions are unlocked with those magic cookies, then 'dd' can access them, but some cookies can be very destructive so I am yet wary of that, and it is still not sure what all of them are yet. I just discovered that one of them is the "recovery-kernel".

Poking around is slow and tedious with no terminal support -- I really need to find a 0.5mm ribbon cable so I can connect to the serial port (or order some on ebay and wait a month)...

[knc1]

tarballs of whatever you can get should be a good starting point.

[donB006]

Originally Posted by knc1

I published a "HowTo" here on that subject -
See my "ARMhf on Kindle" thread.
Found also in that thread are examples of how to get the loader to report what it is doing (and thereby, what the source of the problem is with a bit more control than --verbose).

All of these trouble reports about trouble building for the K1 xScale processor should be a non-issue.

I couldn't find your thread except stumbled on the optware thread. I think that might be another choice with the gumstix archive.

I found several optware builds that might work on the K1 using arm with uclibc. I see where the nslu2 uses glibc not uclibc so those packages wouldn't work. http://www.nslu2-linux.org/wiki/Optware/Platforms

Trying to match the CPU and with the kernels and libraries to find working binaries is probably not the best technique. Maybe staying with the cross-compiling is a better option if that is almost setup correctly. I mention the following only in case somebody else is following this thread and looking for other binaries to add to their readers and not wanting to build their own. http://ipkg.nslu2-linux.org/feeds/optware/

PS- Anybody wanting to look inside the Kindle1 OS using kindle_update_tool.py can get the full rootfs.img from Amazon with Update_kindle-1.2.bin

drwxr-xr-x 6 root  root      4096 May 10 07:26 .
drwxr-xr-x 3 root  root      4096 May 10 07:25 ..
-rw-r--r-- 1 61967   502 15466496 Jan 28  2009 content_fs.img
drwxr-xr-x 2 root  root      4096 May 10 07:25 eink
-rw-r--r-- 1 61967   502   786432 Jan 28  2009 initrd_fs.img
-rw-r--r-- 1 61967   502   786432 Jan 28  2009 initrd-recover_fs.img
drwxr-xr-x 2 root  root      4096 May 10 07:25 ioc
-rw-r--r-- 1 61967   502 11665408 Jan 28  2009 root_fs.img
drwxr-xr-x 2 root  root      4096 May 10 07:25 scripts
-rw-r--r-- 1 61967   502  1310720 Jan 28  2009 uImage
-rw-r--r-- 1 61967   502     1223 Jan 28  2009 update-016-KU3-029987.dat
drwxr-xr-x 2 root  root      4096 May 10 07:25 utils

[geekmaster]

Originally Posted by donB006

PS- Anybody wanting to look inside the Kindle1 OS using kindle_update_tool.py can get the full rootfs.img from Amazon with Update_kindle-1.2.bin

Actually "kindletool" is a much better option, and can be downloaded from NiLuJe's snapshots (source at github). I use the mingw32 .exe version on Windows, but there are versions for other OSes as well (and it even tells you your root passwords if you give it your serial number, including for the latest kindles). Much more contemporary that the older python versions, with better support. Yes, I did unpack the source for the K1, and in fact that is where I copied the /lib folder from in my recent chroot compile attempts. Though I think it may be missing some libs I need to run gcc...

And those scripts in the update give me great clues to accessing raw partitions, which were nowhere to be found in scripts installed on my K1. That repository of gumstix packages seems to be missing stuff in the uclib versions.

I need some coffee so I can think somewhat more clearly. Trying to do tech stuff while barely awake is too distracting. I am suffering from severe caffeine deficiency at the moment... :O

[knc1]

Would the current 1.2.1 firmware be packed as a full image also?

[geekmaster]

Originally Posted by knc1

Would the current 1.2.1 firmware be packed as a full image also?

1.2.1 is a tiny update file, so no... Probably just the cacert update and a small number of other trinkets... 1.2 is full sized though, and has "full flash" scripts (even with flash images for some of its peripheral devices). I also unpacked the update.bin files that are created when you unpack the main 1.2 update.bin (it is a multi-stage install). However, the rootfs seems a bit anemic to me...

[donB006]

I couldn't loop mount the root_fs.img so found the tool unsquashfs in the squashfs-tools.deb will unpack the root_fs.img filesystem without needing to be loop mounted.