Geekmaster's adventures in K1 spelunking

[NiLuJe]

@GM:

Let's see how musl-cross fared...

Does this run?

[geekmaster]

Success! I added "-static" to the thread-hello2.c compile example shown in the aboriginal README, and it just said "Hello world!" on my K1.

I wish to thank knc1 for turning me on to aboriginal linux. I just wish I avoided some of the other dead ends before trying it.



Now, I have some work to do, then I will get gmplay running on my K1, with videos compressed to 1/4th the size they are now (as tested, using xv instead of gzip), and with 2-bit video support (in addition to 4-bit and 8-bit dithering routines now in gmplay). And sound too (already written, but untested). The K1 has sound...

I think the armv4l support is probably the newest we can do, because /proc/cpuinfo already reports it as arm5tej. Though it might be worth trying newer targets, just to see...

[geekmaster]

Originally Posted by NiLuJe

@GM:

Let's see how musl-cross fared...

Does this run?

It reported "Illegal instruction" on my K1.

[geekmaster]

The thing most special about the aboriginal linux chroot build environment is that (unlike other chroots) it begins by booting a linux kernel. That seems to make all the difference here.

[geekmaster]

Just for testing purposes, I tried a static build from the aboriginal armv5l image, and it segfaults on my K1.


Now I will try the armv4tl (we already know armv4l works) image. Nope, that segfaults too.

It appears that ONLY the aboriginal arm4l dev-environment can build working K1 binaries, out of everything I tried (which is quite substantial).

One thing interesting is that the binaries from arm4l, arm4tl, and arm5l all report the same "file" info. And the build systems for all three report /proc/cpuinfo as arm5tej.

Now to use aboriginal armv4l to built an arm tcc that can run on the K1, eh?

[NiLuJe]

You might want to check with readelf what's "extra" in there... Doesn't that T stand for thumb? (Which, according to the K1 cpuinfo, *should* be supported, but Thumb1 was weird, so, who knows...).

At least I feel slightly better about my musl-cross experience (which was targeting armv5te/xscale) ;p.

EDIT: Granted, I forgot -mno-unaligned-access, crap.

[NiLuJe]

On the off chance that the -mno-unaligned-access SNAFU was important, what about this one?

[geekmaster]

I just tried the armv4l static on both K1 and PW3. On K1 thread-hello2, but it FAILED on the PW3 (Illegal instruction).

I also reran NiLuJe's musl-cross hello on both devices. Like before, it failed on the K1, but it ran fine on the PW3 (reporting "Hello World from ./kindletool_tmpfile_XXXXXX").

Unless I can code at a deeper level (i.e. only system calls), it seems like my apps will need two versions, one for the K1, and one for all other kindles, and a launcher script to figure out which version to run (based on serial number). I would be a lot happier if I could compile something that would run on all eink kindles.

I will try running the K1 /bin/busybox in the PW3 and see how it chokes...

[geekmaster]

Originally Posted by NiLuJe

On the off chance that the -mno-unaligned-access SNAFU was important, what about this one?

Nope. Illegal instruction on the K1, though it does work on my PW3 (just like your previous version).

Also, I tried running K1 /bin/busybox on both K1 and PW3. It runs on the K1, but fails ("Illegal instruction") on the PW3. Now, if you can just make it blow up on the PW3, maybe it will work on the K1?

How can something compiled for armv4l that works on an xscale arm5te processor get an "Illegal instruction" on an i.MX6 SoC? That just seems strange...

But with K1 busybox failing on a PW3, there is not much hope of any simple way to build binary code that runs on all the kindles. All these "Illegal instruction" traps (especially when migrating old code to new kindle models) is more than a little puzzling, indeed...

[geekmaster]

I am really curious what ARM instructions are working on the K1 but failing on the PW3.

If I were THAT intereseted though, I could write an assembly language instruction test suite, and test it on all the kindles I own.

I can now see why android strongly recommends that developers code their apps in java rather than native mode (and kinda sorta amazon too), to avoid having android apps that only work on small segments of the phone market (though in reality, that is really the case anyway even with java apps, being dependent on other hardware and features in the phones, and artificial limitations imposed on lesser models by manufacturers).

[geekmaster]

I just tested the busybox-armv4l downloaded from busybox.net, and it fails on the PW3 as well (and works on the K1).

Apparently ARM processors are not upwards-compatible (or at least not across different manufacturers). Old apps just will not work (even when static compiled) when ported to new ARM-based hardware, and must be rebuilt.

Oh well, such is life. At least I am (still) ecstatic that I *CAN* build from source code for the K1. Remaining difficulties are just trivialities to hide from the end-user.

[geekmaster]

Ahh... Just like NiLuJe's musl cross failed on the K1, it seems that the arm4tl and arm5l builds also failed BECAUSE those aboriginal targets were recently converted from uclibc to musl (as recently posted at the aboriginal website landley.net).

I guess that I am very lucky that the armv4l target did not yet get ported to musl, or I would probably still be hunting for a K1 toolchain...

Now in retrospect, I know that I could probably track down older versions of armv4tl and armv5 (based on uclibc) and have some reasonable chance that they would generate K1-compatible code.

Strange though how the musl-based code fails with "illegal instruction" errors -- do they link in some code that was compiled for some other target?

[knc1]

Originally Posted by geekmaster

I just tested the busybox-armv4l downloaded from busybox.net, and it fails on the PW3 as well (and works on the K1).

Apparently ARM processors are not upwards-compatible (or at least not across different manufacturers). Old apps just will not work (even when static compiled) when ported to new ARM-based hardware, and must be rebuilt.

Oh well, such is life. At least I am (still) ecstatic that I *CAN* build from source code for the K1. Remaining difficulties are just trivialities to hide from the end-user.

I took a different approach - -
I googled xScale emulators - found a couple open source - and started reading the emulation code . . . .

Whoot!
The mmu on xScale is different - its control register does not support 'read'.

Now I have never heard of that one before.
And I don't know how that would be seen in user-land (the kernel should be hiding such details).

But that is one more thing that Intel did not grow into the silicon.

PS:
Are you sure that K1 has an Intel xScale processor? (as in having read the part number on the chip)
Or does it have the TI knock-off (OMap)?

The on or two early hardware teardowns I read on the K1 claim its a TI OMap.
If it is, you might not be able to see the part number - they where a 'stacked' chip (IIRC) - the RAM package soldered to the top of the CPU package.

[knc1]

A note on Lab126 scripting - -
On touchscreen devices, you may have noticed that they are writing HTML reports.

I couldn't let them outdo us -
https://www.mobileread.com/forums/sho...d.php?t=271929
The cpu report is HTML (although the extension is .txt, a requirement for viewing HTML documents with the stock Kindle reader).

= = = =

Hey, look at me, sometimes I actually write something here that isn't just an answer to a question (when I can get away from the 'help desk').

[geekmaster]

Originally Posted by knc1

PS:
Are you sure that K1 has an Intel xScale processor? (as in having read the part number on the chip)
Or does it have the TI knock-off (OMap)?

The on or two early hardware teardowns I read on the K1 claim its a TI OMap.
If it is, you might not be able to see the part number - they where a 'stacked' chip (IIRC) - the RAM package soldered to the top of the CPU package.

It reports as a PXA255. Wikipedia claims it has a PXA255. The GPL code also calls it that. The gumstix Apollo eink dev kits (which this is based on) used that. However, it is possible that they substituted a different part number later in the development cycle. I have never seen teardown pictures with the back cover removed (only the outer cover, for access to the serial port hatch). I will need to do that, I guess (unless google CAN find a teardown photo showing the chipset).

Kindle 1: Marvell Xscale PXA255 400 MHz, ARM9