Feeds:
Posts
Comments

Posts Tagged ‘ELIoT’

Screen on Kindle

Since I’m doing some performance/battery duration tests on my rooted Kindle 4NT, I decided I needed the always useful screen application, so that I could execute tests while connected over SSH, then detach the console and let it run for a while, only to re-attach back later to the same console and see what happened, monitor some logs and so on, all the while without interrupting anything. There are other ways to execute stuff in background, but this remains the most practical of all.

Now, I found out that the ncurses library is already installed on the OS, even if it doesn’t seem to be in the sources archive distributed by Amazon; the version 5.4 is sitting right there in /usr/lib; since it is the only external requirement for screen, I copied the library back to my system and directly into the sysroot created by crosstool, so that the linker could find it easily. Then I downloaded the screen sources.

And there the problems started to arise.

First, the fact that you can specify the target/host/build systems in ./configure is not clear at all, or even documented in the help of the script, so you need to improvise and find out by yourself. The configuration does not work by specifying CC/CFLAGS/LDFLAGS, or at least I could not make it work, the only correct way is to use the –host option.

The second problem was, of course, the neverending source of surprises that is the triptych of commands produced by the autoconf stuff: it sucks beyond belief, and in particular in this case it does not work at all for cross-compilation: there are some tests that cannot be executed, the script tells you that, and then simply stops. So you need to apply a well known patch (for example, I have used this one), which allows the script to output the makefiles regardless of those tests. Then, of course, is not over: the failed tests do not produce the correct options in config.h, so my advice is to execute (separately) a configuration for your own computer, then use the config.h generated for the computer for the Kindle sources too: it will compile fine, and the final binary works without problems on the Kindle.

Advertisements

Read Full Post »

In this previous post I’ve already described how to develop the toolchain for the Kindle, from that it was easy to recompile ELIoT: I was able to maintain the computer version of the VM without modifications (in Android some patches were necessary to accomodate it to the OS), and the standard ping utility worked again; no screenshots, since the execution was performed from SSH, and I will avoid to add the console output (it is basically the same of the previous post, with a couple of debugging lines that my VM has).

Now I’m thinking about outputting something on the screen: on Android the SL4A framework gives Erlang (and thus ELIoT) the ability of writing standard layouts and stuff on screen; on the Kindle you can choose between using their J2ME VM and their Java applet framework (called Kindlet), or the GTK+ on DirectFB from C; I have not explored any of those alternatives, so I have nothing more to say here (yet).

We’ll see…

Read Full Post »

In the last couple of weeks, I decided it was time to port my Erlang framework, ELIoT, that I develop as part of my Ph.D. thesis, to several other devices than the ones on which I already ported it (the Raspberry Pi and the Carambola). So last week I ported it to Android, and while I still have to refine it so that it can be executed on non-rooted devices (i.e., you don’t need to be root to do it), I decided to give the Kindle a try. This first post describes my findings in exploring the device itself, in a later post I will talk about ELIoT itself.

I have a Kindle 4th generation non-touch, and this “non-touch” adjective is quite important, since it changes the operating system version (and probably the toolchains/hacks). The first step is to jailbreak it (beware of the consequences! this may at best break your warranty, at worse brick the device!), using the main guides it is quite easy and (seems) with little risks, from the point of view of losing all your settings and books; at the end of the procedure, you can access it through WiFi and SSH.

Given the fact that my main objective was to cross-compile stuff, I started trying to figure out how to obtain the toolchain, and the answer is, as usual, crosstool-ng. Given the fact that the Kindle runs Linux, the non-proprietary part of the OS (i.e., everything except their ebook applications) is open source and they allow us to download the source code; in this way, we know that the 4th gen runs the 2.6.31 kernel and 2.12 libc, so I started to specify those in the ct-ng configuration; for binutils I decided for the latest stable release available, and in my first try I compiled gcc 4.7 Linaro edition.

Some guides on the Web seemed to say that the floating point type was softfp, but since there was so little clue about the toolchains for this particular Kindle, I decided to give the hardfp a try. It didn’t work out, as expected, but it led to an interesting side note: if you want to know what kind of fp a distribution is, you can execute

readelf -A

on an existing binary (I tried on the wpa_supplicant binary): if it contains the line

Tag_ABI_VFP_args: VFP registers

then it means it is hardfp; otherwise it is softfp (I checked against a binary for the Raspberry Pi, which I know is the former).

So, I recompiled the toolchain with softfp and tried the usual hello world: it worked! But the joy was limited: on a more complex application some assembly errors emerged, and at this point I thought the reasons could be

  1. I was using the 2.6.31.14 vanilla as kernel, but I didn’t know the subsubsubversion of the Kindle kernel and it may have been different
  2. maybe 4.7 was a too much advanced version of gcc to use.

So I changed the ct-ng configuration again and used the existing kernel sources downloaded from Amazon for my specific Kindle version, and changed the gcc version to 4.5.4, since /proc/version says:

Linux version 2.6.31-rt11-lab126 (jenkins-official@lucid-build02) (gcc version 4.5.3 20110406 (prerelease) (Linaro GCC 4.5-2011.04-0) ) #5 Sat Jan 12 20:39:09 PST 2013

this worked and I was able to compile and execute Erlang on the Kindle! Unfortunately, no screenshots here: access was from SSH, so all I can show you is:

[root@kindle erlangarm]# ./bin/erl -name erlang@192.168.1.3 -setcookie abc
Eshell V5.9.3.1 (abort with ^G)
(erlang@192.168.1.3)1> net_adm:ping(‘erlang@192.168.1.178’).
pong

copied directly from the terminal.

The final version of the ct-ng configuration is here, if anyone wants it; you have to adjust paths for the output directory and the kernel sources path (that you have to download from Amazon).

Read Full Post »

Nexus 7

Nexus 7

VM

VM

As you know, for my Ph.D. I’m developing a specialized version of Erlang for IoT scenarios, called ELIoT (ErLang for the Internet of Things); we had it running on some known (or less known) devices, such as the Raspberry Pi or the Carambola, and in the last few days I decided it was time for Android to enter the scene.

So I ported the framework forward a couple of minor versions (from Erlang 15B to 15B03.1), and used the existing patches to cross-compile it on Android. The screenshots show it running on my Nexus 7, pinging a Linux VM running on my computer. Unfortunately, for now it has to be run as root, so the next step is to try this SL4A stuff (which was in the original patch set, but as of now it simply crashes, so being root was the easiest way to try everything).

P.S.: don’t worry about the debugging prints on the VM side, they were there simply to check that no strange bytes were passing as messages on the network.

Read Full Post »