Geekmaster's adventures in K1 spelunking

[geekmaster]

I wrote a KUAL extension that launches a RUNME.sh on userstore, and pipes all output to documents/RUNME.txt (so you can view the output on the kindle as a book). That is how I tested my K1 stuff for PW3 compatibility. I suppose I should publish it, and my "Geemaster Video Player" extension that plays videos as well, eh? Hard to believe I burned about three weeks hunting for a K1 toolchain, but stubborn persistence paid off in the end (though at great expense) once again...

[knc1]

Originally Posted by geekmaster

- - - -
Kindle 1: Marvell Xscale PXA255 400 MHz, ARM9

Not Intel xScale then, that part was after Intel sold xScale to Marvell.

Do we have to do much speculation on why Lab126 dropped this processor (mess)?

[geekmaster]

Originally Posted by knc1

Not Intel xScale then, that part was after Intel sold xScale to Marvell.

Do we have to do much speculation on why Lab126 dropped this processor (mess)?

Not just the xscale "standard design MINUS some stuff" mess, but the "uclibc requiring everything to be recompiled for minor uclibc variations" mess as well.

I think lab126 just inherited this mess along with the gumstix-based Apollo eink dev kits they tweaked into a K1. They learned from it, and the K2 (baby DX) and later were freescale and glibc based from then on...

However, I still plan to support the K1 now that I have a working toolchain. I already have working "eink algorithmic art" scripts tweaked for 2-bit eink, working on my K1. Time for some fast binary apps. The K1 really is a fascinating device, IMHO.

[knc1]

I suppose you have at least glanced at Rob's scripts.
That and software that 'just works' even in strange situations tells the story of how many years he has put into doing this exact sort of stuff as a day job.

- - - -

We still don't know WHY - but we are just 'users' of this stuff, we only need to know that it works.

[NiLuJe]

Cooking an arm9e build, just for kicks...

[NiLuJe]

Here goes! \o/

[geekmaster]

Originally Posted by NiLuJe

Here goes! \o/

Another "Illegal instruction" error.

[geekmaster]

I just built a static "demo" app using code included in my tcc package for kindles (from the thread). It build with no errors, but running it in the chroot gave a SEGV error, and a segfault on the kindle. Probably no surprise -- I still need to change /dev/fb0 to /dev/fb0 (and perhaps more). The demo app draws to the framebuffer...

[geekmaster]

Woohoo! The demo.c included with the tcc kindle package WORKS (after changing "/dev/fb0" to "/dev/fb/0" on one line)! Awesome! It is doing (relatively) fast eink animation on my K1, as I type this message. Because that code (my first C eink animation) made the assumption that each byte was just a fat pixel (and a skinny pixel on a K4 and newer), it "just works" even on the 2-bit K1 framebuffer.

Apparently, ignoring error codes when opening framebuffers (as I do in my demos to simplify the code) leads to segfaults when you write to a bad file descriptor, eh?

The animation is running faster than on a DXG, so perhaps my video player might work okay on the K1 too. I will know soon.

EDIT: I used to launch my eink demos from an SSH terminal, so I could ctrl-C them when I viewed enough. Launched from an install script (or KUAL) takes to long for a quick test (or preview). I suppose I should change my launcher script to launch it in the background, wait for a keypress (or screen touch), then do a killall on the launched script. Makes more sense after waiting too long too many times... ...and I am STILL waiting for "demo" to complete. How long does it run?

[geekmaster]

... and running ... and running ... and running ...



Time for a paperclip reset!

EDIT: Actually, I just let it run to completion while I worked on getting gmplay development set up for the K1...

[geekmaster]

Okay, I used the armv4l busybox xz function to decode bunny.gmv.xz (which is under 16MB instead of 60MB like bunny.gmv.gz). I successfuly ran this on a K5 using the xz build into its native busybox. Anyway, THIS xz reported the file as corrupted, then gmplay reported zero frames. But it is a start. A bzip2 version is about 30MB (if I cannot get xz to work) and the K1 has native bzip2 support.

I changed gmplay to open "/dev/fb/0" if "/dev/fb0" (the more common case) returns -1 in its file descriptor. I am not doing 2-bit dither yet, so it the lines will be double-width and wrap around (the K1 has plenty of extra framebuffer RAM allocated, so no segfault should occur). Just a test, but need some sleep first. Getting close. Then I will get the version with sound support working too. Big buck bunny with sound, on the K1. Cool, at least to me...

[knc1]

You can get a quicker start-up of your application if you do like I did with the CPU Report.

In your menu.json, instead of:
"action": "your script or application name"

use:
"action": "exec"
"params": "your script or application name"

I.E: Re-use KUAL's process space, by-passing a lot of over-head of ending KUAL and starting your new process.

[NiLuJe]

(Just a quick reminder that the K1 doesn't support Kindlets ).

@knc1: That shouldn't change anything, KUAL always wraps everything in a shell script (to handle backgrounding & I/O redirection), and that's spawned by Java's own execve() soup.

(cf. https://bitbucket.org/ixtab/kindlela...ndlet.java-810 & https://bitbucket.org/ixtab/kindlela...ndlet.java-867)

EDIT: Use

"exitmenu": false

if you don't want to, well, exit KUAL on button press .

[knc1]

Originally Posted by NiLuJe

(Just a quick reminder that the K1 doesn't support Kindlets ).

@knc1: That shouldn't change anything, KUAL always wraps everything in a shell script (to handle backgrounding & I/O redirection), and that's spawned by Java's own execve() soup.

(cf. https://bitbucket.org/ixtab/kindlela...ndlet.java-810 & https://bitbucket.org/ixtab/kindlela...ndlet.java-867)

EDIT: Use

"exitmenu": false

if you don't want to, well, exit KUAL on button press .

Well, it does.
Try the CPU Report button the way the action/params is written and after editing it back to the 'normal' style.

If you really want to be impressed by the difference -
Use the 'Powersave' button first (which locks your device to lowest speed clock).

Note:
On some of my device/firmware combinations -
you must be on external power to even start KUAL while locked to minimum speed.
others have reported that with some combinations (which I don't have), the Kindle will 'lockup and re-boot' while locked to minimum speed.

[geekmaster]

The exec function is like a JUMP rather than a shell CALL, from scripts -- no new process space. However, the framework parent for KUAL is still eating lots of memory unless you shut it down when running native code. Though this is more important while running a build environment on the target device (why optware locked up on K5s, for example).