Geekmaster's adventures in K1 spelunking

[geekmaster]

Okay, I am playing around in a qemu-arm-static chroot that combines the K1 tarballs, a gumstix angstrom (armv5te) rootfs, and the k3 optware rootfs image folks were playing around with here (with ipkg support). I updated /opt/etc/ipgk.conf to include the gumstix armv5te repository, but it redirects to https (as do many websites these days) and the wget in this environment is only http and ftp. So, I downloaded a static arm wget with https support here:
http://pogoplug.s3.amazonaws.com/wget

I just "relearned" that replacing a symlink to busybox with a standalone replacement does not work while working in a shell provided by that busybox. Busybox intercepts intrinsic (built-in) commands, ignoring the search path. I can call /usr/bin/wget myself, but the problem is that I cannot tell ipkg to do that. Now I need a shell that does not include wget, or that has wget with https support.

I remember fighting a similar wget problem in optware on the k3, where some folks hex-editted ipkg to resolve the problem (though I think I found a different solution, perhaps involving a subshell -- not sure, but it is in a post somewhere here).

I am *hopeful* that I can install gumstix arm5te packages (especially gcc).

Or perhaps knc1 is right and I am just wasting my time?

[geekmaster]

A "normal" person would have given up long ago, and decided NOT to bother supporting the K1, right? But I have never been good at convincing myself that the solution to a problem is beyond my grasp. Either it was easier when I was younger, or my memory glossed over the painful parts of the sometimes-difficult acquisition of technical knowledge and skill, especially when exploring paths in the wilderness (such as K1 native mode app development).

[geekmaster]

Originally Posted by TinyApps.Org

... Apparently in Kindle 3.1 ...

It appears we have a lab126-compatible kernel config file for the K3 (see link above), so maybe something similar for the K1? But then yifanlu posted about building a custom kernel too, and we need a custom gcc, not a kernel. But still, it looks like a possibly useful place to start exploring configs...

[knc1]

Originally Posted by geekmaster

- - - - -
Or perhaps knc1 is right and I am just wasting my time?

Only if hoping to use the factory supplied system libraries by finding a uClibc toolchain that just happens to match the Lab126 toolchain build.

You could still build against more modern system libraries (musl is probably the best choice now), install them in /mnt/us and set the binaries you create to use the /mnt/us/* system binaries rather than Amazon's.

That way, all you have to match is the Major.Minor kernel version headers.
(Hmm... I am not sure if musl will build for 2.6 but it is widely used in embedded work, and so is 2.6 still in use - so its worth checking out.)

Even the kids here will die of old age if they wait for me to have time to do it.

[geekmaster]

I thought (for apps, not kernel modules) that you just needed a static build, and your app was self-contained, only relying on system calls. The problems seem to be that some compilers seem to be generating code with instructions we do not want (regardless of our gcc params), or our static apps must be only partily static (calling incompatible libs), or embedding libs with incompatible instructions.

I was under the impression that an old enough compiler linked with old enough libs would not use incompatible arm instructions, and all would be fine if I stay close to the metal (native mode) and just make dependable system calls (or use /proc interfaces as needed). But my recent experience shows that my impression was naive, apparently. Things are not as easy as they seemed in the recent past...

The more you learn, the more you realize that you do not know (the unknown unknowns). The only folks who (think they) know it all, are those freshly graduated from tech school. At least until the older wiser folks in industry rub their noses in the musty dusty rusty corner cases of reality. But sadly, the older wiser folks have much to learn too, when diving into new territory such as this, for me.

[geekmaster]

Another problem is that google chrome will not let me access http://uclibc.org because it redirects to https://uclibc.org and it has a bad security certificate (or may be under a MITM attack, according to chrome). I will try a different browser that does not "protect" me like a big brother...

Hmm, firefox says the uclibc.org expired yesterday, but I was having this problem last week on chrome, so that seems odd. Anyway firefox at least has the "advanced" option to view the site anyway, unlike chrome.

These might help:
https://mocko.org.uk/projects/armbinaries/
And these:
https://github.com/andrew-d/static-b...ries/linux/arm

[geekmaster]

I now have a mix of static and dynamic binaries in my k1_build folder, and when I chroot into it, some of the dynamics throw errors about missing or incompatible libraries. I really need a collection of all static arm binaries, but finding them is few and far between. I will need to build almost all tools from scratch it seems, just like everybody else seems to build either toolchains and/or complete root filesystems. And that is reported to take hours or days to build (depending on the speed of your desktop PC or target system). And yes, a lot of folks out there reported giving up on a chroot solution and reverted to building in their target system (just like folks here were/are building in K3 devices).

If building in a chroot on a desktop PC, it seems safest to just use a full static rootfs, so not fits and starts fighting will all the library incompatibilies with you import existing pre-compiled tools.

The windows folks have gone to extremes to assure backwards compatibility, but the linux folks just seem to think you will compile all your build tools (and/or root filesystems) from source for each project, it seems. Or so it seems...

[NiLuJe]

FWIW, a simple TC (i.e., a bare sysroot, simply glibc/gcc/binutils) build takes 8 minutes over here (if the mirrors are cranky, it may actually take longer to download the source code than to build it...).
(Granted, that's over all 8 threads of an i7 6700K @ 4GHz, but it took only roughly twice to three times as long on my old C2D w/o SMT... Which is also mostly how long it takes on my buildbox, an old i3 2130 @ 3.4GHz).

[knc1]

A similar situation with Aboriginal Linux (which builds the minimum needed to self-host) -
A very short build time (mostly spent downloading the sources).

[NiLuJe]

And on the plus side, if you go fully static with musl (or ship your own libc & loader àla @knc1), you can *probably* avoid a whole lot of hassle trying to mix'n match old libc & gcc versions, which is where most of the hassle lies when you want to target dynamic linking on those old crappy systems.
You're mostly left with dealing with old kernel headers, which *should* be less problematic to overcome.

[geekmaster]

I am totally happy doing static build, which I also do on Windows apps. I hate when apps break because they are using the wrong SDL dll, or the wrong cyg1.dll, or whatever other brand of DLL hell falls on you today. DLL hell exists here too, in the form of shared library incompatibiliies (but .so instead of .dll).

For production code, I only use DLLs when I must (such as LGPL that only allows dynamic linking). I stick with BSD or MIT or similar licenses whenever possible, so I can use my hobby code in production environments to minimize re-development efforts.

Just for a re-test, I built a STATIC hello, using a chroot of arm debian lenny:

PHP Code:

mint17-32 k1_build # file /media/user/Kindle/hello
/media/user/Kindle/hello: ELF 32-bit LSB  executable, ARM, EABI4 version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, stripped 


And just like other attempts, it seg faults (even though I used all the switches knc1 suggested that my GCC would accept, and GCC is using the /lib copied from the K1 (from the tarball I provided for him). Depending on compiler, it is usually either "seg fault" or "illegal instruction". I should check the assembler output, but bed time...

And while I am posting, I finally got around to testing reading various switches using the /proc interface:

PHP Code:

#> cat /proc/fpow/uc/ac_adapter
1

#> cat /proc/fpow/uc/headphones
1

#> cat /proc/fpow/uc/power_switch
1

#> cat /proc/fpow/uc/wan_switch
1 


This time I plugged in headphones, and the power supply (a small barrel jack, not USB), and I turned on the (pysical) radio switch. They all report '1' as seen above. In previous runs, I did not have headphones, nor power supply, and the radio switch was off, so only the power switch reported as on. I suppose I might be able to turn the power switch off and see that change to zero, after selecting UYK (but before my script runs).

One thing interesting, when I did UYK to run my script, a message that notifies me that the update may take awhile was in a different position on the display, and in a much smaller font. Now that I ran it again with radio off, it returned to the larger font near the botton of the display. That smaller script stayed there much longer too -- my kindle must have been "phoning home". And just FYI, this one is registered and identifies itself as "Rob's 15th Kindle", betraying the fact that about 10-percent of my kindle collection has been registered...

[geekmaster]

Hmm, at this link:
https://www.raspberrypi.org/forums/v...30036&p=264425
they claim tcc-compiled code for arm has intermittent segfaults, in different tests at different times (sometimes all tests succeed). And programs are less likely to fail with the -run switch (which runs C source as a script). Weird. The tcc version in our threads cannot read argv and argc either (reported as "standard" behavior in arm tcc).

[NiLuJe]

Note that -static is far from enough to do actual fully static builds (i.e., no libc).

See the gcc specs used by the musl wrapper (as well as the terse GCC manual on options affecting linking).

https://github.com/GregorR/musl-cross might be a good start to build such a TC?

CT-NG appears to have musl support, but I'm not sure how stable/tested it is. Same for BR, but @knc1 might know more there .

[geekmaster]

It seems like PURE static is the only thing safe for a K1, until we can get a compatible (i.e. IDENTICAL) uclibc set of tools that exactly match the uclibc used in the K1 (based on claims at uclibc.org that config changes to uclibc can require recompiling ALL binaries that use it).

Regarding small libc libraries (whilst I prefer bare metal -- talking direct to I/O ports), I have stumbled across this more than once over the years, and I think it kinda cool:
http://www.muppetlabs.com/~breadbox/software/tiny/
http://www.muppetlabs.com/~breadbox/...ny/useful.html

The bulk of my original windows programs do direct winapi calls, and avoid libraries whenever possible. I have more control that way, and I feel more comfortable closer to the bare metal where library mismatches are unlikely to occur, so those tiny direct API call programs at the link above fascinate me. That seems most likely to work on the K1 -- I should try building some that way (with suitable arm instructions, of course), and the asm could call C as well, so just an asm wrapper around C would be my goal -- no libc needed. The difficulty will be figuring out the linkage needed for kernel modules (and they should be even easier, perhaps)...

Or this for bare-metal arm apps:
https://balau82.wordpress.com/2010/0...ogram-for-arm/

In linux, everything is a file, so this:
https://en.wikipedia.org/wiki/Write_..._calling_write
Yeah, that's is in my bare-metal ballpark, for sure. If I can write to the framebuffer and read input events, it's all cool...

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

[NullNix]

Originally Posted by geekmaster

I now have a mix of static and dynamic binaries in my k1_build folder, and when I chroot into it, some of the dynamics throw errors about missing or incompatible libraries. I really need a collection of all static arm binaries, but finding them is few and far between. I will need to build almost all tools from scratch it seems, just like everybody else seems to build either toolchains and/or complete root filesystems. And that is reported to take hours or days to build (depending on the speed of your desktop PC or target system).

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.

Originally Posted by geekmaster

The windows folks have gone to extremes to assure backwards compatibility, but the linux folks just seem to think you will compile all your build tools (and/or root filesystems) from source for each project, it seems. Or so it seems...

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, but if you move out of the embedded world glibc is very strict about this, even preserving bug-compatibility in compatibility symbols via symbol versioning, as is X11 and other major system libraries like Qt (Gtk used to be good but is frankly taking the piss of late, ditching major features and breaking programs willy-nilly: as long as the formal ABI doesn't change, who cares if the entry points now do nothing? Nobody will care about that! Increasingly this is turning out to be true as this behaviour drives onetime library users to rewrite for Qt instead...)