Geekmaster's adventures in K1 spelunking

[geekmaster]

I hate struggling with toolchains. Not my cup of tea. If somebody can give me some useful hints about compiling WORKING binaries for the PXA255 in the K1, please do so. Thanks.

[geekmaster]

I tried building gcc from the amazon source code for my K1, but it errored out during the compile -- perhaps a configuration error. So I tried another prebuilt toolchain:
https://github.com/samsheff/Amazon-K...ross-Toolchain

However, a "hello world" built with that segfaults on my K1. Windows toolchains are much more backwards compatible. Why does linux need a specific flavor of a specific version of a toolchain (and even with specific flags, for kernel builds)? How do sane people figure out which specific set of options?

There is too much to read and too little time. And as I said, the tcc for kindles creates code that also does not work on my K1. What is so different about an armv5 that all the existing kindle binaries either are not recognized as executable, or get "illegal instruction", or segfault? I need to put this aside for a bit, and go outdoors before it starts snowing again...

[knc1]

The usual suspect is the difference in how un-aligned accesses are handle ARMv5 and ARMvLater.

Use only aligned accesses to work-around the problem.
Hmm...
There should be compiler flags to 'fix' your source code for you during compile.

[geekmaster]

I tested my hello.c built with the PXA255 toolchain (supposedly compatible with the K1), and it ran fine in my K5. So it I *can* compile code that works on the K1, perhaps it will also work on later kindles without recompiling? I hope so... But then I will need to recompile ALL the hacks I want to support, so they can run on "all the kindles"...

So, yeah, now I need to learn enough ins and outs about "compiler flags", eh? I never had these problems on windows, though I was fond of building everything with vc6 for win98 (so it would work on "all the windows boxen")...

Time to find the LOWEST COMMON DENOMINATOR toolchain that can support all the kindles (with the exception of kernel modules, which I also plan to build when I have *time* to get compatible toolchains working for each specific kernel version, and with all the right flags and options set)...

I am not a happy camper right now, and I am not getting an younger burning time trying unsuccessfully to build apps from source. Even COBOL was easier than THIS! And yes, some of my COBOL programs were dynamically loading tcclib.dll (to be compliant with LGPL), and they used tcc to compile and run C scripts (used as search filters). Even that was easier than this...

But at least now I have a toolchain that I can use to compile my kindle video player (with sound support). I want gmplay to support the K1 2-bit video as well (4 pixels per byte). When I have time, I want to try pumping sound out the accessory port pads on the bottom of most kindles, and also perhaps out the power LEDs. A photocell connected to amplified speakers would not be so bad, for kindle sound, would it? But the accessory power pads can drive an LED reading light, so they ought to be able to drive a small speaker or headphones, I think...

[knc1]

Your looking at it, the K1 is the lowest common denominator.
Everything else is ARMv6 or ARMv7 (both of which run ARMv5 code).

[geekmaster]

Originally Posted by knc1

Your looking at it, the K1 is the lowest common denominator.
Everything else is ARMv6 or ARMv7 (both of which run ARMv5 code).

Now if I could just find or build a toolchain that works on the K1 PXA255 (unlike the toolchains that were SUPPOSED to support this processor but failed when I tested them). It would also be nice if tcc could be tweaked to work on it too...

[geekmaster]

I tried adding -march=armv5 to the gcc command line. Still not working. Not sure what to try next...

[knc1]

-mtune=xscale -mno-unaligned-access
Ref: https://gcc.gnu.org/onlinedocs/gcc-4...ml#ARM-Options

[geekmaster]

The older gcc versions that were supposed to support the PXA255 processor did not support -mfloat-abi=softfp. I tried building with the latest gcc in my recent linux mint, with -march=armv5 and -mfloat-abi=softfp, but still not working.

Any idea what flags (and/or gcc versions) I should use, so I can support the armv5 K1 instead of just armv7+ processors?

[knc1]

My NSLU2 is an Intel Xscale IXP420 device -
I have a complete, self-hosting, install of Debian on it -
I know, I set it up to build the entire install from source (it took 3 or 4 days IIRC).
So it is possible.

Didn't you once tell me you had an NSLU-2 also?
Use it to native compile your code for Xscale under NSLU2/Debian.

Xscale is really, really old - I can only guess beyond what I have already posted.

Note: The XScale architecture is based on the ARMv5TE ISA without the floating point instructions.
Ref: https://en.wikipedia.org/wiki/XScale

[knc1]

Google for a Debian/Arm/qemu-static chroot - -
The is fairly well documented, you have a choice of directions.
The one I found easiest to follow is:
https://wiki.debian.org/ArmHardFloatChroot
Modifying names and things to use the ARMel and the NSLU2 xScale tar-ball in your case.

I have several of those installed and they each worked the first time tried.
Notes:
For the i.MX6 touchscreen devices (they all are) - Debian Jessie is a good match to the system libraries. I haven't found a problem yet.

For the K1 - I think you will be stuck with Debian 3 to get a decent match with the installed system libraries.

Then, since the NSLU2/Debian tar-ball is still posted, run that in your qemu chroot (emulation on a current desktop will be a lot faster than the NSLU2 is ).
https://www.cyrius.com/debian/nslu2/

Note that the Debian 3 tar-bar is still posted there (or linked to from there).

Trivia: The Peter Korsgaard mentioned there is now the lead maintainer of BuildRoot.

[geekmaster]

The original Linksys software is running in big endian mode, including the RedBoot bootloader. Debian only supports little endian mode on ARM. Therefore the kernel has to switch the processor into little endian mode at startup (in arch/arm/boot/compressed/little-endian.S). The kernel image furthermore needs to be byteswapped before upload as it is loaded into memory by RedBoot running in big endian mode, but needs to be read by the Linux kernel running in little endian mode.

Gee, that sounds like fun...

When the script finishes you should have an armv5b-softfloat-linux-gcc in /opt/crosstool/armv5b-softfloat-linux/gcc-3.3.4-glibc-2.2.5/bin/. Alternatively you can download a precompiled version of it: crosstool-armv5b-softfloat-gcc-3.3.4-glibc-2.2.5.tar.gz (40M)

Hmm... I have not tried THAT toolchain yet...

The kernel for running Debian on the NSLU2 is based on a standard 2.6.11.12 kernel.org kernel with some additional patches. The kernel patch is based on the work done by the OpenSlug team with a few patches to run in little endian mode.

The K1 is running kernel "2.6.10-lab126", so no kernel modules without some vermagic futzing...

[knc1]

I don't recall any of what you quoted - mine "just worked".

[geekmaster]

Originally Posted by knc1

I don't recall any of what you quoted - mine "just worked".

Those quotes were from a link on the page you linked. Sadly, that armv5b toolchain also built code that does not work on my k1 (not found and/or segfault issues).

I noticed that tcc configure supports options for armv4 (and also cross compiling). Time to play with that for a bit, though I will still need a real gcc...

I am not sure why we seem to need a unique toolchain for each device we intend to support. There MUST be some compile flags to set to generate armv4 code on a modern device -- I feel like such a noob slogging in this toolchain muckery (too much time in the mainframe COBOL and MS windows development worlds).

[geekmaster]

I am thinking strange thoughts -- would it make ANY sense to run qemu on my K1 so it can support apps compiled for newer arm processors? Nah...