Geekmaster's adventures in K1 spelunking

[knc1]

Originally Posted by geekmaster

- - - -
If I do not USE any libc (or other) library (i.e. as bare-metal as I can get), how can the code fail on a K1? Well, unless everything I have learned about the K1 is a lie, of course. Not sure about anything anymore... Need some sleep...

But if I must stick with a library, then perhaps musl is the (or a) way to go...

By attempting access to the ARMv5 floating point registers.
The xScale does not have any and the access will trap.

There are common runtime program initialization objects, provided by the compiler, not the system library, that may be making those accesses.

Perhaps: To set the fp control register to a known state or to save/restore it across the execution of the program, or to . . . .

This is why I gave you a list of options with which to build your static HelloWorld application -
So that if it did not run on the K1 it could be disassembled and read by a human to find the exact instruction that is causing your problems.

[geekmaster]

Originally Posted by knc1

By attempting access to the ARMv5 floating point registers.
The xScale does not have any and the access will trap.

There are common runtime program initialization objects, provided by the compiler, not the system library, that may be making those accesses.

Perhaps: To set the fp control register to a known state or to save/restore it across the execution of the program, or to . . . .

This is why I gave you a list of options with which to build your static HelloWorld application -
So that if it did not run on the K1 it could be disassembled and read by a human to find the exact instruction that is causing your problems.

Yeah, some of those options did not work in the tool I was using at the time. I am setting up an aboriginal linux toolchain now, using the K1 1.2 rootfs provided in the update*.bin file downloaded from amazon. My plan is to try your options again using that, and to explore the assembler output, and the ELF file headers, and such.

Part of my detour last night was to learn how app loading works on linux, and how apps can talk directly to the kernel via system calls (essentially what a fully static app SHOULD do, when all libs it uses are linked into it).

And yes, I am aware that a full arm5te has floating point hardware, but the xcale variant lacks floating point -- no doubt the main source of problems I have stumbled into so far.

It is easy to become overwhelmed when there is so much to learn all at once and all the online tutorials and links I could find with google fail for one reason or another (and most of them have missing links to downloads and even other related content on their own website).

Aging is not kind to internet content -- bit rot, corporate buyouts breaking links (like codesourcery, arm UK, etc.), and recent problems with http pages redirecting to https while old autodownloaders use old wget that does not support https. I suppose it is like getting old for humans -- many of the old structural landmarks you navigated by for a lifetime are not there anymore (and memories are like landscapes if you used the ancient "memory palace" method to store vast quantities of knowledge in your head -- getting forgetful is because mental landmarks have been consolidated or pruned when you spent awhile not using related information).

Anyway, each time I try something new, I have my hopes up. I hope aboriginal linux with a K1 rootfs will work for me. We shall see. I am trying a different approach today -- instead of coffee for breakfast, I am drinking beer.

[geekmaster]

Originally Posted by NullNix

You might find the buildroot project useful here -- you won't want the disk image it produces, but you can loopback-mount it and copy off heaps of stuff.

This is more a description of the embedded world than the Linux world. uClibc in particular is explicit about providing almost no source or binary backward compatibility at all...

I can see this even in the kindles. Stuff I built for the K3 works on everthing from K2 to PW3 (and perhaps more), all being glibc based (and also on various firmware versions, and even when booted to diags). However, lab126 DID fubar the firmware v5.x eink libraries by adding new fields INSIDE a structure, making it incompatible between versions. And to complicate matters, the new structure had the same name as the old one, AND the header file had the same name as the old one. My solution (as seen in gmplay) was to NOT include those headers, but to copy (and rename) both structures from both versions of the header files. My code tests to see which structure to use, and it has worked well so far on older and newer kindles (except for the K1, of course).

The K1 has no floating point, a more primitive eink controller (only 2-bit/4-color support), and (self-incompatible) uClibc instead of (very stable between kindle models) glibc.

If I have to (but hopefully not), I can use a little ASM shim to virally inject my code into existing lab126 apps, I suppose -- but that seems desperate and lame. The muppetlabs website I linked earlier shows how to do that for x86 code, so somehting similar should work on arm processors. However, I want to build (not exploit) apps, in a more respectable way.

I have my hopes up for aboriginal linux, which I will resume today.

[geekmaster]

Last night (actually early this morning), I needed to loop mount the JFFS2 rootfs image from the FW 1.2 update file. I chose to sleep a bit first. Now I am thankful I posted my steps to loopmount JFFS2 in this thread. It was non-trivial AND had to be adapted from (almost but not quite working) instructions I found on google (after multiple attempts). There is an AWFUL LOT of information out that (found with google) that just DOES NOT WORK these days, though it likely DID work when it was posted. I wonder what future generations will think when they attempt to use the huge landfill of information excavated from old websites, only to find it suffered from horrible bit-rot...

Originally Posted by bit rot @ catb

bit rot: n.

[common] Also bit decay. Hypothetical disease the existence of which has been deduced from the observation that unused programs or features will often stop working after sufficient time has passed, even if ‘nothing has changed’. The theory explains that bits decay as if they were radioactive. As time passes, the contents of a file or the code in a program will become increasingly garbled.

There actually are physical processes that produce such effects (alpha particles generated by trace radionuclides in ceramic chip packages, for example, can change the contents of a computer memory unpredictably, and various kinds of subtle media failures can corrupt files in mass storage), but they are quite rare (and computers are built with error-detecting circuitry to compensate for them). The notion long favored among hackers that cosmic rays are among the causes of such events turns out to be a myth; see the cosmic rays entry for details.

The term software rot is almost synonymous. Software rot is the effect, bit rot the notional cause.

[geekmaster]

A script just finished that had been running all night, scanning all my mounted drives using "file" to search for ARM static executables. Interestingly, the vast majority of ARM static programs are "ldconfig", which makes sense in that you cannot dynamically load the loader configuration utility with an unconfigured loader.

I did find a few static busybox versions, including a busybox-4l which does not show any EABI info or linux version info, which might be worth trying (though I suspect I did try it at one point and it failed, but I will try again).

It also looks like all the statically-linked apps copied from K1 firmware (regardless of firmware version) specify "for GNU/Linux 2.0.0" which is much older than any other ARM static app on my storage devices (with most non-K1 stuff specifying 2.4.x or 2.6.x).

[knc1]

Originally Posted by geekmaster

- - - -
Anyway, each time I try something new, I have my hopes up. I hope aboriginal linux with a K1 rootfs will work for me. We shall see. I am trying a different approach today -- instead of coffee for breakfast, I am drinking beer.

When in doubt, e-mail Rob.
He has spent his entire professional life working embedded Linux.

Given enough details, he can probably provide the answer you need.

Best chance of a reply is to frame the question based on "I am having this/that problem with your ... and xScale processors."

He also knows Eric, who wrote uClibc.

Network, network, network . . . .

Rob and I are currently "on the outs" - so it wouldn't do any good for me to write him.
But there are a lot of people that I haven't (yet) picked a fight with in the industry - this can be solved.

[geekmaster]

Though just an item of curiousity at this point, I *DID* find a non-lab126 binary executable THAT WORKS on my K1. It is the busybox-arm4l mentioned previously, found with my "file" search. What is curious is that the "file" info does not display any EABI or Linux version info (which is what caught my attention and made decide to test it):

PHP Code:

mint17-32 k1_build # file /media/user/Kindle/busybox-armv4l 
/media/user/Kindle/busybox-armv4l: ELF 32-bit LSB  executable, ARM, version 1, statically linked, stripped 


And here is its output when run on my K1:

PHP Code:

#> /mnt/us/busybox-armv4l
BusyBox v1.21.1 (2013-07-08 10:00:38 CDT) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2012.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list[-full]
   or: busybox --install [-s] [DIR]
   or: function [arguments]...

    BusyBox is a multi-call binary that combines many common Unix
    utilities into a single executable.  Most people will create a
    link to busybox for each function they wish to use and BusyBox
    will act like whatever it was invoked as.

Currently defined functions:
    [, [[, acpid, add-shell, addgroup, adduser, adjtimex, arp, arping, ash,
    awk, base64, basename, beep, blkid, blockdev, bootchartd, brctl,
    bunzip2, bzcat, bzip2, cal, cat, catv, chat, chattr, chgrp, chmod,
    chown, chpasswd, chpst, chroot, chrt, chvt, cksum, clear, cmp, comm,
    conspy, cp, cpio, crond, crontab, cryptpw, cttyhack, cut, date, dc, dd,
    deallocvt, delgroup, deluser, depmod, devmem, df, dhcprelay, diff,
    dirname, dmesg, dnsd, dnsdomainname, dos2unix, du, dumpkmap,
    dumpleases, echo, ed, egrep, eject, env, envdir, envuidgid, ether-wake,
    expand, expr, fakeidentd, false, fbset, fbsplash, fdflush, fdformat,
    fdisk, fgconsole, fgrep, find, findfs, flock, fold, free, freeramdisk,
    fsck, fsck.minix, fsync, ftpd, ftpget, ftpput, fuser, getopt, getty,
    grep, groups, gunzip, gzip, halt, hd, hdparm, head, hexdump, hostid,
    hostname, httpd, hush, hwclock, id, ifconfig, ifdown, ifenslave,
    ifplugd, ifup, inetd, init, insmod, install, ionice, iostat, ip,
    ipaddr, ipcalc, ipcrm, ipcs, iplink, iproute, iprule, iptunnel,
    kbd_mode, kill, killall, killall5, klogd, last, less, linux32, linux64,
    linuxrc, ln, loadfont, loadkmap, logger, login, logname, logread,
    losetup, lpd, lpq, lpr, ls, lsattr, lsmod, lsof, lspci, lsusb, lzcat,
    lzma, lzop, lzopcat, makedevs, makemime, man, md5sum, mdev, mesg,
    microcom, mkdir, mkdosfs, mke2fs, mkfifo, mkfs.ext2, mkfs.minix,
    mkfs.vfat, mknod, mkpasswd, mkswap, mktemp, modinfo, modprobe, more,
    mount, mountpoint, mpstat, mt, mv, nameif, nanddump, nandwrite,
    nbd-client, nc, netstat, nice, nmeter, nohup, nslookup, ntpd, od,
    openvt, passwd, patch, pgrep, pidof, ping, ping6, pipe_progress,
    pivot_root, pkill, pmap, popmaildir, poweroff, powertop, printenv,
    printf, ps, pscan, pstree, pwd, pwdx, raidautorun, rdate, rdev,
    readahead, readlink, readprofile, realpath, reboot, reformime,
    remove-shell, renice, reset, resize, rev, rm, rmdir, rmmod, route, rpm,
    rpm2cpio, rtcwake, run-parts, runlevel, runsv, runsvdir, rx, script,
    scriptreplay, sed, sendmail, seq, setarch, setconsole, setfont,
    setkeycodes, setlogcons, setserial, setsid, setuidgid, sh, sha1sum,
    sha256sum, sha3sum, sha512sum, showkey, slattach, sleep, smemcap,
    softlimit, sort, split, start-stop-daemon, stat, strings, stty, su,
    sulogin, sum, sv, svlogd, swapoff, swapon, switch_root, sync, sysctl,
    syslogd, tac, tail, tar, tcpsvd, tee, telnet, telnetd, test, tftp,
    tftpd, time, timeout, top, touch, tr, traceroute, traceroute6, true,
    tty, ttysize, tunctl, udhcpc, udhcpd, udpsvd, umount, uname, unexpand,
    uniq, unix2dos, unlzma, unlzop, unxz, unzip, uptime, users, usleep,
    uudecode, uuencode, vconfig, vi, vlock, volname, wall, watch, watchdog,
    wc, wget, which, who, whoami, whois, xargs, xz, xzcat, yes, zcat, zcip 


Strangely, it claims to be a relatively recent version, so how and why its "file" info is stripped is a mystery (to me).

And for comparison, here is the output /bin/busybox on my K1:

PHP Code:

BusyBox v1.01 (2008.03.31-00:04+0000) multi-call binary

Usage: busybox [function] [arguments]...
   or: [function] [arguments]...

    BusyBox is a multi-call binary that combines many common Unix
    utilities into a single executable.  Most people will create a
    link to busybox for each function they wish to use and BusyBox
    will act like whatever it was invoked as!

Currently defined functions:
    [, addgroup, adduser, adjtimex, ash, awk, basename, bunzip2, busybox,
    bzcat, cat, chgrp, chmod, chown, chroot, clear, cmp, cp, crond,
    crontab, cut, date, dd, delgroup, deluser, df, dirname, dmesg,
    du, echo, env, expr, false, fdisk, fgrep, find, freeramdisk, getty,
    grep, gunzip, gzip, halt, head, hexdump, hostname, hwclock, id,
    ifconfig, ifdown, ifup, init, install, ip, ipaddr, iplink, iproute,
    kill, killall, klogd, linuxrc, ln, logger, login, logname, logread,
    losetup, ls, makedevs, md5sum, mkdir, mknod, mktemp, more, mount,
    mv, nc, netstat, passwd, pidof, ping, pipe_progress, pivot_root,
    printf, pwd, rdate, readlink, realpath, reboot, renice, reset,
    rm, rmdir, route, run-parts, sed, seq, sh, sleep, sort, start-stop-daemon,
    strings, stty, su, sulogin, sync, sysctl, syslogd, tail, tar,
    tee, telnet, test, time, touch, tr, traceroute, true, tty, udhcpc,
    umount, uname, uniq, uptime, usleep, vi, wc, wget, which, who,
    whoami, xargs, yes, zcat 


It seems that arm-static binaries need to be built built for GNU/Linux 2.0.0 (or need some mysteries file info stripping?). Or perhaps that is just a coincidence and all the other possible problems with instruction sets and libraries and nothing being "pure static" are the real culprits...

And regarding being on the outs, I have that problem with certain folks (mostly multimillionaires and billionaires who *used* to be my friends) not because I picked fights, but because a mutual "friend" picked fights in forums, while claiming to be me. And as for *our* "fights", we seem to have gotten past all that (for now). I have vast experience at some things, but I feel like a complete noob in this K1 stuff, so it is easy to admit my errors (poking around in the dark)...

EDIT: If nothing else, at least this new bigger busybox version adds a whole lot of new commands I can execute from my shell scripts on the K1. But especially, it supports '[[' and ']]' so I do not need to "fix" so many of my old scripts that rely on those commands. Ooohh... It has 'xz' too -- so now I can compress my .gmv vids to one-quarter the size of the .gmv.gz versions (even on the K1), but gmplay still will not run on the K1 (one of my first goals at this point).

[knc1]

In armv4 days, there was only one abi.

Try that on your Hello World: -arch=armv4
or whatever your compiler offers that is close.

[geekmaster]

Originally Posted by knc1

In armv4 days, there was only one abi.

Try that on your Hello World: -arch=armv4
or whatever your compiler offers that is close.

I did try that, along with -static. It did not work. I will try it after I build the aboriginal rootfs. I was busy with other stuff. Another option: I have a codesourcery arm-linux for bare metal, it looks for _start() instead of main(), and it needs a short assembler preamble to setup interrupt vectors (per the "bare metal arm" link I posted last night). I will probably try that soon too; I prefer working at system-call level anyway, and not (mis)depending on other libraries that will (probably) suffer from version mismatches in the future (both in windoze and linux).

[geekmaster]

I looked in my browser download history, and I found where that K1-compatible busybox-armv4l came from here: https://busybox.net/downloads/binari...busybox-armv4l

That working busybox version means that the armv4l packages I downloaded from landley.net (for the aboriginal project), are very likely to work on my K1. I am anxious to test these aboriginal linux files: cross-compiler-armv4l.tar.gz , system-image-armv4l.tar.gz , native-compiler-armv4l.tar.gz , root-filesystem-armv4l.tar.gz

I see that I also downloaded some files for armv4tl (with thumb support) and armv5l targets. I wonder if those would work on the K1 (they should, I think). And the aboriginal source code on github also has armv4l, armv4tl, and armv5l targets as well. Sweet!

[knc1]

My room is reaching its temperature limit.

I either have to turn on the A/C or shut down the computer (one more degree and it will make the decision for me).

Later - once the cool of the evening has come to central Texas.

[geekmaster]

Originally Posted by knc1

My room is reaching its temperature limit.

I either have to turn on the A/C or shut down the computer (one more degree and it will make the decision for me).

Later - once the cool of the evening has come to central Texas.

Meanwhile, I am freezing my ass off in Minnesota. What do Minnesotans do in the summer? If summer falls on a weekend, they have a picnic!

[geekmaster]

I see that when booting to aboriginal armv4l, "cat /proc/cpuinfo" shows it as 5TEJ (with java bytecode support, absent on the K1). That does not matter though, as long as we do not use that feature, I hope.

However, when I follow his directions here:
http://landley.net/aboriginal/README
it fails on the "gcc" step:

PHP Code:

(armv4l:1) / $ gcc -lpthread /usr/src/thread-hello2.c
hush: can't execute 'gcc': No such file or directory 


Starting ./dev-environment.sh instead of ./run-emulator (as his README says) lets me compile and execute the resulting a.out inside the emulator, but I have to exit and loop-mount the "hdb.img" file to copy the compiled binary to my K1. Doing that now...

Bummer! It segfaulted!

EDIT: Duh! Its file info show it as dynamically linked. Time for -static.

[NullNix]

Originally Posted by geekmaster

I can see this even in the kindles. Stuff I built for the K3 works on everthing from K2 to PW3 (and perhaps more), all being glibc based (and also on various firmware versions, and even when booted to diags). However, lab126 DID fubar the firmware v5.x eink libraries by adding new fields INSIDE a structure, making it incompatible between versions. And to complicate matters, the new structure had the same name as the old one, AND the header file had the same name as the old one. My solution (as seen in gmplay) was to NOT include those headers, but to copy (and rename) both structures from both versions of the header files. My code tests to see which structure to use, and it has worked well so far on older and newer kindles (except for the K1, of course).

Yeah. Debuggers have long had this problem, too, on arches like x86 and SPARC and nowadays ARM supporting both 32- and 64-bit code -- you might be on a 64-bit platform but people are going to want to debug 32-bit stuff without having to build a cross debugger -- so you need two versions (and, in the limit, N versions) of every structure in the victim you want to look at/modify, one with 32-bit type sizes and padding, one with 64-bit...

[NullNix]

Originally Posted by geekmaster

A script just finished that had been running all night, scanning all my mounted drives using "file" to search for ARM static executables. Interestingly, the vast majority of ARM static programs are "ldconfig", which makes sense in that you cannot dynamically load the loader configuration utility with an unconfigured loader.

Many of the rest are probably sln(1), a statically-linked ln(1) whose sole purpose is establishing the ld.so symlink after glibc is installed (without which, of course, no dynamically linked programs will have a hope of starting).