Skip to content

Using persistent storage to debug kernel crashes

23-Sep-14

I am debugging a Digi’s ConnectCore 6 SBC running a 3.10.54 kernel. The system is freezing in the middle of a software reboot. This method explains how to use persistent RAM storage which is kept across reboots to capture the console, oops trace and function tracer messages.

2. Configure the kernel with persistent storage, function tracing and magic sysrq (just to test the feature):

patch -p1 < debug-ccimx6sbc_defconfig.patch

diff --git a/arch/arm/configs/ccimx6sbc_defconfig b/arch/arm/configs/ccimx6sbc_defconfig
index 2914d51686c5..fc879ed27deb 100644
--- a/arch/arm/configs/ccimx6sbc_defconfig
+++ b/arch/arm/configs/ccimx6sbc_defconfig
@@ -261,7 +261,10 @@ CONFIG_MSDOS_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
 CONFIG_TMPFS_POSIX_ACL=y
-# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_PSTORE=y
+CONFIG_PSTORE_CONSOLE=y
+CONFIG_PSTORE_FTRACE=y
+CONFIG_PSTORE_RAM=y
 CONFIG_NFS_FS=y
 CONFIG_NFS_V3_ACL=y
 CONFIG_NFS_V4=y
@@ -273,9 +276,12 @@ CONFIG_NLS_ASCII=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_NLS_ISO8859_15=y
 CONFIG_NLS_UTF8=y
+CONFIG_MAGIC_SYSRQ=y
 # CONFIG_SCHED_DEBUG is not set
 # CONFIG_DEBUG_BUGVERBOSE is not set
-# CONFIG_FTRACE is not set
+CONFIG_FUNCTION_TRACER=y
+CONFIG_FTRACE_SYSCALLS=y
+CONFIG_TRACER_SNAPSHOT=y
 # CONFIG_ARM_UNWIND is not set
 CONFIG_SECURITYFS=y
 CONFIG_CRYPTO_DEFLATE=y

2. The temporary persistent storage region needs to be configured on u-boot’s extra_bootargs:

setenv extra_bootargs ramoops.mem_address=0x30000000 ramoops.mem_size=0x200000

Do not use the final 1MB of RAM.

3. Mount the pstore filesystem at boot by adding to /etc/fstab:

pstore		/pstore		pstore		defaults	0	0

4. Enable the ftrace persistent logging.

user@computer:$
echo 1 > /sys/kernel/debug/pstore/record_ftrace

And the function tracer:

user@computer:$
echo function > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on

5. Force a reboot

user@computer:$
echo b > /proc/sysrq-trigger

6. On reboot, you will see the following files on /pstore.

-r--r--r--  1 root root 4084 Sep 16 16:24 console-ramoops
-r--r--r--  1 root root 4084 Sep 16 16:24 ftrace-ramoops

Which contain the console and ftrace log respectively.

7. Move them to a different location to make space in the persistent log.

You are now ready to obtain the traces for your real problem.

What patches have already been applied?

17-Feb-14

A utility script that traverses all patches on a specified folder and looks for matching commits on the current git branch.

Useful when you have a bunch of patches and you need to remove those that have already been applied to your tree.

A usage example is when you receive a kernel BSP refresh as a tarball of patches.

#!/bin/bash                                                                     
 
# Traverse the current git branch (or all branches) for matching commits to the
# patches provided                                                              
 
# Arguments
# $1: Path to folder with all patch files
# $2: Since commit to traverse from (since..HEAD)                               
 
set -o pipefail                                                                 
 
since=$2
FILES=$1
VERBOSE=1                                                                       
 
# With the --all args is searches on all refs, not only the current branch
ARGS=""
#ARGS="--all"                                                                   
 
function log () {
    if [[ $VERBOSE -eq 1 ]]; then
        echo "$@"
    fi
}                                                                               
 
for f in $FILES/*.patch
do
        log "Processing $f file..."
        patchid=( $(git patch-id < $f) )
        searchPatchID=`git rev-parse ${patchid[0]}`
        log "Searching for equivalents to patch $searchPatchID..."              
 
        git log -p $ARGS $since..HEAD  | git patch-id | grep $searchPatchID | while read patchID commitID;
        do
                if [ "$commitID" = "$searchCommitID" ]; then
                        echo "$f Exact commit $commitID found, removing."
                        rm $f
                else
                        echo "$f Equivalent commit $commitID found, removing"
                        rm $f
                fi
                if [ "$ARGS" = "--all" ]
                then
                        echo " on branch:"
                        git branch -a --contains $commitID
                fi
        done
done

IOMUX PAD configuration on Freescale I.MX processors

12-Feb-14

For purely software guys, the pin configuration is complex to grasp initially. Follows a description of the typical pin configuration that should help.

Slow Rate Enale (SRE): How fast the pin state changes from 0 to 1, since rapidly changing states takes more power & emits RF spikes, slowing it down if you can helps EMC. Typically low slow rates are preferred, except for quick control signals like I2C and SPI which need to change fast.

Drive Strength Enable (DSE): How much current the IO pin will source/sink, again a power-saving / EMC thing as it’s generally bad practice to hang loads directly from micro pins.

Open Drain Enable (ODE): Whether the pin pulls down to 0V for a low output or goes “open drain” (disconnected/floating), useful for some things like I2C where parts take it in turns to hold lines low or high.

Hysteresis (HYS): Applies only to input pins, it controls whether the pad behaves like a Schmitt trigger, a comparator with memory of its last input (hysteresis).The pin retains its value until the input changes sufficiently to trigger a change.

Pullups/down are controlling whether the pin has an internal resistor connected to +v or 0v to stop things floating to some random/undesired value, usually used when the pin is an input.

PullUp/PullDown select (PUS): Selects the value od the pull up/down internal resistor.
Pull Keep Select (PUE): Configures whether the pin value is a pull up/down or will keep its previous value until changed.
Pull Keep Enable (PKE): Enables or disables the pull/keep functionality.

Understanding video timings for LCD displays

03-Feb-14

About LCD displays

An LCD is a device which consists of an array of pixels that modify the characteristics of the light that comes through them and a backlight. The number of pixels is the resolution, and some common resolutions are listed here. The displays LCD controller will paint the pixels from left to right and top to bottom, so it’s important to set the native display resolution correctly. Size and resolution are independent, so you can have big resolutions in small displays and viceversa. LCDs use the RGB color space, and not YUV. Depending on the numbers of data lines it can typically be RGB565, RGB666 or RGB(A)888.

Display types

There are synchronous (or dumb) and asynchronous (or smart) displays. Dumb displays require to be updated continuously with new frame data. TFT displays are a particulat group of dumb displays.

Smart displays only need to receive frame data when the image changes, and then only the changed portion need to be send. Smart displays are more expensive and hence less used.

The following details refer to dumb synchronous displays ( and non SHARP, the interface, not the brand).

Signals

Signals used for a typical dumb display include:

HSYNC: Horizontal synch (FPLINE or LP), indicates the LCD line finished and the following pixels are part of the next line.
VSYNC: Vertical synch (FPFRAME, FLM, SPS or TV), indicates the current frame has ended and the line index should restart at zero.
DRDY: Data ready or data enable (DE). The data in the bus is valid and must be latched using the pixclk signal. While it’s active each pulse draws a pixel.
PIXCLK: Specifies the placing of RGB data on the bus.
RGB data: 24 data lines for RGB888, 16 data lines for RGB666.

Timing considerations

Horizontal Back Porch (HBP): Number of pixclk pulses between HSYNC signal and the first valid pixel data.
Horizontal Front porch (HFP): Number of pixclk between the last valid pixel data in the line and the nect hsync pulse.
Vertical back porch (VBP): Number of lines (HSYNC pulses) from a VSYNC signal to the first valid line.
Vertical Front Porch (VFP): Number of lines (HSYNC pulses) between the last valid line of the frame and the next VSYNC pulse.
VSYNC pulse width: Number of HSYNC pulses when a VSYNC signal is active.
HSYNC pulse width: Number of pixclk pulses when a HSYNC signal is active.
Active frame width: Horizontal resolution.
Active frame height: Vertical resolution.
Screen width: Number of pxlclks between the last HSYNC and the new HSYNC.

Screen width = Active frame width + HBP + HFP

Screen height: Number of lines between VSYNC pulses.

Screen Height = Active Frame Height + VBP + VFP

VSYNC polarity: Value of vsync to indicate the start of a new frame (active low or high)
HSYNC polarity: value of HSYNC to indicate the start of a new line (Active low or high).

Most data sheets will include all the values listed above. Sometimes they list Horizontal and Vertical blanking periods, which are:

Horizontal Blanking Period: HSYNC + HFP + HBP
Vertical Blanking Period: VSYNC + VFP + VBP

The split is a bit arbitrary, but a common rule of thumb is to split the blanking period in four and assing the sync two parts and the porches one part each.

For example, if the Horizontal Blanking Period has a typical value of 176, we could do:

HSYNC: 88
HFP: 44
HBP: 44

Mapping timings to kernel data structures

 
Drivers configure the fb_videomode data structure below with the datasheet LCD timings.

struct fb_videomode {
	const char *name; 	// Descriptive name
	u32 refresh; 		// Refresh rate in Hz
	u32 xres;		// resolution in x
	u32 yres;		// resolution in y
	u32 pixclock;		// Pixel clock in picoseconds
 
	u32 left_margin;	// Horizontal Back Porch
	u32 right_margin;	// Horizontal Front Porch
	u32 upper_margin;	// Vertical Back Porch
	u32 lower_margin;	// Vertical Front Porch
	u32 hsync_len;		// Hsync pulse width
	u32 vsync_len;		// Vsync pulse width
	u32 sync;		// Polarity on the Data Enable
	u32 vmode;		// Video Mode
	u32 flag;		// Usually 0
};

xres: Number of horizontal pixels, resolution in the x axis.
yres: Number of vertical lines or pixels, resoution in the y axis.
pixclock: Pixel clock, dot clock or just clock, usually in MHz. It needs to be entered in picoseconds

pixclock in ps= 10 ^(-12) / dotclock in MHz

left margin: This is the HBP.
right margin: This is the HFP.
upper margin: This is the VBP.
lower margin: This is the VFP.
hsync length: This is the hsync pulse width.
vsync length: This is the vsync pulse width.
sync: This refers to the clock polarity. It can be 0 or FT_SYNC_CLK_LAT_FALL is inverse.
vmode: This is the video mode. FB_VMODE_INTERLACED, FB_VMODE_NONINTERLACED etc.
flag: Leave at zero (FB_MODE_UNKNOWN) or FB_MODE_IS_DETAILED.

Understanding video timings for digital interfaces

29-Jan-14

Video timings are formally defined in SMPTE standards for SDI interfaces, like SMPTE 296M for 720p and SMPTE 274M for 1080p. They are grouped into modes by the CEA-861-E standard.

Although these standards are not in the public domain, the information regarding video timing is publicly available for example in the Linux kernel

A video mode is defined in the Linux kernel as an array of fb_videomode, which is defined as follows:

struct fb_videomode {
        const char *name;       /* optional */
        u32 refresh;            /* optional */
        u32 xres;
        u32 yres;
        u32 pixclock;
        u32 left_margin;
        u32 right_margin;
        u32 upper_margin;
        u32 lower_margin;
        u32 hsync_len;
        u32 vsync_len;
        u32 sync;
        u32 vmode;
        u32 flag;
};

And CEA modes are also defined in the linux kernel source, for example mode 19:

        /* #19: 1280x720p@50Hz */
        [19] = {
                NULL, 50, 1280, 720, 13468, 220, 440, 20, 5, 40, 5,
                FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
                FB_VMODE_NONINTERLACED, 0,
        },

Where,

50:         Refresh rate in Hz.
1280,720:   width x height of the active video area, that it the area which is displayed on the screen
13468:      13468 picoseconds is the pixel clock.
220:        left margin
440:        right margin
20:         lower margin
5:          upper margin
40:         hsync length
5:          vsync length

So, how do we make sense of these numbers?

The pixelclock is the time it takes the video controller to draw a single pixel,that is, it takes 13468ps.

If you do the maths, it takes 1280 x 720 x 13468 x 10^(-12) = 0.01241s to refresh the screen. But that is around 80MHz, not 50MHz, so something is wrong.

And that’s because 1280×720 is only the active video area. We need to add the vertical and horizontal blanking areas. These used to be the horizontal and vertical retrace for the electron beams on CRC screens. For SMPTE 720p, the vertical blanking is defined as a constant of 30 pixels. So we can play with the horizontal blanking:

For a value of 700:

(1280+700)x(720+30)x13468x10^(-12)=0.02s => 50Hz

For a value of 370:

(1280+370)x(720+30)x13468x10^(-12)=0.016s => 60Hz

So for 50Mhz we need a horizontal blanking area of 700 pixels.

The horizontal and vertical blanking areas are defined as follows in the linux kernel framebuffer documentation:

horizontal blanking = left margin + right margin + hsync lenght
vertical blanking = upper margin + lower margin + vsync lenght

Since the monitor doesn’t know when a new scanline starts, the graphics board will supply a synchronization pulse (horizontal sync or hsync) for each scanline. Similarly it supplies a synchronization pulse (vertical sync or
vsync) for each new frame.

For SMPTE 720p the hsync is defined as 40 pixels and the vsync is 5 pixels.

Also, in SMPTE 720p the left and upper margins are constant, 220 and 5 pixels respectively. So, to calculate the missing right and lower margins:

700 = 220 + right margin + 40
30 = 5 + lower margin + 5

So:

right margin: 700-40-220 = 440 pixels
lower margin: 30-5-5 = 20 pixels

A device tree primer

12-Aug-13

Overview

The device tree architecture in the Linux kernel originates with an effor in the PowerPC architecture to separate the hardware configuration data from the source code itself. They adopted the ePAPR [1] standard regarding kernel/bootloader APIs using a flattened device tree (FDT) data structure defined after the Open Firmware specification.

Its aim is to eliminate the hardcoding of hardware descriptions from the kernel facilitating the development of embedded systems.

It removes the MACHINE_ID, platform codes define macros, GPIO muxing code and most platform code.

This article is based on the v3.10 source.

The Flattened device tree (fdt)

It’s a binary blob (device tree blob or dtb) loaded into memory and passed to the kernel by the bootloder. The dtb is small, relocatable and allows the insertion and deletion of nodes without recompilation.

For example U-Boot does something like.

bootm <image> <dtb>

It can also be compiled as part of the kernel image.

The dtb is compiled from device tree syntax (dts) files using a device tree compiler (dtc). You can install the dtc on a debian based system by doing:

user@computer:$
sudo apt-get install device-tree-compiler

And you can compile a dtb by doing:

user@computer:$
dtc -I dts arch/<$arch>/boot/dts/<platform>.dts -O dtb -o </path/platform.dtb>

Device tree kernel APIs

Used to access device tree nodes data from kernel drivers.

include/linux/of.h
include/linux/of_*.h

Modifying a kernel driver to be device tree compatible

We add a table of compatible devices which matches it with device tree nodes defining the same compatible property.

static const struct of_device_id mxc_gpio_dt_ids[] = {
        { .compatible = "fsl,imx1-gpio", .data = &mxc_gpio_devtype[IMX1_GPIO], },
        { .compatible = "fsl,imx21-gpio", .data = &mxc_gpio_devtype[IMX21_GPIO], },
        { .compatible = "fsl,imx31-gpio", .data = &mxc_gpio_devtype[IMX31_GPIO], },
        { .compatible = "fsl,imx35-gpio", .data = &mxc_gpio_devtype[IMX35_GPIO], },
        { /* sentinel */ }
};

static struct platform_driver mxc_gpio_driver = {
        .driver         = {
                .name   = "gpio-mxc",
                .owner  = THIS_MODULE,
                .of_match_table = mxc_gpio_dt_ids,
        },
        .probe          = mxc_gpio_probe,
        .id_table       = mxc_gpio_devtype,
};

Device tree syntax

Starts froms a root node (/) with no parents. Each node thereafter has exactly one parent node. Each node has key/value pairs describing the device properties.

name@address {
	<key> = <value>;

	name@address{
	}
};

Node names are generic, case insensitive, a maximum of 31 chars long and must start with a letter. Node addresses define the device’s offset from the start address of the parent node.

Node values can reference other nodes, in what’s call a pointer handle (phandle) which refers to a label.

name@address {
	<key> = &label;
};

label: name@adress {
}

Node properties

model = "Freescale i.MX53 Automotive Reference Design Board";

Only in the root node, substitutes the old MACHINE_ID as a unique board identifier.

compatible = "fsl,imx53-ard", "fsl,imx53";

Lists the specific device the dts refers to as well as compatible devices. Must be used on each node representing a device and is used by Linux to bind device drivers to a device. Allows to match a single driver with multiple devices.

manufacturer,property = <value>

New properties can be added as needed and documented on the device tree bindings on the Documentation/devicetree/bindings folder of the kernel source.

Device addressing properties

#address-cells = <1>;
#size-cells = <1>;
name@addr {
	reg = <0xf4000000 0x2000000>;
};

#address-cells = <1>;
#size-cells = <1> ;
name@addr {
	reg = <0xf4000000 0x2000000> ,<0xd4000000 0x1000>;
};

#address-cells = <1>;
#size-cells = <0> ;
name@addr {
	reg = <0> ;
};

#address-cells = <2>;
#size-cells =<1> ;
name@addr {
	reg = <0 0 0x100>;
};

The value may represent indexes, registers or memory ranges used by the device. The #address-cells and #size-cells determine how the child node should be addressed.

The addresses of root children nodes are absolute while their childen may be relative.

A ranges property can perform address translation between parent and children nodes. An empty ranges property indicates identity mapping translation.

ranges = <child-addr parent-addr length>
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x80000000 0x4000>
name@addr {
	reg = <0 0x2000>;
};
name@addr {
	reg = <0x2000 0x2000>;
};

Interrupt properties

On the controller:

interrupt-controller: Declares a device as capable of receiving interrupt signals.
#interupt-cells: Number of cells in an interrupt speicifer.

tzic: tz-interrupt-controller@0fffc000 {
	compatible = "fsl,imx53-tzic", "fsl,tzic";
	interrupt-controller;
	#interrupt-cells = <1>;
	reg = <0x0fffc000 0x4000>;
};

On the device:

interrup-parent: phandle to the interrupt controller the device is attached to.
interrupts: List of interrupt specifiers, one per device interrupt signal.

lan9220@f4000000 {
	compatible = "smsc,lan9220", "smsc,lan9115";
	reg = <0xf4000000 0x2000000>;
	phy-mode = "mii";
	interrupt-parent = <&gpio2>;
	interrupts = <31 0x8>;
};

[1] Power.org Standard for Embedded Architecture Platform Requirements.

Adding touch support in Yocto

07-Feb-13

The core-image-sato default image in Yocto has touch support, but chances are it takes some tweaking to make it work. In my case I am using Digi’s ConnectCore for MX51 JumpStart Kit with a custom Yocto image, based in core-image-sato, and a resistive touch. The touch is driven by the MXC_TS driver from the Freescale BSP for the i.MX5X.

Testing the kernel touch support

Some basics checks to make sure the touch is functional:

dmesg should show:
user@computer:$
input: mxc_ts as /devices/virtual/input/input0
mxc input touchscreen loaded

And the information in the sys filesystem should be:
user@computer:$
cat /sys/devices/virtual/input/input0/uevent
PRODUCT=0/0/0/0
NAME="mxc_ts"
EV==b
KEY==400 0 0 0 0 0 0 0 0 0 0
ABS==1000003
MODALIAS=input:b0000v0000p0000e0000-e0,1,3,k14A,ra0,1,18,mlsfw

user@computer:$
cat /sys/devices/virtual/input/input0/event0/uevent
MAJOR=13
MINOR=64
DEVNAME=input/event0

Then you can check whether the driver works by doing.
user@computer:$
cat /dev/input/event0 | hexdump
0000000 002e 0000 f889 0008 0003 0000 06cb 0000
0000010 002e 0000 f89f 0008 0003 0001 03c2 0000
0000020 002e 0000 f8a5 0008 0003 0018 0001 0000
0000030 002e 0000 f8ab 0008 0000 0000 0000 0000
0000040 002e 0000 f27b 0009 0003 0000 001f 0000

Which should update continuously when you touch the screen. If that does not work you either have a configuration or kernel driver issue.

User space touch support

Usually embedded distributions have been using tslib for touch support, so I like starting with tslib and its test applications ts_calibrate and ts_test over the framebuffer.

If you do:
user@computer:$
export TSLIB_TSDEVICE="/dev/input/event0"
export TSLIB_CONFFILE="/etc/ts.conf"
/usr/bin/ts_calibrate

You should see the arrows and be able to calibrate a resistive touch.And /usr/bin/ts_test should allow you to see the touch working.
Now we get into the Yocto SATO image. The default Xorg driver used is evdev, which interfaces to the kernel’s event interfaces, evdev, which needs udev to be functional. For more details read this for an overview of the Linux input system.
The default Xorg configuration is:
user@computer:$
cat /etc/X11/xorg.conf
Section "Device"
Identifier "i.MX Accelerated Framebuffer Device"
Driver "imx"
Option "fbdev" "/dev/fb0"
# This option only recognized when "mxc_epdc_fb" frame buffer driver in
# use. Values are "RGB565" (default, 16-bit RGB), "Y8" (8-bit gray),
# and "Y8INV" (8-bit gray inverted).
Option "FormatEPDC" "Y8INV"
EndSection

Section "ServerFlags"
Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
EndSection

Which omits the InputDevice sections. Looking around (with the help of /var/log/Xorg.0.log) we find them in /usr/share/X11/xorg.conf.d/:
user@computer:$
cat 10-evdev.conf
#
# Catch-all evdev loader for udev-based systems
# We don't simply match on any device since that also adds accelerometers
# and other devices that we don't really want to use. The list below
# matches everything but joysticks.

Section "InputClass"
Identifier "evdev pointer catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection

Section "InputClass"
Identifier "evdev keyboard catchall"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection

Section "InputClass"
Identifier "evdev touchpad catchall"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection

Section "InputClass"
Identifier "evdev tablet catchall"
MatchIsTablet "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection

Section "InputClass"
Identifier "evdev touchscreen catchall"
MatchIsTouchscreen "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection

As we see all the input devices are driven by evdev.
We can get some more information using xinput:
user@computer:$
sh-4.2# xinput list
Virtual core pointer id=2 [master pointer (3)]
Virtual core XTEST pointer id=4 [slave pointer (2)]
Dell Dell USB Optical Mouse id=7 [slave pointer (2)]
mxc_ts id=8 [slave pointer (2)]
Virtual core keyboard id=3 [master keyboard (2)]
Virtual core XTEST keyboard id=5 [slave keyboard (3)]
DELL Dell QuietKey Keyboard id=6 [slave keyboard (3)]

user@computer:$
sh-4.2# xinput list-props mxc_ts
Device 'mxc_ts':
Device Enabled (112): 1
Coordinate Transformation Matrix (113): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Device Accel Profile (233): 0
Device Accel Constant Deceleration (234): 1.000000
Device Accel Adaptive Deceleration (235): 1.000000
Device Accel Velocity Scaling (236): 10.000000
Device Product ID (230): 0, 0
Device Node (231): "/dev/input/event0"
Evdev Axis Inversion (237): 0, 0
Evdev Axis Calibration (238): 985, 42, 935, 58
Evdev Axes Swap (239): 1
Axis Labels (240): "Abs X" (254), "Abs Y" (255), "Abs Pressure" (256)
Button Labels (241): "Button Unknown" (232), "Button Unknown" (232), "Button Unknown" (232), "Button Wheel Up" (118), "Button Wheel Down" (119)
Evdev Middle Button Emulation (242): 0
Evdev Middle Button Timeout (243): 50
Evdev Third Button Emulation (244): 0
Evdev Third Button Emulation Timeout (245): 1000
Evdev Third Button Emulation Button (246): 3
Evdev Third Button Emulation Threshold (247): 20
Evdev Wheel Emulation (248): 0
Evdev Wheel Emulation Axes (249): 0, 0, 4, 5
Evdev Wheel Emulation Inertia (250): 10
Evdev Wheel Emulation Timeout (251): 200
Evdev Wheel Emulation Button (252): 4
Evdev Drag Lock Buttons (253): 0

Theoretically we only have to launch xinput-calibrator and the touch will calibrate itself.
In practise, this only works if the touch has already been calibrated beforehand. With the default values it gets from xinput, the calibration does not work.  I haven’t looked into the code, but the project has a list of unanswered open bugs some of which already report this.
What can we do? Manual calibration for starters, and then xinput-calibrator for accuracy.

Manual touch calibration

For manual calibration you need to use the evtest application. If using Yocto just do:

user@computer:$
bitbake evtest

And then install the package it builds. In my case the package lives in tmp/work/armv7a-vfp-neon-del-linux-gnueabi/evtest-1.25-r0/deploy-ipks.
user@computer:$
evtest /dev/input/event0

Or whichever eventN your touch is in, and touch the four corners of your screen writting down the X,Y values. Evtest will show the RAW touch values. In my case the mxc_ts driver is working through a 10bits ADC, so the resolution is 0 to 1023.
user@computer:$
evtest /dev/input/event0
Input driver version is 1.0.0
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "mxc_ts"
Supported events:
Event type 0 (Sync)
Event type 1 (Key)
Event code 330 (Touch)
Event type 3 (Absolute)
Event code 0 (X)
Value 340
Min 0
Max 1023
Event code 1 (Y)
Value 430
Min 0
Max 1023
Event code 24 (Pressure)
Value 0
Min 0
Max 1023
Testing ... (interrupt to exit)
Event: time 3872.440377, type 3 (Absolute), code 0 (X), value 914
Event: time 3872.440383, type 3 (Absolute), code 1 (Y), value 966
Event: time 3872.440386, type 3 (Absolute), code 24 (Pressure), value 46
Event: time 3872.440388, type 1 (Key), code 330 (Touch), value 1
Event: time 3872.440391, -------------- Report Sync ------------
Event: time 3872.470939, type 3 (Absolute), code 0 (X), value 909
Event: time 3872.470945, type 3 (Absolute), code 1 (Y), value 970
Event: time 3872.470950, -------------- Report Sync ------------
Event: time 3872.501124, type 3 (Absolute), code 24 (Pressure), value 0
Event: time 3872.501130, type 1 (Key), code 330 (Touch), value 0
Event: time 3872.501132, -------------- Report Sync ------------

The touch screen size is 800×480, and the translation between the raw resolution and the screen resolution is what calibration is about.
Once you have them all do:
user@computer:$
xinput set-prop "mxc_ts" "Evdev Axis Calibration" xmin xmax ymin ymax

If you need to swap the XY axis, you can also do it with:
user@computer:$
xinput set-prop "mxc_ts" "Evdev Axes Swap" 1

The touch should work now. And xinput-calibrator should too. To make the calibration permanenent have a read at the different options here.
My recommendations would be either altering the Xorg configuration to:
user@computer:$
Section "InputClass"
Identifier "evdev touchscreen catchall"
MatchIsTouchscreen "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "Calibration" "xmin xmax ymix ymax"
Option "SwapAxes" "1"
EndSection

Or use the pointercal.xinput file as described in the link above.

Encrypting folders with ecryptfs

28-Jan-13

Ecryptfs can encrypt partitions or directores without its own partition. All the information needed to decrypt is contained on the files themselves, so it’s ideal for backup and restoration on any other system.

To create an encrypted folder:

sudo apt-get install ecryptfs-utils
mount -t ecryptfs /path/folder /path/folder

It will ask a few questions, starting with a passphrase. Enter the passphrase and leave all as defaults (aes, 16 bytes, no plaintext passthrough, no filename encryption, append signature to /root/.ecryptfs/sig-cache.txt).

mount will show (with your own ecryptfs_sig):

/path/folder on /path/folder type ecryptfs 
    (rw,ecryptfs_sig=bd28c38da9fc938b,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)

You follow the same steps to mount an existing encrypted folder. If you have never mounted that filesystem on the computer you are using you will see:

WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.
Would you like to proceed with the mount (yes/no)?

Just type yes, it’s a safe answer.

Git stash tricks

17-Dec-12

Stashing only specific files

git stash --patch
  • d Skip file
  • a Stash file
  • q Quit

Stash stuff that has not been added

git add the things you want to keep, then run:

git stash --keep-index

Splitting an old commit into more than one changeset

git rebase -i
    Mark some changes as edit.
git reset HEAD^
git add 
git stash --keep-index
    Fix things up as necessary. Don't forget to git add any changes.
git commit
git stash pop
Repeat, from #2, as necessary.
git rebase --continue

Checking out a single file from the stash

git checkout stash@{0} -- path/to/file

Saving a stashed file with a new name

git show stash@{0}:path/to/file  > path/to/file

Installing Sun/Oracle Java in Ubuntu

05-Dec-12
This is a nice script that will create the .deb packages for you to install locally.
user@computer:$ wget https://raw.github.com/thenameisnigel/oab-java6/master/oab-java.sh -O oab-java.sh
chmod u+x oab-java.sh
sudo ./oab-java.sh

Note: The original wrapper script here seems unmaintained, so I am using a fixed fork.