Contents

Chapter 1
Introduction

BCI, or Brain Computer Interface is a research field which try to verify and hopefully realize an interface to a computer controlled just by the user mind. This is technically feasible, and it has already been done, but mainly with professional EEG. Now the tecnology is giving us low cost devices whose quality is sufficient to use this tecnique with an affordable investment.

The possible application are both for users which need to use hands for other purposes, or to integrate the standar interface to the PC, or persons unable to use their hands, or even other parts of their body. In this case the device could notably increase the quality of life of the person.

The technology is mainly based on EEG, and the idea is practically feasible in the recent years with the availability of portable low cost devices. The possible hardware is:

• http://www.neurosky.com/ a chip used by various producer, such as PlxWave or some “mind games” available from Amazon;
• http://www.plxwave.com/ a low cost device, which offer interface APIs for IOS and Android;
• http://www.emotiv.com/ A low cost - not as low as PlxWave, but with more sensors.

Let’s see the “Big Picture” (from the technical point of view):

• an acquisition device, an headset such as Emotiv Epoc
• EEG data acquisition
• data is sent via Bluetooth (preferred) or USB
• data elaboration
• data extrapolation of some meaningful signals to be interpreted by the computer/mobile as inputs, such as mouse simulation

And the “Big Picture” (from the user point of view):

• syndromes such as Locked in syndrome (one the most critical situations) http://en.wikipedia.org/wiki/Locked-in_syndrome let the patient conscious but unable to move almost any muscle. This can be an opportunity to give a new life to such a patient.
• a user with the ability to control 1 signal, can communicate with the external world ... the more the device can understand from patient’s EEG, the quicker will the communication run.

Chapter 2
Ongoing research

“The Berlin brain–computer interface: non-medical uses of BCI technology”, by Benjamin Blankertz, MichaelTangermann, CarmenVidaurre, Siamac Fazli, Claudia Sannelli, Stefan Haufe, Cecilia Maeder, Lenny Ramsey, Irene Sturm, Gabriel Curio and Klaus-Robert Müller (available on http://www.frontiersin.org/neuroprosthetics/10.3389/fnins.2010.00198/full is an overview with many references about the various uses of BCI: the overview includes:

• the importance of dry electrodes to make EEG easily usable, with references to studies about their measure quality
• theproblem of training and the possibilities to avoid it, for example with large pattern databases
• the use of BCI to understand the mental state, for example the attention level, the incoming sleep
• BCI in entertainment, with examples of use in “fast reaction” games, such as pinball machines

The article “NeuroPhone: Brain-Mobile Phone Interface using a Wireless EEG Headset”, by Andrew T. Campbell, Tanzeem Choudhury, Shaohan Hu, Hong Lu, Matthew K. Mukerjee, Mashfiqui Rabbi, and Rajeev D. S. Raizada (http://sensorlab.cs.dartmouth.edu/pubs/neurophone.pdf)is an overview of an implementation of P300 on iPhone using the Emotiv Epoc as headset: the implementation uses a Windows PC as data bridge from the headset to the iPhone.

A description of the OpenVibe framework in present in “OpenViBE: An Open-Source Software Platform to Design, Test and Use Brain-Computer Interfaces in Real and Virtual Environments” availabe at http://www.hal.inserm.fr/docs/00/47/71/53/PDF/Renard_et_al_2010_draft.pdf

The thesis “Adaptive Computer Interfaces” by D. Ward is a 2001 work (http://www.inference.phy.cam.ac.uk/djw30/papers/thesis.pdf), submitted in candidature for the degree of Doctor of Philosophy, at the University of Cambridge, and exploring predictive tecniques to mare data input faster, in particular, it is exposed the research about the Dasher input system (http://www.inference.phy.cam.ac.uk/dasher/).

A tactile P300 brain-computer interface http://www.frontiersin.org/neuroprosthetics/10.3389/fnins.2010.00019/full show the possibility to record P300 potentials evoked by tactile stimulation.

A simple format for exchange of digitized polygraphic recordings: the paper proposing EDF format.

A “Turing Test” and BCI for locked-in children and adults a proposed test to use evoked potential with childen and locked in persons. A stimulation based on YES/NO (as a variant of different sounds’ types)

Open vocabulary language modeling for binary response typing interfaces by Brian Roark: predictive text input.

Chapter 3
Emotiv Epoc

The Emotiv is the first device we will exploit: is has an affordable price (from 300$ - just the device - to 750$ for a Research Development Kit) and makes 14 data channels available. Here an interesting demo on the device: http://www.ted.com/talks/lang/eng/tan_le_a_headset_that_reads_your_brainwaves.html

There are other devices, such as the PlxWave: the idea is to design the software in such a way as it will be easy to change acquiring device, both to be able to use future headset, when they will be available, and to compare the various devices, or even to just give a more economically affordable solution, if available, and if the reached control capacity will be sufficient.

3.1 Technical infos

The Emotiv Epoc (with the Research SDK) gives the following features (from http://emotiv.com):

• 14 channel (plus CMS/DRL references, P3/P4 locations) high resolution, neuro-signal acquisition and processing wireless neuroheadset. Channel names based on the International 10-20 locations are: AF3, F7, F3, FC5, T7, P7, O1, O2, P8, T8, FC6, F4, F8, AF4 (see http://www.bem.fi/book/13/13.htm)

This is what the hardware gives, but, depending on the official SDK used, not everything can be available. The research SDK gives:

• real-time display of the Emotiv headset data stream, including EEG, contact quality, FFT, gyro (if fitted, custom option), wireless packet acquisition/loss display, marker events, headset battery level
• record and replay files in binary EEGLAB format1. Command line file converter included to produce .csv format.

The Emotiv communicates with PC via a ultra low power Bluetooth interface (to use less battery): there can be some communication problems if the headset and the receiver are not in the optimal position (the nearest, the best :-) http://www.emotiv.com/forum/messages/forum4/topic484/message2659/?phrase_id=158643#message2659

3.1.1 From Emotiv forum

3.2 Software interface

Emotiv Epoc sends to the host a stream of encrypted data: the interface is not open, but some reverse engineering work has been accomplished to use it: information can be found at Emokit project.

By the way, in the same discussion there’s a reference to the following paper: http://sensorlab.cs.dartmouth.edu/pubs/neurophone.pdf, saying: “The headset transmits encrypted data wirelessly to a Windows-based machine; the wireless chip is proprietary and operates in the same frequency range as 802.11 (2.4Ghz)”. This means that the receiver is not a standard Bluetooth device (i.e. we cannot use directly a smartphone do receive data) but we need the provided Emotiv dongle.

The headset samples all channels at 128Hz, each sample being a 14 bit value corresponding to the voltage of a single electrode.

3.3 Emokit

A project started by Cody Brocious, http://daeken.com/emokit-hacking-the-emotiv-epoc-brain-computer-0, available at http://github.com/qdot/emokit. This project is now included in http://www.openyou.org/libs/.

Emokit has C and Python interfaces which allow to access raw EEG data from the Emotiv EPOC on Windows, Linux, and OS X.

Emotiv comunicates using a USB dongle: it’s a USB device with VID=21A1, PID=0001 (note: from walking through the device enum code in the EDK, it seems that PID=0002 might be the development headset, but that’s totally unverified). It presents two HID interfaces, “EPOC BCI” and “Brain Waves”. Reading data off the “Brain Waves” interface gives you reports of 32 bytes at a time; “EPOC BCI” is not clear what is.

The data is crypted, with 128-bit AES in ECB mode, block size of 16 bytes: the found key was: 31003554381037423100354838003750.

The first byte of each report is a counter that goes from 0-127 then to 233, then cycles back to 0. The X coord from the gyro is byte 29 and the Y coord is byte 30. The EPOC has some sort of logic in it to reset the gyro baseline levels, the baseline generally (not perfect) is roughly 102 for X and 204 for Y.

If you assume that each sensor is represented by 2 bytes of data, that gives us 28 bytes for sensor data. 32 - 28 == 4, so what’s the extra byte? Looking at byte 15, it’s pretty clear that it’s (almost) always zero – the only time it’s non-zero is the very first report from the device.

According to some data on the research SDK, there’re 2 bits per sensor that give you the signal quality (0=none, 1=very poor, 2=poor, 3=decent, 4=good, 5=very good).

Packet structure is:

3.4 OpenVibe

From EEG raw data to meaningful information we need some elaboration: OpenVibe http://openvibe.inria.fr/ is a general Brain Computer Interface. It’s not the only one; the paper which describes it http://www.hal.inserm.fr/docs/00/47/71/53/PDF/Renard_et_al_2010_draft.pdf reports some link about other interfaces too.

3.5 Applications

http://www.nanotechgalaxy.com/braintalk/ An application to simulate a keyboard.

3.6 Roadmap

Preliminary work:

• acquire EE (Emotiv Epoc) data on PC via Emokit: should be as easy as running the demo ... but sometimes there are troubles with the decryption key!
• acquire EE (Emotiv Epoc) data on Android via Emokit: this needs a porting to Android platform, in particular, verify the Android API for Bluetooth Input.
• test EE and OpenVibe on Windows/Linux with official SDK: this should be a plain task. Emotiv is officially supported on Windows, while on Linux there’s a beta SDK (probably it can be asked by a SKD license holder)
• write an acquisition server/driver for OpenVibe on Linux using Emokit: the server building is documented. Interfacing Emokit to the server should be a work of “data structure adaptation”
• write an acquisition server/driver for OpenVibe on Android using Emokit: the porting of the previous work on Android.
• run OpenVibe on Android (?): OpenViBE is an analizying tool. Is it better to port OpenViBE on Android or take from OpenViBE the relavant algorithms and implement on Android? (Probably this last option is better!)
• identify 2/3 signals which a user can control (x/y axis, click): this can be done on OpenViBE on Linux/Windows. When we have meaningful data, we can try to duplicate them on Android
• interface those signal to I/O methods: to simulate mouse/joystick moving.
• USE I/O FOR MIND CONTROLLED INPUT!: and now ... the work can start! use the previous software to realize something!

Application work:

• I/O test: an application that moves a ball around (to test ... and to show as demo!)
• Porting of Dasher: http://www.inference.phy.cam.ac.uk/dasher/DasherSummary.html an efficient alternative input method, to Android
• Interface Dasher to mind controlled I/O

Specific for Android:

• Raw data acquisition
  • Bluetooth I/O API
  • USB I/O API (should not be needed - Emotiv send data via Bluetooth with a USB dongle: it should be possible to read directly the Bluetooth stream)
  • porting of Emokit to decode data
  • implement some API to access raw data
  • implement a data server (could be the OpenViBE acquisition server). This is an alternative to the previous point: to verify which is the best solution
  • while doing this, do think about having the same tools (API or server or both) to acquire data from different devices (Emotiv Epoc, PlxWave, Dummy1)
  • implement a “store raw data” and a “read stored data” to be used thru’ a DummyDevice (for test of upper layer)
• Raw data elaboration. OpenViBE is a EEG data elaboration tools, but quite a big framework to implement on Android. The idea could be to test the data elaboration on PC and to implement in Android only the relevant parts. OpenViBE core is a data analysis tool, based on IT++: it could be interesting implement IT++ (or part of it) on Android. IT++ has other dependencies such as FFTW, BLAS, LAPACK.

  The package to port to Android are the following: these steps are to verify (i.e. verify if they are really necessary)

  • FFTW
  • BLAS
  • LAPACK
• Output of relevant parameter: the final result should be some (2/3/4/5) parameters. The ideal would be to have
  • 2 analogic signal for x/y axis
  • 1 click signal to select
• interface this parameter to Android I/O structure to simulate a joystick

Chapter 4
Hands on tests!

4.1 Hardware connection

The initial test on the Emotiv Epoc are quite interesting:

• the comunication channel is NOT Bluetooth: it uses a http://www.nordicsemi.com/ chip - a ultra low power device implementing a wireless communication on 2.4GHz. From the practical point of view, the Emotiv Epoc cannot be accessed directly by a smartphone via Bluetooth
• the comunication Epoc/smartphone could be done:
  • using a dedicated device from Emotiv: they seem interested in selling such a device, but at the moment nothing is available.
  • using a wireless hub: http://http://www.iogear.com/product/GUWH104KIT/. This could be used in the configuration headset - dedicated usb dongle - wireless hub - smarthphone. The problem is the driver, not available in smartphone.
  • using a PC as bridge (in the PC there would be the EPOC driver)
  • using an embedded solution: a small factor/mini/micro PC with a USB host, a Bluetooth dongle and a stripped down Linux. There’s the Epoc driver problem.

4.2 Primary data reading

Data sent by the Epoc is crypted, but it is present a software to read it: http://github.com/qdot/emokit

It is available a Python software to read the primary data, using 3 possible decrypting keys: the correct one for the available consumer key under test is another one, extra1_key

found at http://github.com/qdot/emokit/issues/4.

The procedure used to get that key was the following (as reported in the forum):

The used program is almost the standard Emokit: just added the new decryption key on emotiv.py, while the test program has been rewritten as rawread.py:

To use it on MacOSX:, first of all the Linux lsusb command is the following:

then the python program expects to find a /dev/hidraw? device: it is a HID raw driver (http://http://lxr.free-electrons.com/source/drivers/hid/hidraw.c) which:

4.3 An open server

Emotiv Epoc data could be used from various software, such as OpenVIBE: it could be interesting to prepare a daemon sending data on a socket.

At the moment, for testing purposes, we can use the python program, sending the data in plain ASCII (values separated by ’,’, line terminated by ’;’) to standard output, combined with the nc tool (netcat) to pipe the data to a socket.

This app can be used to read data from a socket: http://giammy.com/eegview

4.4 OpenVIBE test

First considerations:

• OpenVIBE must be compiled from sources for Linux
• Epoc driver is available only for Windows, needs the Emotiv SDK and must be compiled
• OpenVIBE can read data from a socket :-)

Compilation of OpenVIBE on Ubuntu 11.04:

• linux-install_dependencies
• linux-init_env_command
• linux-build

4.5 Test: Evoked potential

The test (Audio evoked potential) has been accomplished on 2011.10.14, with the Emotiv Epoc headset. The setup includes:

• patient with Emotiv Epoc
• acquisition on a Linux box via a Python program (variation of the one included in the EmoKIT)

The acquisition runs continuously while the software emits 2 100ms beeps (200Hz and 4000Hz frequency), every 1-3 seconds (the variation of the interval length is random).

Whenever a sound must be emitted, the low frequency one is chosen with probability 0.2.

The subject was sitting on his chair, closed eyes, mentally counting the low frequency beeps.

The program is the following:

4.6 Emotiv to OpenVibe and EEGLab

Here we present some ideas and tools to connect the Emotiv EPOC to some elaboration frameworks: the headset comes in a consumer/developer/research edition, but we are interested in Open Source elaboration tools, so we suppose to have just the raw data in a ASCII file.

4.6.1 Getting the Emotiv EPOC raw data

This is the initial step which must be accomplished to start the work. There are 2 possibilities:

• use the Emotiv EPOC Research Edition and the given framework
• use the Emokit tools to acquire the data

When raw data is available, we can store it in an ASCII file, one acquisition for line, each line being the sequence of acquired samples. We do not use a more definite format, as these notes are not an out-of-the-box solution: we just give the basic ideas to test the various solutions.

4.6.2 From raw data to OpenVibe

OpenVibe is a very flexible tool to analyze EEG data, in particular it supports various input mode. The one we are exploiting is the Generic Raw Telnet Reader with the following configuration:

• Generic Raw Telnet Reader
• Number of channels: 16
• Sampling Frequency: 128
• port 1337
• Limit speed - checked
• Little endian
• 16 bits unsigned integer
• Header size: 0
• Inter frame size: 0

We need to start the acquisition server (one of the modules of OpenVibe: dist/ov-acquisition-server.sh), select the Generic Raw Telnet Reader and set the given options.

After this we run a scenario in OpenVibe Designer dist/ov-designer.sh: the scenario used for this test includes just the acquisition box and a graphical widget to see the data in realtime.

Having OpenVibe up and running, the Emotiv EPOC ASCII raw data is piped to the a2b tool which just takes the input stream as ASCII numbers and transform it in a binary output stream (16 bit unsigned integers, little endian - as defined in the acquisition server) The source is the following:

The tool sends data to the standard output: the network management is done using the standard Linux tool nc (see a Linux manual for the details: the command is named nc or netcat) which take the binary stream and sends it to the socket 1337 (the one defined in the acquisition server).

At this point we use the Linux flexibility: as we use pipes to manage data, the incoming stream can come from a file or from a running program doing a realtime acquisition and sending data in realtime to standard output. In this configuration we get a tool to acquire and visualize EEG data in realtime. The next step is to prepare an elaboration scenario.

Working with the research edition you need to write a server in a Windows machine, from there the connection to OpenVibe is the same (or use the included OpenVibe driver for Emotiv Epoc).

4.6.3 From raw data to EEGLab

EEGLab is an Open source suite which runs in Matlab, for non realtime EEG data elaboration: we proced to save on file an acquisition session, then we convert it for EEGLab using EDF format.

In this case we are interested in recording some events (the instant of the PC beep and it’s frequency, as we will need to identify evoked potentials.

Data is converted in EDF format with the following tool, which is just a test program, not a program to use in the field as the header is manually written in the code!

The program takes as input a raw ASCII EEG and produces an EDF file: ./a2edf <in >out.edf. In the output file a new signal is added, to code the beep event, which is automatically recognized by EEGLab.

4.6.4 Conclusion: OpenVibe and EEGLab

The two proposed tools give us the possibility to have EEG data available in OpenVibe or EEGLab. At the moment the scenario is:

1. getting the raw data from Emotiv EPOC via Research Edition SDK or Emokit
2. store the data on file for post-elaboration
3. build a server and stream the data via socket in realtime
4. or both ... obviously!
5. for post-elaboration: convert the data file to EDF format and import it in EEGLab (with informations about events - needed for evoked potential rilevation)
6. in realtime: use OpenVibe to get data via Raw Telnet

The idea of having 2 different elaboration tools is that we will use the one which will suit best to our needs. Other frameworks interfaces could be tested in the future.

4.7 A first manual P300 elaboration

Referring to the Audio Evoked Potential test described in section 4.5, Test: Evoked potential, we present a preliminary manual data analysis.

The test emitted high frequency sounds, with 33 low frequency sounds (random rare events).

The plotted signals are the resulting media of all the acquisitions corresponding to the 2s interval around the rare events.

We report just the signal corresponding to F3, F4, AF3 (the position of the sensors must be verified): in these signals the peak is more evident.

The rare event occurs at sample 128, while the peak occurs about 30 samples after (a quarter of second).

This seems to suggest that the Emotiv Epoc can record an evoked potential, but is preliminary data and preliminary report: more test - and in realtime configuration, must be done!

Chapter 5
Resources

• P300 speller Matlab code: http://asi.insa-rouen.fr/enseignants/ arakotom/code/bciindex.html
• A tool to read data from a socket on Android: http://giammy.com/eegview
• Initial tests for Bluetooth interface on Android: http://github.com/giammy/bscan
• Discussion Mailinglist: http://groups.google.com/group/medical-bci (email address: medical-bci@googlegroups.com)
• Brain scanner on N900: http://milab.imm.dtu.dk/eeg
• Lego Mindstorm and Emotiv Epoc: http://www.youtube.com/watch?v=HLbly5rWPK0
• Mind control of a sculpture: http://brainstorms.puzzlebox.info/

  5.0.1 Not strictly BCI

  http://www.ofoa.net/applications/eagleeyes_apply.cfm

Chapter 6
Equipment

http://www.gtec.at/

http://www.micromed.eu/

Chapter 7
Tablets, Android, Kernel

7.1 ASUS TF101

7.2 VIA8560

Here we have some preparatory tests to connect the Emotiv to an Android tablet. The tablet is the MID 7 - Via8650.

The device is:

To recompile a kernel, you need the ARM toolchain and the kernel sources.

7.3 ARM toolchain

We will need a compiler for the arm platform. The android source comes with the arm compiler. You can download it following this instructions http://source.android.com/source/downloading.html . Or we download only the prebuilt toolchain:

git clone git://android.git.kernel.org/platform/prebuilt.git

Mirrors are available at https://github.com/android for example:

git clone https://android.googlesource.com/platform/prebuilt.git

After git finishes his download, you will have a new directory called ”toolchain”. We have to set some environment variables (i assume you have downloaded the toolchain in your home directory):

An example of environment variables setting for Linux is:

7.4 Kernel sources

Finding tablet’s kernel sources is usually a mess, as not all the producer have them available in their site.

As examples, the ASUS Transformer TF101 can be downloaded from the ufficial site:

while for the Via8650 we have the vendor official archive:

the file is: KERNEL-DS_ANDROID_2.6.32_WM8650.111209.1514.tgz

The configuration used for the compilation can (sometimes) be downloaded from the tablet:

The compiler is installed and configured. It’s time to modify some settings in your config file (!!AT YOUR OWN RISK!!) editing the .config file or use a graphical interface.

cd kernel make xconfig (make menuconfig if you prefer a command-line menu)

Now we can compile the android kernel with the command make: our new kernel is stored in

while the command make uImage produces:

7.4.1 Tablet ROM update

This tablet has a modded ROM available here:

http://www.slatedroid.com/topic/18025-rom-universal-hybrid-honeycombmod-uberoid-for-wm8650-devices-v130-w-video/

http://www.techknow.t0xic.nl/forum/index.php?action=forum

The package is Universal_Uberoid_WM8650_v10.1_www.TechKnowForum.net http://www.mediafire.com/?z4nd3h85q0s65ok

The update procedure is well done: just put the new image on a SD, and the tablet, when sees it, flash it! One way to proceed it to build an Uberoid standard SD update card and then put our modification in it.

For the Uberoid ROM, the correct type to select is 11 (Via8650, MID 7)

7.5 Debian on the Mid and Via8650 tablet

It seems it can be done:

http://www.slatedroid.com/topic/23028-running-debian-on-wm8650/

with the following image:

http://www.filefactory.com/file/ce12c6b/n/debian_wm8650_0.5.img.7z

You need a 4G (or more) SD card and just

dd if=theimage of=/dev/thecard

This is a kernel source for via8560:

https://gitorious.org/linux-on-via-vt8500/vt8500-kernel

The hardware support depends on the device: on the MID 7 the keyboard does not work.

Chapter 8
Acer Iconia A500 kernel recompile

Acer Iconia A500 is a tablet based on Android whose interesting feature is the standard USB port: this is valuable to connect an Emotiv EPOC device to the tablet as it uses a USB dongle: a standard HID usb device, which can be accessed via the standard linux /dev/hidraw driver.

The main problem with the tablet is that the HIDRAW support is not compiled in the kernel. Here we see how to compile and install a custom kernel on the Acer Iconia A500: the original kernel is: Linux version 2.6.36.3 (simba@lion) (gcc version 4.4.3 (GCC) ) #1 SMP PREEMPT
Wed Jun 29 14:15:34 CST 2011

8.1 A500 and ClockworkMod ROM Manager

To work with the kernel is a good (almost mandatory, I would say) idea to have a recovery tool such as the http://www.clockworkmod.com/ ROM manager, which allow you to (from the ufficial description):

The installation on the A500, with Android 3.1 installed (from the ufficial update) is not very plain as this device is not supported. Anyway, from a clean 3.1 update you need to use Acer Recovery Installer from Google market http://www.addictivetips.com/mobile/install-clockworkmod-recovery-on-acer-iconia-a500-honeycomb-tablet/ so:

• root the device
• install Acer Recovery installer from the market
• using the previous tool, you can install the ClockworkMod recovery

This is a good moment to STOP AND BACKUP ALL!

The ROM manager can be activated in Recovery mode: for the A500 you need to push volume down and then push the power on. There will be a menu with a lot of options, and the possibility to do a “Complete backup”. Do it, try to recover from that backup, store it on a USB device, copy on your PC ... do not lose it!

8.2 Kernel compilation

The first step is to download the ufficial kernel sources from the Acer site http://http://us.acer.com/ac/en/US/content/drivers. At the time of writing (May, 2012) the kernel for version 3.1 had a missing Makefile, while the kernel for 3.2 was complete. The kernel is configured via a .config file which can be pulled from our device (the number is the A500 device UID):

we will find a file congif.gz which can be expanded and moved as .config in the root of the kernel source tree. The only modification we need is to enable HIDRAW support: there should be some lines like:

the last line should be uncommented.

After this you need to recompile the kernel with the modified .config file: the quick overview of the procedure is:

• you need a Linux box with development tools installed
• install the ARM cross compiler
• expand the kernel source to KERNEL_DIR
• copy the modified .config to KERNEL_DIR
• compile with something like:
  #!/bin/bash  
  export ARCH=arm  
  export CROSS_COMPILE=arm-eabi-  
  export PATH=$PATH:/home/giammy/Desktop/toolchain/prebuilt/  
                     linux-x86/toolchain/arm-eabi-4.4.3/bin/  
  #Our new kernel is stored in : arch/arm/boot/zImage

• the kernel will be in KERNEL_DIR/arch/arm/boot/zImage

8.3 Android partitions’ structure

The partition map of Android can vary from device to device: some infos are present in http://elinux.org/Android_Fastboot, but the memory for the A500 is mapped to /dev/block/mmcblk0pn with:

mmcblk0p1

recovery partition

mmcblk0p2

kernel, the place where the Linux kernel and RAM disk reside;

mmcblk0p3

base system;

mmcblk0p4

...

mmcblk0p5

main file system;

mmcblk0p6

...

mmcblk0p7

checksums of other partitions (follow explanations...)

Here we work only in /dev/block/mmcblk0p2, where the kernel and RAM disk are stored.

WARNING: if you use the wrong partition you can brick your device. What I did, worked on my device: I do not know what will happen to your device!

The kernel is located in the mmcblk0p2 partition, packed with the RAM disk. To get the kernel you need to fetch the right partition: from the adb shell just do:

Note that you need a rooted device to access to the shell as root. Be careful that the shell application will ask you on the tablet display the authorization to become root, so, if you run the command without looking at the tablet display (unlocked) you miss the request and cannot become root.

The command is the standard GNU/Linux dd command - see a Linux manual for more info.

WARNING: if you give the wrong command you can brick your device: do this only if you undersand what you are doing!

Note that the backup procedure, essentially copy all the partition in, more or less this way.

8.4 The kernel and its partition

The kernel is stored in the partition 2, as we have seen, packed in a binary blob which we call boot.img with the RAM disk: to change the kernel we need to unpack the original kernel, compile our new kernel, repack it in a new boot.img. A description can be found here: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images.

The tools used to unpack the boot image are split_bootimg.pl: a perl script referred to in the previous quoted wiki page, whose output is something like:

and the two relevant files boot.img-kernel and boot.img-ramdisk.gz: the first is the kernel and the second ... guess what!

At this point you need to repack the image with your kernel (at the moment, we keep the same ramdisk): the tool for this operation is mkbootimg with a command line as:

be careful to the base address --base 0x10000000.

Now we need to reflash the new image to our device:

WARNING: IF YOU BRICK YOUR DEVICE DON’T BLAME ME!

The command line to reflash is:

At this point you could have bricked your device if the message you see at the following boot is:

The problem is that A500 keeps all the checksums of the partitions on the last partition, probably to stop people doing what we are doing, but this has been documented in http://forum.xda-developers.com/showthread.php?t=1121543; they say: “Checksums for all partitions are stored on mmcblk0p7. During boot, the actual checksums for boot.img and recovery.img are calculated and compared to the values stored in p7.” You need to download the itsmagic tool and run it, or run this tool from the ClockworkMod recovery. What it does is to write a blob of 16 bytes somewhere on partition 7: if this is not clear to you, don’t worry - you are not alone - you just understand the reason of its name: it’ s magic :-)

At this point, we can reboot the tablet and see other problems: it shows the android logo and then it reboots and so on and so forth ... This behaviour was fixed with Clockwork recovery resetting everything to factory default (reset cache, dalvik cache, user data ...) As conclusion, the steps are:

• get kernel source
• compile them with your modifications
• get the original boot image
• unpack, change kernel, and repack
• do a dd of the new image
• run itsmagic
• factory reset of everything

8.5 Iconia A500 and Emotiv EPOC

At this point, the result is that, connecting to the USB port, the Emotiv Epoc Dongle, tha raw data is available on /dev/hidraw1. Now we need to use it.

TODO: Note that the hidraw device is now supported but there is a problem with the new kernel: at the moment the system tasks show the output as “mirrored left to right”: we need to investigate this. Another problem is that enabling wifi, resets the tablet: we think that we got the procedure to ricompile the kenel, but we are missing some critical configuration!

Index