Linux, IT, DIY, Interesting Stuff...

NSLU Optware for Android

2012-02-20T14:44:00.001-08:00

Yes, there was kind of attempt at that already, but:

It's no longer available at the link announced and spread over the Internet (yep, it's available at another, but why so ... complicated?)
It ships binary blobs of unknown origin. Yup, maybe one could trace their origins, but who'd bother, and telepaths are on vacation as usual. It should be described stringently where they are from, if not scripted to be collected in user's build directory from known good sources, so users can actually trust them.
It is marketed as supporting only something called "Nook Color". What's that, I thought it was Optware for Android? Could I have Optware specifically for my HP nx9420 notebook, serial number XYZZY, 3Gb of RAM? Just make sure it's different from the Optware for the same notebook, but with 4Gb of RAM, and from any other Optwares in the world!
It goes as far as patching rootfs ramdisk. That may work on Nook Color or may brick it. That may work on next firmware upgrade of Nook Color or may brick. That may work on another device or may brick. The talk is not about this, it's about the fact that it's two big differences - to be able to install and run bash and to have sshd started automatically after the boot. I definitely want first, but I will do good consideration if/when I need second. So, I don't want setup for those 2 stages to mixed and done without myself being ready for stage 2.
It still appears to rely on presence of some other 3rd party stuff (look at that #!/bin/sh line, there's no such thing on pristine Android device, only #!/system/bin/sh)

So well, I decided to take my turn on hacking up an Optware bootstrap script for pure Android (root and adb access are the only prereqs). It's hosted here: https://github.com/pfalcon/optware-android and intended to be run on a Linux hosts. It starts by downloading CodeSourcery toolchain for libc and ipkg and immediate dependencies from http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/stable to bootstrap ipkg on device. Yep, it's being tested on Nook Tablet so far, but at least it is called Optware for Android and I have that aim ;-). So, bugreports and patches are welcome. And I have few more devices to test it on, just steal me some time...

HC-04 Bluetooth module and BlueCore4 Deep Sleep

2012-01-29T16:26:00.000-08:00

The good news is that BlueCore indeed has Deep Sleep mode, it's not marketing hype. It can be verified by configuring PSKEY_CLOCK_REQUEST_ENABLE to drive PIO when chip uses/doesn't use external clock. The key here is not to keep PSTool run (which well, you need to tweak sleep settings).

The bad news is that an HC-04 module in Deep Sleep still consumes 2.5mA, which is far too high for anything called Deep Sleep. So, something on the module besides BlueCore still consumes too much power. However, when BlueCore is held in reset state, entire module consumes 0.

Without Deep Sleep, simple LED flash task consumes 3.5mA, so there's not that much gain from the Deep Sleep...

Enabling SPI logging in BlueSuite tools CSR BlueCore chips

2012-01-29T06:06:00.000-08:00

BlueFlashCmd.exe and other tools, part of CSR BlueSuite toolset to program BlueCore Bluetooth chips, has support for logging SPI communication with a chip. To enable it:

BlueFlashCmd.exe -trans "SPIDEBUG_FILE=spi.log SPIDEBUG=ON" -chipver

The key parameter here is SPIDEBUG_FILE - logging is activated when it's specified, and thus logging is always done to a file. One way to have logging go to a console is to use SPIDEBUG_FILE=con: , but then it won't be possible to redirect it.

Besides SPIDEBUG=ON, there're other logging levels/features:

SPIDEBUG
SPIDEBUG_REPRODUCIBLE
SPIDEBUG_WRITES
SPIDEBUG_READS
SPIDEBUG_WIRE

The keys may be also specified in the environment instead of -trans switch arguments.

Looking at the output produced, it turns out it spends a lot in calibrating SPI speed, a way to that down is to use SPISLOW=ON setting right away.

Notes on Android EGL/native windowing system interface

2012-01-17T17:00:00.000-08:00

EGL is defined here and appears to be in OpenGL ES something what GLUT was (?) in OpenGL world. At least, EGL is what takes care of actually displaying on screen what was rendered by OpenGL ES.

Donut

EGLNativeWindowType is defined in opengl/include/EGL/eglplatform.h as struct egl_native_window_t* . egl_native_window_t is defined nearby in opengl/include/EGL/eglnatives.h . This is nice, clean, standalone structure (unlike horror in Eclair+). It starts with a "magic" (signature) 0x600913, followed by "version" which is sizeof of the structure (now I know why Microsoft gets a buck on each Android phone sold - they for sure patented this (stupid? lazy?) trick widely used in Win32 API). There're some function pointers (virtual method table) used by EGL to call into native windowing system (deep, close to vendor drivers) to support its workings. Out of these, there's essentially one related to rendering finalization: swapBuffers(). So yes, it seems that eglSwapBuffers() just calls out to this. The structure also directly contains "Base memory virtual address of the surface in the CPU side" and other easily graspable memory/graphics notions.

It's clear that in its young years, Android was fair and naive, not suitable at all for typical vendor OpenGL mumbo-jumbo. The "fix" came with the later versions.

Eclair and following

EGLNativeWindowType is defined (in include/EGL/eglplatform.h) to be struct ANativeWindow*. ANativeWindow was android_native_window_t in Eclair, but was renamed to ANativeWindow in Froyo (android_native_window_t is still available for compatibility). ANativeWindow is defined in platform/frameworks/base/include/ui/egl/android_natives.h:

ANativeWindow not just emulates VMT, but seems to want to do entire C++ in C-like manner in its metes and bounds. It uses subclassing from android_native_base_t, and that contains fields for magic ("_wnd" for ANativeWindow) and version-sizeof. Methods defined are also more involved. Among the most interesting are dequeueBuffer(), lockBuffer(), queueBuffer(). Essentially, it appears that EGL takes a free buffer out of native system's rotation, locks it for changing its contents, then puts back into queue for display.

Actual implementation of ANativeWindow for read device screen is in libs/ui/FramebufferNativeWindow.cpp . There's factory function to get its instance: android_createDisplaySurface().

All implementation details on buffers used are hidden in android_native_buffer_t type. It is also subclassed from android_native_base_t, its magic is "_bfr". Among simple things like width/height it contains buffer_handle_t, which leads in utero of vendor graphics driver. buffer_handle_t is native_handle*, and native_handle is a generic container for arbitrary number of fd's and pointers.

native_handle's are produced by gralloc vendor module, and that's exactly what FramebufferNativeWindow constructor does - it loads gralloc module, then uses it to open framebuffer and gralloc devices. It then allocates back and front buffers from gralloc devices with the size of the framebuffer. queueBuffer() method is implemented by calling framebuffer's post() method which well, shows the buffer on the screen.

Thoughts/notes on Android version upgrades and reusing Android drivers

2012-01-17T10:38:00.000-08:00

So, what it takes to upgrade Android on an arbitrary Android device (from user perspective)? What takes to run Linux in full-fledged mode? This boils down to few things:

Kernel porting

Upgrade kernel. This means forward-porting hardware support modules to a new kernel version. That's, when source code for such modules is available. Sometimes, it's not violating GPL (or tainting kernel, but who wants that? ;-) ). In an ideal world, that would all that's needed, but vendors don't like GPL, and try to move stuff outside of kernel. So, the list continues.

Bitblt acceleration porting

Next step is making sure that basic hardware acceleration works - accelerated bitblt/compositing (defining compositing as bitblt with alpha). This is actually pretty important step - without accelerated bitblt, Android with more or less big screen will run pretty sluggishly. Well, X Windows won't run too zippy either. Bitblt code in Android lives in /system/lib/hw/copybit.*.so and depends on gralloc.*.so from the same dir (* there is vendor/implementation identifier - Android support multiple, pluggable implementations). Needless to say, for a random device, source for these modules are not available - vendors don't have to provide it, it's Apache2-licensed, and very few choose to uphold OpenSource spirit nonetheless. So, if new Android version have changes the ABI for those modules, then oops - upgrade is "not possible" is layman terms. Of course, real men will immediately think about writing adapters, etc...

What about other X and other "foreign" windowing systems? They would need drivers/adapters too, and base all their low-level FB access based on Android's gralloc/bitblt/etc. model.

OpenGL ES porting

Last, least, but nonetheless. Curse of the modern world - OpenGL. You didn't have it on your Apple 2 (I mean Apple 2, yes, not what you thought about!) and everything was great, wasn't it? Apart from games you don't have time to play, what it's useful for? Yes, as soon as we'll stream videosignal directly into the brain, it will be useful for augmented reality, but I mean, *useful now*. They keep talking they added some hardware acceleration using OpenGL to the normal UI, then immediately say it didn't work that great, and depends on many things, because... Because OpenGL simply doesn't work that great, yeah. For example, even "accelerated", it's pretty slow, buggy, inconsistent across devices, etc, etc.

Anyway, thanks for listening to the rant. Let's de-emphasize usefulness of OpenGL, let's just take it as a challenge - vendors hacked it, so why can't hackers hack it? The basic idea is the same as with bitblt - there's an interface between closed vendor OpenGL ES implementation and Android. If interface changed, you're hosed. I mean, you write adapters. You also write adapters to make it talk with your windowing system of choice, and not Android. The core interfacing part of OpenGL ES/Android junction is EGL. How to deal about it is worth a separate post.

New Hack Toy - Zenithink ZT-180

2012-01-17T09:14:00.000-08:00

Recently I got new hack toy: cheap (well, depends) Chinese Zenithink ZT-180 tablet. This one seem to be (have been) pretty popular and hacker-friendly. Here's data about it:

Vendor: http://zenithink.com/
Product home page, ZT180-102 (it's the oldest in the product list, so soon will go to "Retired products" (== /dev/null))
CPU: IMAPx200 (or IMAPx210, IMAPx220), ~1GHz
GPU (SoC-builtin): GC600 (tentative)
RAM: 512MB (Android boots with mem=384M)
Bootloader: u-boot
Kernel source from the vendor (github)
Slatedroid forum announcement and discussion about the kernel release above
Vendor toolchain
Post saying that user yuray started upgrading kernel to 3.0.4. Following posts add more details, no source link provided.
yuray also appears to be the author of ZT-180-Linux-Flash-Tool.
Slatedroid ZT-180 Wiki
More detailed hacking information

It seems that I've got vendor model ZT180_G2 (maybe, ZT180_G0).

Button combinations to hold during power on:

Home+Power - Upgrade firmware from /sdcard/zt-update/
Left arrow (of swing double-button)+Power - Boot with debug kernel from /sdcard/zt-debug/ . Debug kernel is booted and continues with the normal boot process.
Right arrow (of swing double-button)+Power - Multiboot support, select one of 3 modes:

Android adb - kernel with ADB over USB support
Android mass storage - kernel with mass storage USB gadget support (tablet is presented as a mass storage when connected to host)
Other OS - WinCE

Random links:

http://www.slatedroid.com/topic/10233-zenithink-zt-180-cpu-actually-infotmic-imap210-cpu/
http://www.androidtablets.net/forum/infotmic-based/2354-infotmic-chips.html

Stopping Android GUI services

2012-01-16T15:31:00.000-08:00

Well, this really worth a cross-post. The way to stop Android GUI services is (under root of course):

setprop ctl.stop zygote

UPDATE: Thanks to hint from StackOverflow: there're even simpler commands: "start" & "stop". Surprise.

Bluetooth Park Mode Exposed

2012-01-07T09:04:00.000-08:00

So well, as I settled on Bluetooth as a wireless sensor/automation protocol and grow my device base, I started to wonder what will happen when I'll have more than 7 slave devices. Bluetooth stack of master device (Bluez in our case) must be smart to put devices into and out of PARK mode to allow to communicate with more than 7 devices, right? Not in this world.

Not only Bluez doesn't support park management, according to Marcel Holtmann, the problem is that it's really not known if there're devices (masters) which can support more than very limited number of slaves, or even have decent park mode implementation at all:

Anyway, I started to test parking with devices I have.

HC-04 Bluetooth module with CSR BlueCore4-Ext

# hcitool cc 00:11:10:xx:xx:xx; hcitool con

Connections:
    < ACL 00:11:10:xx:xx:xx handle 12 state 8 lm MASTER

What we need here is a connection handle 12 (0x0c). hcitool doesn't have dedicated command for part mode (and for lot of other things), so we'll use raw HCI command mode using "cmd" command:

# hcitool cmd --help
Usage:
    cmd <ogf> <ocf> [parameters]
Example:
    cmd 0x03 0x0013 0x41 0x42 0x43 0x44

What's important here is that <parameters> should be byte values. If words should be given as parameters, they should be give by bytes in little-endian format.

# hcitool cc 00:11:10:xx:xx:xx; hcitool cmd 0x02 0x05 0x0c 0 0x50 0 0x40 0

Here we run HCI_Park_State(Connection_Handle=0x000c, Beacon_Max_Interval=0x0050, Beacon_Min_Interval=0x0040) command (see Bluetooth spec). And here's communication as captured by hcidump (parts irrelevant to park command omitted):

2012-01-07 15:36:46.084074 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 15:36:46.086040 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 15:36:46.271047 > HCI Event: Mode Change (0x14) plen 6
    status 0x24 handle 12 mode 0x00 interval 0
    Error: LMP PDU Not Allowed

This "LMP PDU Not Allowed" was quite confusing and took me lot of googling to figure out. Fortunately, I found insightful post from a CSR guy right on this matter: http://article.gmane.org/gmane.linux.bluez.devel/72

What we get here is that local Bluetooth master just forwards status it got from the remote device. As the message suggests, park might be disabled in remote device line policy. Let's see:

# hcitool cc 00:11:10:xx:xx:xx; hcitool lp 00:11:10:xx:xx:xx
Link policy settings: RSWITCH HOLD SNIFF PARK

Here's slight issue of what hcitool lp actually does. According to man, it "displays link policy settings for the connection to the device with Bluetooth address". There's also "hcitool lp" command which "Sets default link policy". So, reasonable assumption would be that every device may have default link policy, then during connection, they negotiate link policy which is suitable for the connection. Ok, let's set PARK policy explicitly:

# hcitool cc 00:11:10:xx:xx:xx; hcitool lp 00:11:10:xx:xx:xx PARK; hcitool lp 00:11:10:xx:xx:xx; hcitool cmd 0x02 0x05 0x0c 0 0x50 0 0x40 0
Link policy settings: PARK 
< HCI Command: ogf 0x02, ocf 0x0005, plen 6
  0C 00 50 00 40 00 
> HCI Event: 0x0f plen 4
  00 01 05 08 

But hcidump shows the the same "LMP PDU Not Allowed" error. So, what we have is that HC-04 module advertizes park support, it apparently negotiates its availability for connection, but when asked to actually perform it, it rejects it. This is so much correlates with this message: http://article.gmane.org/gmane.linux.bluez.user/12710

PS3 Bluetooth remote

# hcitool info 00:06:F5:xx:xx:xx
Requesting information ...
    BD Address:  00:06:F5:xx:xx:xx
    Device Name: BD Remote Control
    LMP Version: 2.0 (0x3) LMP Subversion: 0x229
    Manufacturer: Broadcom Corporation (15)
    Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
        <encryption> <slot offset> <timing accuracy> <role switch> 
        <sniff mode> <RSSI> <power control> <enhanced iscan> 
        <interlaced iscan> <interlaced pscan> <AFH cap. slave> 

So, this fair Broadcom device doesn't even conceal the fact that it's barely Bluetooth interoperatable - it doesn't support park state at all.

No surprises when asking it to go there nontheless:

2012-01-07 16:03:08.863586 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 13 max 80 min 64
2012-01-07 16:03:08.865636 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x1a ncmd 1
    Error: Unsupported Remote Feature / Unsupported LMP Feature

LG KS20 WindowsMobile phone

# hcitool info 00:1E:75:xx:xx:xx | grep park
        <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>

So, this one advertizes park. But:

2012-01-07 16:29:11.288514 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 16:29:11.290485 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 16:29:11.466508 > HCI Event: Mode Change (0x14) plen 6
    status 0x0c handle 12 mode 0x00 interval 0
    Error: Command Disallowed

Broadcom is such Broadcom...

Huawei U8160 aka Vodafone 858 Smart Android phone
# hcitool info 04:C0:6F:xx:xx:xx | grep park

<empty>

2012-01-07 16:19:01.322536 < HCI Command: Park State (0x02|0x0005) plen 6

    handle 12 max 80 min 64

2012-01-07 16:19:01.324521 > HCI Event: Command Status (0x0f) plen 4

    Park State (0x02|0x0005) status 0x1a ncmd 1

    Error: Unsupported Remote Feature / Unsupported LMP Feature

Broadcom is such Broadcom...

HTC Mogul WindowsMobile phone

2012-01-07 16:11:14.184067 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 16:11:14.186430 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 16:11:14.528429 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x03 interval 80
    Mode: Park

Bwahaha! TI rules!

Samsung i740 WindowsMobile phone

Manufacturer: Cambridge Silicon Radio (10)

2012-01-07 17:54:17.141466 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 17:54:17.142911 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 17:54:17.472919 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x03 interval 80
    Mode: Park

Linux computer with Broadcom chip

Park mode work here, supervised by Bluez.

So, out of 7 devices (that's whole piconet, and I have more!) only 3 supported park mode.

More insightful posts:

Linux kernel Bluetooth ACL connection auto-disconnect

2012-01-04T14:05:00.000-08:00

I finally found time to figure out why "hcitool cc" created connections die very soon (see previous posts). It turned out to be handled on the Linux kernel level. What's worse is that it's hardcoded at 2s - no provision for adjustment via sysfs for example. http://lxr.free-electrons.com/source/include/net/bluetooth/hci.h?v=3.0#L120 :

118 /* HCI timeouts */
119 #define HCI_CONNECT_TIMEOUT     (40000) /* 40 seconds */
120 #define HCI_DISCONN_TIMEOUT     (2000)  /* 2 seconds */
121 #define HCI_PAIRING_TIMEOUT     (60000) /* 60 seconds */
122 #define HCI_IDLE_TIMEOUT        (6000)  /* 6 seconds */
123 #define HCI_INIT_TIMEOUT        (10000) /* 10 seconds */
124 #define HCI_CMD_TIMEOUT         (1000)  /* 1 seconds */

Actual disconnection happens in hci_conn_timeout(). Other issue is that such disconnect reported as "Remote User Terminated Connection", which is, well, not true, as I don't terminate it, the system does. There's another status code, "Remote Device Terminated Connection due to Low Resources" which IMHO more suitable (if there's no "low resources", why do you disconnect so quickly, dear Linux?).

I quickly made a patch to be able to adjust disconnect timeout via sysfs, to experiment with low level connection more comfortably. Unfortunately, it turns out that I can extend delay to max 10s, even if set value much higher. So, something appears to call disconnect routine, even though I don't see any other references or timer manipulation %).

Bluetooth link key types

2011-12-30T05:06:00.000-08:00

From http://lxr.linux.no/#linux+v3.1.6/include/net/bluetooth/hci.h#L254 :

/* Link Key types */
#define HCI_LK_COMBINATION        0x00
#define HCI_LK_LOCAL_UNIT        0x01
#define HCI_LK_REMOTE_UNIT        0x02
#define HCI_LK_DEBUG_COMBINATION    0x03
#define HCI_LK_UNAUTH_COMBINATION    0x04
#define HCI_LK_AUTH_COMBINATION        0x05
#define HCI_LK_CHANGED_COMBINATION    0x06

Pairing Bluetooth devices from command line

2011-12-30T04:54:00.000-08:00

Following appear to be commands required to trigger pairing process from the command line:

hcitool cc <bdaddr>; hcitool auth <bdaddr>

Commands must be on the same line, separated by the semicolon, as described in previous post.

At this point, Bluez auth agent should kick in, asking for a code, if you have GUI one.

I found a page which suggests that only "hcitool cc" was enough for the author to trigger pairing, this could be explained by the fact that prior to 2.1, Bluetooth supported security modes which could protect either entire device access or just some of its profiles.

Shopping for 3D TV...

2011-11-12T09:56:00.000-08:00

Shopping for 3D TV (again), few findings:

There are no non-LED 3D TVs for sale in this part of world anymore (in particular, my older favorite, LE40C750 is no longer available)
Samsung D6xxx series (the cheapest) were caught red-handed not providing FullHD resolution in 3D: via Samygo. (Note from myself: Samsung was caught because lots of people actually buy their stuff, what one can think about other vendors?)
LG goes out of line of vendors with 3D shutter glasses technology with their FPR ("Cinema 3D" in marketing speak) technology. It uses passive (no power needed) polarized glasses, like RealD cimenas. Announced April (on these longitudes), already in local shops at not-so-indecent prices. FPR is Film Patterned Retarder, and I hope the last word is spelled right, because I have high hopes for this tech. It shares the same issue as Samsung D6xxx: there won't FullHD here for sure, but at least it's official and there're other benefits.

Kindle Packages I use

2011-11-09T11:53:00.000-08:00

jailbreak
usbnetwork
physkeyb

Links for November 2011

2011-11-08T14:12:00.000-08:00

Kindle:

Amazon Kindle official GPL source code
Kindle keyboard shortcuts and other reference
Latest jailbreak appears to be one from NiLuJe (forum). It's known to work with firmware 3.3. Hacks/updates should be copied to Kindle USB drive root.
SirAlex's page
Intro for writing kindlets

Linux kernel module tricks:

How to bind Linux driver to device whose IDs it doesn't know (yet), without recompiling
Building a kernel module separately

Fixing fan cooler in Asus X34F notebook

2011-10-23T12:15:00.000-07:00

I spent good deal of day today fixing howling, growling, roaring and making other pleasant noises fan in my Asus X34F notebook. X34F appears to be region-specific version of U35F, and motherboard bears labels of UL30A, so I guess this may be pertinent to them either.

I wasn't able to find a service manual, so I proceeded with disassembly by experience and intuition. It turns out that to detach cooler one needs to unscrew one motherboard plate completely (there're two, bound with a connector). The cooler part number turned out to be KDB04505HA by Delta Electronics. Vendor site showed no trace of this part no. But quick googling showed that it's the same part no used in Macbook Pro with similar performance stories. One another reason you don't need to pay a lot to get the same c.r.a.p.

Once I completely detached it, I figured how it could make those noises - impeller could dance on its axis, and while doing so could touch plastic casing. So, my idea was to either cut the corresponding side of impeller, or increase vertical space in which it "dances". I went for the latter, adding two washers between metal and plastic casing parts and gluing another washer on third point to get more support.

I decided also to oil fan, and considering oiling with machine oil could lead to just more dust accumulation, figure I take a pencil and oil it with graphite. Big mistake - either that pencil didn't really have pure graphite, or I put it there too much, but after re-assembling and powering all stuff, I saw that the cooler stopped working at all.

I almost gave up and started to look for closest repair shop, then figured I already have thing half-disassembled, and they would need to extract the fan anyway, so guessed I do it myself and deliver it to repairman in pieces. But before then, heck, I'll make another pass it it - first of all, try to power it on despite its rather home-use unfriendly connector.

Couldn't reliably figure the connector pinout (found pinout only for 12V desktop fans, who knows if laptop one would be proprietary), so tried googling for wire color codes instead. This page gave me good hints (black - GND, red - VCC, blue - PWM for speed control, yellow or another - speed sensor) which I decided to try with power supply at last. Unfriendly connector? Was able to stick into it breadboard wires, then breadboard, then breadboard power adapter. Saw the motor nudge, as struggling with friction. Took off the impeller, wiped its axis, and cleaned other part as best as I could. Put it back and powered, and so it moving - but, with whistling and vibration, even though suspected plastic part was off. Well, decided there's little to lose and oiled it with smallish drop of machine oil.

That was it! The thing stopped its hellish screams and just monotonically buzzed if move ear close to it. Reassembled all the stuff - the noise level is close to that which was when I bought it, as far as I can tell. acpitz sensor temperature is down to 55dC from 95dC I saw before. Finger crossed that oiling will help for decent time.

Conclusion and note to myself: It's indeed nice idea to be in power of your hardware, no doubts, and fears off. And its better to invest into tools than to pay for services of unknown quality (could easily imagine the same oiling to be done, but charged as replacement).

UPDATE: No, it didn't last even a day :-(

Making hcitool commands work

2011-10-19T09:15:00.000-07:00

It's a shame how some now-ubiquitous technologies, like Bluetooth, are under-used and under-understood. And by usage I don't mean here occasional business card exchange, net access, being bluesnarfed and other boring consumer-level activity, but page scans, inquiries and having secure wireless communication you can trust (or not).

Anyway, if you ever tried using hcitool you may think it barely works. For example:


# hcitool cc <bdaddr>
# hcitool lq <bdaddr>
Not connected.

Ok, so here's the matter. First of all, hcitool accesses hci device directly, and that requires root access. Secondly, it works on low protocol level (ACL), so connection established by "cc" is of course not pairing or service-level connection. It's low level connection, which persist only while data is transferred and shutdown quickly to preserve the power. Yep, it shuts down while you type or even re-run next command. That's how it should be done:


# hcitool cc <bdaddr>; hcitool lq <bdaddr>
Link quality: 255

More fun:


# hcitool cc $BDADDR; hcitool auth $BDADDR; hcitool enc $BDADDR; hcitool key $BDADDR; hcitool con
Connections:
< ACL 7D:75:75:xx:xx:xx handle 12 state 1 lm MASTER AUTH ENCRYPT SECURE

Links for September 2011

2011-09-13T07:36:00.000-07:00

Speech synthesis/TTS links, focusing on Russian:

OpenSource:

FestLang, Festival voices for different languages, in particular, Russian.
VoxForge, speech corpus collection site
AOT, automated text processing (Russian)
RHVoice, mailing list archive (Russian)

Towards decent mouse wheel support in Android

2011-06-28T11:41:00.000-07:00

One thing everyone would notice on attaching a USB mouse to an Android device is that mouse wheel is not supported, which makes interaction very tedious. I take a quick look at the state of its support.

Android-x86 project advertises mouse wheel support, but looking at their patch, they translate mouse wheel clicks into up/down buttons. That's better than not supporting wheel at all of course, but still not intuitive usage. What I'd like to have is not analog of up/down key press, but actual scroll, i.e. analog of drag.

But probably, such behavior couldn't be reliably emulated on the lower level of input processing, (or this might lead to adverse effects, like mouse wheel movement interpreted as click). Instead, higher-level controls should have explicit support for discrete scroll events. For example this event handler block should be factored out to be callable for such event and be passed just deltaY.

Of course, that would be more or less big refactor, so another approach would be just waiting until Google thinks it gave enough competitive advantage to big vendors over small and finally releases 3.0+ source code, which supposedly implements wheel support.

Links for June 2011

2011-06-27T10:07:00.000-07:00

http://sigrok.org/ - OpenSource logic analyzer software supporting lot of hardware analyzers (C++/Qt, protocol plugins in Python)
http://dangerousprototypes.com/2010/07/23/logic-analyzer-client-roundup/ - Logic analyzer client roundup
http://blog.visucore.com/categories/embedded - Blog posts about using and hacking USBee SX. In particular, how to find UART pins on a device using it; how to replace firmware with self-compiled using SDCC, etc.
http://openenergymonitor.org/ - Open Energy Monito
On accuracy of (commercially available) power meters:

Lies, Damn Lies and Cheap Power Meters
That one lying disassembled with blob chip, but with potentiometers to calibrate
Comparing KaW and a clone with industrial piece
http://www.pupman.com/listarchives/2005/Aug/msg00936.html

Hacking Luxeon SP-1

2011-06-26T12:50:00.000-07:00

I finally going to get Arduino, and while I'm choosing flavor and waiting for it, I can't help but disassembling all devices I have at home, each time speaking: "This must have Arduino inside!" (meaning of course that I expect it to be based on general-purpose MCU). Gosh, I usually get "blob chip" (uncased chip with blob of epoxy on top).

Well, I finally had my expectations fulfilled - Luxeon SP-1 voltage stabilizer/cutter features ATMEGA48V-10PU (Flash: 4k, EEPROM: 256, RAM:512). Not only that, it is installed in DIP socket! Buy from Luxeon, they're hacker-friendly ;-).

I bought the device actually for a wattmeter it features (which fact is hard to figure out from common specs found in the shops, I accidentally read somebody mentioning it on a forum). The wattmeter is of course not bright - for a lamp rated 100W it shows 88W, and for more powerful equipment (like perforator) understates wattage even more (maybe it's difference between real and apparent power factor).

Still, for $17 you get Arudino-alike with voltage/current sensor and hacking possibility. Woot!

BOM:
High-power board:

Relay: Coil: 24VDC, 5A/240VAC
7805
Coil transformer LR-019B

MCU board:

ATMEGA48V-10PU
2 buttons
2 LEDs (red & green)
3-digit 7-segment LED indicator

Hacking Technoline WS 585 weatherstation

2011-06-26T05:55:00.000-07:00

Technoline WS 585 is a simple consumer weatherstation offering builtin indoor temperature sensor and outdoor wireless (433MHz) temperature sensor. But as funny extra, it comes with wireless USB dongle which, being attached to computer running special (Windows) software, transmits to the base station weather forecast for next few days as well as extra weather data for today.

There're two problems with that: I prefer my weather forecast site, not one hardcoded by the vendor, and, I don't have constantly running Windows box. Besides, this device is essentially low-resolution wireless LCD (albeit with funny pixel shape), so one may want to show build status or loadavg on it.

So, I wanted to hack a Linux driver for it for a long time. Wider-scope, I wanted to grok USB and hack driver for it for longer time. Few times before I had a look at usbsnoop log of something, It seemed for overwhelming and I didn't really put much effort into it.

So well, I read up USB docs (Usb in a NutShell is a good summarization of the spec), and started to look at USB descriptors and logs with understanding eye.

Here are info and descriptors for WS585 dongle btw:

dmesg:

[1118327.253222] usb 2-1.3: new low speed USB device using ehci_hcd and address 3
[1118327.524340] usbcore: registered new interface driver hiddev
[1118327.527975] input: Tenx Non standard Device as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/input/input51
[1118327.528162] generic-usb 0003:1130:0202.0001: input,hidraw0: USB HID v1.10 Device [Tenx Non standard Device] on usb-0000:00:1d.0-1.3/input0
[1118327.530011] input: Tenx Non standard Device as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.1/input/input52
[1118327.530182] generic-usb 0003:1130:0202.0002: input,hidraw1: USB HID v1.10 Device [Tenx Non standard Device] on usb-0000:00:1d.0-1.3/input1
[1118327.530554] usbcore: registered new interface driver usbhid
[1118327.530557] usbhid: USB HID core driver

lsusb:

Bus 002 Device 003: ID 1130:0202 Tenx Technology, Inc.

lsusb -v:

Device: ID 1130:0202 Tenx Technology, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x1130 Tenx Technology, Inc.
  idProduct          0x0202 
  bcdDevice            1.00
  iManufacturer           0 
  iProduct                2 Tenx Non standard Device
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           59
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      41
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      23
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10
Device Status:     0x0000
  (Bus Powered)

So, it uses well-known programmable microcontroller chip from Tenx Technology, found in bunch of other devices like USB missile launchers, etc.

By the end of day I had a PyUSB app which implemented the protocol seen in usbsnoop log. It received all the same (way, similar) responses from the chip. But it didn't exhibit external behavior. Specifically, under Windows, LED on the dongle blinks about every 55s (sic, less than whole minute), and right at the same time weather station updates its display. Under Linux with my app, LED never blinks, and no updates are shown on the display. I tried to to adjust my app to use the same delays between requests as seen in the original log, but no avail.

So, I have 2 ideas here: I made some mistake transcribing log into PyUSB calls, or, it's all timing related, and I didn't get the timing right. I tried to capture USB log around the blink, and don't see any request which could make explicit "transmit" request. I have following hypothesis: base station doesn't listen air all the time, it turns on it radio only ~ once a minute. So, dongle at first synchronizes to the base station. Then, it just transmits data at predefined intervals. And control requests from host don't transmit stuff immediately, but put it into buffer for the next transmission.

Is that true or not, hard to tell. But this device is for sure more complicated than other Tenx-based ones due to its wireless and trickle-transmit features.

I've put my current code together with USB logs to git at https://gitorious.org/homeauto/homeauto-devices

Comparison of OpenSource PDF readers for Android

2011-06-12T02:54:00.000-07:00

Today we're going to review few open-source PDF readers for Android platform. The table below provides links and feature-by-feature comparison, with more detailed discussion of features below the table. It should be noted that all these readers are based on the same PDF rendering library - MuPDF, so offer roughly the same rendering quality, the differences may be only due different version of the library used, or different configuration options (for example, some readers compile MuPDF without JPEG2000/JBIG support, or without standard PDF fonts).

The review summarizes with expectable conclusion - there's no perfect reader so far, but selects clear winner, which is worth to be hacked on.

Feature	DroidReader 0.5	APV aka PDFViewer 0.2.9	VuDroid 1.4	MuPDF Android Client 0.8.165
Builtin open file	-	+	+	-
On-screen zoom	-	+	+	+
Continuous pages	-	+	+	-
Page smaller than screen	- (force close on attempt)	+	-	-
In-app rotate	+	+	-	-
Go to page	+	+	+	-
Table of contents	-	-	-	-
Find text	-	+	-	-
JPEG2000/JBIG	- (doesn't recognize pdf)	+	-	+
Other formats	-	-	DJVU	-

Builtin open file - whether you can start application and select file to view, or must have a compatible file manager and open PDF in it using "open with".
On-screen zoom - whether you can zoom by direct manipulation on screen (like, pinch zoom, zoom in/out widgets) or need to go to menu. Needless to say, without on-screen zoom a reader is hard to use for real reading.
Continuous pages - whether you see single page at time and need to use explicit next/prev page actions, or can just scroll a page away and see next/previous page. (Arguably, continuous page reading is easier and more productive.)
Page smaller than screen - whether you can zoom out page so it is smaller than screen. For continuous pages reader, that would mean showing more than 2 pages at the same time on the screen. While this seems like neat feature, it actually just complicates real reading, when you need to take extra care to zoom back carefully after occasional zoom-in. (That's of course why most apps don't bother to implement it.)
In-app rotate - whether app has own support for rotating pages, or relies on OS to support rotation. Got a vendor-crippled device without OS support for rotation? You're lost without in-app rotate, so that's boon.
Go to page - basic navigation feature. That's not much convenient for real reading, but without this, you can't do any real reading at all.
Table of contents - real navigation. For an app to be really usable, it must support this. Nope of apps in review does though.
Find text - other very useful navigational feature. You hardly can read technical/reference docs without this.
JPEG2000/JBIG images support - Apps which doesn't support these images format don't really support PDF, just some crippled subset of it.
Other formats support: You found your perfect PDF reader? Congrats, now repeat that for all other ebook formats you use. Don't wanna waste time like that? Choose readers which support all reasonably similar formats. For already typeset ebook, there're actually two formats: PDF & DJVU, so good reader should support both. For TXT, HTML, CHM you indeed would rather look for different reader with different featureset.

And the winner is...

Based on the table above, the clear winner is VuDroid: it supports both typeset-ebook formats, PDF & DJVU, and has reasonable usability features (like has limit for page zoom out, as well as adjusts zoom on rotation). One serious, but easy to fix thing lack of JPEG2000/JBIG support (fixable by extending MuPDF config). Other thing it lacks comparing to APV is text find. Well, all readers in review lack ToC support, which a perfect reader must have. Back to VuDroid, it's UI is rather bare - there's no even About dialog, so you can't know that you're running VuDroid at all, or its version!

Breaking out of Android sandbox

2011-03-20T05:53:00.000-07:00

The aim: run real native applications side-by-side with Android Dalvik applications.
Reason: Android imposes drastic lifecycle scheme on any application started under its Dalvik VM. That lifecycle is not how real software is written (be be written, should be written).

So, the idea is to run Linux-native application which will create a window/surface/display compatible with ones managed by Android's "Window Manager". It seems that level on which such app should operate is "SurfaceFlinger" Android service which is essentially a compositing display server. So, the app will create a new surface (possibly, still showing standard Android toolbar), and essentially will have exclusive control over the hardware during its runtime (for example, it apparently would read input events directly from Linux devices), but of course it should be able to "minimize" itself to let Android window manager to control its windows, and be able to "maximize" (by receiving some IPC event).

The problem: how to deal with OOB Android window interaction (for example, alarm window pops up)? Apparently, that should lead to another surface to be created on top of our app's, so new one should be just visible to user, and our one should just go offscreen. But what about input events? Does SurfaceFlinger notifies clients of their surface state changes?

Mobile Multitasking (iPhone vs. Android)
Why the iPad and iPhone don’t Support Multitasking
Anatomy & Physiology of an Android
Using SKIA in Android native code
Necessitas blits to surface from native code, AndroidBitmap_* functions (libjnigraphcs.so) are used, and it pulls its implementation from AOSP source, so it works for any Android version (libjnigraphcs.so is just a thin wrapper of Skia functions). A Necessitas commit where they switch from using internal surfaces to AndroidBitmap_*: http://qt.gitorious.org/~taipan/qt/android-lighthouse/commit/37f298c40ca19570f2c2302f227323711c8478e9 (Some info at Issue 4)
Notes and native Linux programming under Android (static and dynamic linking examples using CodeSourcery toolchain)
Hello World C program using Android Toolchain
http://blog.sina.com.cn/s/blog_6074fcd20100g648.html - Some class diagrams
http://kcchao.wikidot.com/surfaceflinger - Some class diagrams
surface flinger framework and issues
frame buffer

http://www.mail-archive.com/android-porting@googlegroups.com/msg01680.html

OpenSource Package Manager for Android

2011-03-13T20:04:00.000-07:00

Android is surely breaks records in many areas, like openness of platform, etc. But not only that, Android Market delivers spyware and junkware to your devices with unsustainable ease - I don't remember such wealth at Palm and PocketPC times. Maybe paid apps save the situation, but wise platform owners don't offer them in various places around the world. All in all, while it's generally great fun to dig for gems in such places, there got to be something else.

So, next move of thought is towards open-source package manager. But only to find out that:

Trackdroid is fool's gold, with source never released (or taken down after release)
Undroid is stopped because "ultimately it was made irrelevant by Google market place."
apkget was started just this year, but already undergone repo created - something committed - repo removed cycle.

Googling for "android opensource package manager" doesn't give much - you know, it's all "Android OpenSource Project" and there's a PackageManager class. And - suddenly, thanks to Wikipedia, there's a winner:

f-droid.org

They offer maintained client, they offer repository of packages. Hurrah!

UPDATE: F-Droid is a fork of Aptoide, which also specialized in Android repository provision, but not specializes in FOSS. Consequently, Aptoide client lacks detailed information about licencing, etc. and the repository provided by Aptoide project contains more than just FOSS project. At the same time, Aptoide seems to be leaning towards meta-level (i.e. provide package provision solution for others to reuse), and thus has more documentation and momentum.

F-Droid on the other hand also includes build system for its packages, albeit simple/limited one (e.g., entire recipe is written in one line).

All in all, it's great that there're such solutions for Android, and pity that that they are relatively hard to find, they should be published more, that will contribute to overall software quality on Android platform.

How it all started: F-Droid Repository Vapourware

Critical review of build systems

2011-03-13T15:01:00.000-07:00

Last time I looked at possible alternatives to OpenEmbedded, I mostly looked at how many packages they support, how many architectures/OSes, and how easy is to add overrides. Of course, OpenEmbedded outperforms any other generally available build system in these respects.

But still, while the idea of grand unified build system is very cool, maybe it would be easier to add/extend support for some non-Linux OS to some other build system? (As OE is targetted at Linux.) Let's see.

GUB
This software tries to steal "grand unified" motto, though so far it has 200+ packages, but supports Windows. Recipes are structured as Python classes, overrides are handled like:

class Ctypes__mingw (Ctypes):

One thing which immediately catches eye is "def patch (self)". Yeah, Python doesn't let people play with curlies, but they'll go out fo their ways with braces. Recipes-classes do allow deal of declarativeness, for example, in specifying patches, and yet there're stuff like:

def patch (self):
self.system ('''
cd %(srcdir)s && patch -p1 < %(patchdir)s/busybox-mkconfigs.patch
''')

Summary: Violates standard codestyle for target language (PEP8), breaks declarative vs imperative metadata separation.

mingw-cross-env
Targets mingw32 (only). Doesn't support DLLs. Uses .mk for recipes. Both recipes and other files (patches, etc.) lie in one flat directory. Recipes look clean, but one target and no sharedlibs is trivial case on its own.

WM8505 (VT8500, WM85xx) hacking timeline

2011-02-27T03:23:00.000-08:00

I've got my hands on cheap WM8505-based Android tablet, figuring out how open to hacking it is, as usual, the information is fragmented and outdated, so I'm going to try and compile timeline:

2010-05-28 Alexey Charkov makes first commit to the tree hosted at http://gitorious.org/linux-on-via-vt8500
2010-06-03 Alexey Charkov registers http://gitorious.org/linux-on-via-vt8500
2010-06-03 Angus Gratton's first blog post on Eken M001, Eken M001 Android tablet review (Pt 1)
2010-06-10 Angus Gratton Notes on porting Android 2.x to Eken M001 Discusses the fact the Android userspace was patched to use libwmtapi.so
2010-06-22 Angus Gratton Eken M001 teardown & serial console Show good internal pictures (in particular, "WM8505" lebel on CPU).
2010-06-13 created topic Kernel source almost available
2010-07-27 Harald Welte released initial packages from VIA, with binary objects for video and SD/MMC drivers
2010-07-28 Angus Gratton's follow-up on inial VIA release
2010-08-01 Angus Gratton created topic WM8505 linux kernel development (for Eken M001 & others).
2010-08-01 https://github.com/projectgus/kernel_wm8505 created
2010-08-06 Alexey Charkov invites Angus Gratton to join forces on clean implementation of wm850x support at http://gitorious.org/linux-on-via-vt8500/vt8500-kernel
2010-08-13 Harald Welte posts about making Android 2.6.29 kernel source available. That tarball actually has C source in drivers/video/wmt .
2010-08-18 Angus Gratton announces (blog) creation of VT8500/WM8505 Linux Kernel Google Group. "Kernel discussion seems to have running in a few different places concurrently, especially between netbook & tablet people."
2010-09-16 Angus Gratton created topic Testing: Custom kernel with cpu frequency scaling/overclock enabled.
2010-11-24 Angus Gratton: Froyo (Android 2.2) alpha for Eken M001 & M003

http://www.bento-linux.org/

git repos:

https://github.com/projectgus/kernel_wm8505 - import and cleanup of original VIA sources, maintained by Angus Gratton
http://gitorious.org/linux-on-via-vt8500 - from-scratch and cleaned up implementation maintained by Alexey Charkov
https://github.com/bushing/android_wm8505 - just a few commits, last 2010-06-03, apparently superseded by other repos

Ubuntu, somebody's favorite Linux-based distribution

2011-02-17T14:40:00.000-08:00

Well, to get into the hype, I've installed Ubuntu 10.10 on new Asus X34F. Here's floating post what tweaks I did to get it into shape.

First note about all those "Herons" and "Lucids". Who said word-based versions are better than number-based? Words are better than numbers when they have meaning, and that's not the case with version numbers. So, as my mind is not going to waste its cycle on remember that stuff for some more time yet, note to myself: 10.10 == Maverick.

-Replace dark-strange-buttons-god-knows-where default theme with Clearlooks. And don't even let me start about wallpaper...
Fix suspend issue due to usb host module (give link to forum)
Make mc stop pretending it's running on 50-years old tty and do Esc key well.
Get bitmap fonts to be available for selection: remove /etc/fonts/conf.d/70-no-bitmaps.conf symlink which rules them out, and instead link 70-force-bitmaps.conf (yes, there's 70-yes-bitmaps.conf, but who wants to check if they'll listen if asked politely, granted that they managed to disable classy fonts at all).
Set nice bitmap font for Gnome Terminal, because you don't want to file your eyes with anti-aliased vector novelties on a color background. We need classical "Fixed" font from X11's package fonts-misc-misc. For reference, one of font files is /usr/share/fonts/X11/misc/10x20.pcf.gz . When selecting this font for console, make sure to try different sizes: there's some weird substitution for some of them - instead of nice-looking sans-serif there's serif popping up. "Fixed 16" what worked here on X34F (same real size is "Fixed 20" on nx9420/Gentoo, probably because of different dpi or something).
Uncommented net/ipv4/ip_forward=1 in /etc/ufw/sysctl.conf
NO FIREWALL AFTER DEFAULT INSTALL?! https://help.ubuntu.com/community/UFW : "By default UFW is enabled but all ports are left open (otherwise there would be no Internet access following installation)." It's only on Ubuntu "not all ports open" means "no Internet access". They've got to learn that ports may be incoming and outgoing. Set incoming to Denied.
Anyway, figured out masquerading. It's a shame it cannot be configured by simple rule and in GUI. It's outdated to think masquerading is only needed for router box, nowadays it's needed to give net access for sart devices, virtual machines, etc. The problem I had was that even after setting up masquerading per Ubuntu guide, I couldn't ping google. Well, the VM used physical Ubuntu box as DNS, so I had to add rule to enable incoming port 53.

TODO:

Where's my hibernate?

Xara Open Source - Sleeping Beauty

2011-02-15T18:59:00.000-08:00

You just can't imagine what fairytale may in the industry, while you just do common things like hacking, building, and debugging... Anyway, as any fairytale, it started long time ago. I first saw a demo of Xara Studio when CPUs were 100MHz and Windows just turned 95. Don't hold your breath - software was better those days, but not really magic, so you've got to recognize and remember when you see a miracle. Xara, a vector graphics editor, was exactly such miracle. CorelDRAW the Third was king of the hill those times, which ruled without inspiration, though did its job. Well, Xara brought real fresh spirit into the area of graphics design - not only it brought anti-aliasing support, it was also real-time. And the were streamlined and logical UI and set of advanced graphics tools, like blending - also realtime.

So, Xara showed that you can do great software if you like, to stand out of the crowd and make a difference. I remember it since then. And today I found out that Xara was open-sourced! "They must be crazy to have done that" - was first thought which occured to me when I saw the site. But this is fairytale, remember, and evil sourcerers must have kept me in parallel world - it turned that happened long ago, the first wave of commercial companies opening up their projects, and it had been dead few years by now, and epithaph written. So, they weren't mad after all, they didn't open up their low-level graphics lib which on 100MHz behaved better than Adobe Flash on 4-core 2GHz CPU does now. And community guys were too lazy to port it to multitude of other graphics engines, so project dead.

But what amazes me is that open-source site is up and nicely running, docs are there, etc. just timestamps are old. And mailing lists are quiet. And the temple is full of ancient scrolls suggesting checking if SVN works by telneting to a port. Hush, this is fairytale. It's all working, it's not dead, it's sleeping. Sleeping Beauty.

So, apparently, as site is running smooth, the company apparently does well. I checked Wikipedia - they do, and keep amaze their users (content-based bitmap resizing is what I saw with a corner of my eye). I don't know how to treat this case. I can't say "better they wouldn't open up it". I can't say "they must have opened up their gfx lib". It's not the case that everything should be opened up, and such applied software as Xara clearly should bring its owners a direct value. So, I better be amazed by Xara and its creators for the second time, it's nice to know they tried. Not only they tried - they did it. I installed it on Ubuntu and it looks and works great, even though it's not maintained much any longer (well, there's Ununtu developers' merit to that too).

What amazed me is that, even though I tried, I found no attempts to resurrect it. Well, I found this, but it didn't get much beyond changing a preference dir name. It also used some ancient systems like SVN and imported some history-less archives. Well-well. I'm finishing git svn clone now, to push to gitorious, for git be more comfortable bed for the sleep...

https://gitorious.org/xaralx

Hacking Osram NightLux

2011-02-06T04:20:00.001-08:00

Ok, this blog had "DIY" included on reload, so here's a bit of it. (By "DIY" I mean hardwarish hacking, real-world directed mostly.)

For smarthoming purposes, I wanted to stick around my apartment LED motion-activated lights. Because it sucks to push the buttons of course. My requirements were: 1) LED; 2) motion-activated; 3) light-activated (works only at night); 4) thresholds adjustable; 5) battery-powered, so worked on power outages; 6) actually, accumulator-powered with builtin charger for technology to serve me, not me serving technology. Alas, as usual, it's "choose 2 of 3" thing. The best I could find were Osram's NightLux and SpyLux. The first one is floodlight-like, the second is flashlight-like. Well, they don't have builtin charger and - worst - don't have adjust knobs! The only control they have is off-10s delay-60s delay-always on.

And the light sensor threshold is actually pretty high - not facing a window, it starts to light just on cloudy weather. So, I went inside to see if knobs are there - no. What a shame for otherwise great product! But I found that light sensor actually looks into plastic covers, only slightly lighted by nearby PIR window. So, the hack for 1st NightLux was purely mechanical - I cut with my Dremel-like plastic inside which shadowed sensor. It helped. But I had to put it near the ceiling directly facing the bulb, because when it hanged on a fridge it still turned on couple of times until eco-bulb warmed up.

Well, I want to put the 2nd one in the hallway, where there's no direct window light at all. I could try drilling cover and exposing sensor, but have doubts such bad aesthetics would still help. So, I've set for real hardware hack this time, even if risking to brick it. The idea is to identify type of light sensor (photo-diod, photo-transistor, etc.) and resistor which passes current from it, then use old trick to either gently file it to increase resistance, or short-circuit with something to decrease.

I looked at the board more closely - it has small chip, marked M7616. Well, I am lucky, it's not custom one, datasheets are available.

(to be continued)

Links for February 2011

2011-02-02T08:40:00.000-08:00

http://notioninkhacks.com/ - Portal and forum

Links for January 2011

2011-01-31T18:00:00.000-08:00

mbed.org - Kind of Arduino for NXP microcontrollers. There are interesting algos, like JTAG Search.
nookdevs.com - Hacking B&N Nook eReaders. For example, NookColor Hardware specs.
novaports.org - Another embedded/Android/Nook hacking portal, features destructive teardown.
http://wiki.osdev.org/ - OS Development Encyc
Open Source J2ME software

And the winner is...

2011-01-21T11:52:00.000-08:00

After problem with MSI X430 described in earlier post, I kept shopping. There were few interesting contenders. By chance I saw in the shop a ViewSonic ViewBook Pro VNB131. I didn't even consider a ViewSonic to be a company to consider notebooks from, but they keep providing surprises. The screen immediately catches attention - it's truly bright and vivid, unlikely washed-out generation of current inexpensive notebook screens. And in around 1.6kg they managed to cramp even easily-replaceable DVD. Which is a brilliant ... drawback, in the same way as big battery in notebook is ;-). DVD in my nx9420 is amost dead now, hardly reading every 5th disk I put into it (which is rare nowadays).

Well, anyway, VNB131 is outstanding device (they even promise all-aluminum frame), exactly of that type that you notice, keep in mind, and when finally you want to get one few months later - oops, it's no longer around. The reason I skipped it was that I got idea of L335 performance, and looked up Core2 ULV (used in VNB131) performance - it turned out it's not much better than 5-year old Toshiba M200 which I have. As I got idea taht i won't get anything decent for $500, I decided to shell out more, but get something noticeably powerful than even nx9420.

And the winnder was Asus X34F, which just recently got into stock around. X34F is a strange device, there was no info about it on Asus site. No reviews on the net. Googling just gave lot of pricelist hits clustered for some locality, giving good, though sometimes controversial specs. After extensive research, it turned out it's a U35F spinoff for these localities. Afre finally spotting an instance in a physical shop, I've ordered it and it seems everything is right with it. Funny thing, scrolling with touchpad again doesn't work with Ubuntu 10.10 (device otherwise sells with just FreeDOS). But I have high hopes and trust Asus not to stick films advertising 2-finger scroll on an unsupporting touchpad. Just Linux driver needs upgrade or maybe hacking. After all, I already fixed (thanks to forums) hang-on-suspend issue which at first occured.

Samba and iptables UDP broadcast issues

2011-01-14T22:06:00.000-08:00

Have been having issues with browsing Samba from Windows boxes or vice-versa for years, like me? No wonder - just google for "ip_conntrack_netbios_ns site:samba.org". See? It's not documented or even mentioned that that kernel module must be loaded for NetBIOS broadcasts to get thru firewall, except for one recent post, even though the issue was raised and solved 5 years ago: https://bugzilla.redhat.com/show_bug.cgi?id=113918 .

Notebook MSI X430 (aka X420 aka X410) - Big Disappointment

2011-01-05T08:38:00.000-08:00

So, I've been shopping for notebook for some time - my current work model, HP Compaq nx9420, has been failing me for like 1.5yrs now, with its lid hanging on just one corner (the steel support plate in there broke, nice job, HP!). I also grew pretty tired to carry it's 3.3kg around, so was shopping for subnotebook. So, criteria was: minimal weight, workable screen size (12" is kinda small, 14" is kinda heavy, those are extreme bounds), budget price (also tired to shell out a grand+, especially that nx9420 shows that no matter how much you pay, you have strong chance to get budget quality nowadays).

I had Acer Timeline t3810 (or something close) in my shopping list, but was swamped by real world, so when I came closer to actual shopping - oops, that model is no longer available. That's another trait of modern hardware market - it's not like good stuff gradually becomes cheaper and better stuff comes in, it's like good stuff being replaced by more expensive and mediocre one.

So, I started looking for another replacement, and I found MSI X430. Gosh, it was brilliant. They cramped 14" in 1.5kg - there was/is no competitor in that regard. Battery life was crap (~2hrs), but that's actually brilliant engineering thought. Because laptop battery doesn't last "X or Y hours", it lasts untill next hot summer - when it completely dies. So, it makes little sense to pay lot for large battery which will anyway die soon. So, thanks to that nice crappy battery, X430 costed just $500 (my ideal upper bound for a contemporary piece of technical stuff), it made decent weight to of course. The performance wasn't great, but at least it had latest AMD X2 which has come to these vicinities, L335.

Guess what - when I started to actually call shops, it turned out the model went out of stock like a week ago. Yes, it was on hot sale the whole summer, and boom, suddenly there's only X410 & X420 which are less performance and/or much more pricey. Well, I waited a bit, and oh, miracle - one shop got it back.

Got it in a day, just to find out that:

Max amount of memory ambgiously (not explicitly) mentioned in the docs is 2Gb. Come on, this is not netbook, which 2Gb?? And it doesn't have dedicated RAM cover to easily try 4Gb module - would need to disassemble it completely (either void warranty or go to service center - with what - 4Gb SODIMM I purchased not knowing if it works or not?)
Booted Ubuntu 10.10. Got complete mess on the screen, more specifically torn off signal sync. Remember how old CRT TVs looked with broken row sync heterodyne? I couldn't even imagine that effect can be so faithfully reproduced on LCD panel! I was able to found just single report of someone else facing that, did some hacking, found a workaround, and then thanks to DRM driver people found easy solution. So, well, that DRM/Ubuntu issue, though, taking into account all points above and below, MSI engineers outwitted themselves too. (Support for such funky videoadapeters, as in X430, will be (was) fixed in next kernel version).
One final point which really put me over the edge and made me return the thing. Its touchpad doesn't support scrolling. Well, to be exact, it does, in a following manner: you have to tap at top right corner to scroll up, somewhere near bottom right corner to scroll down. So yes, you had to target the tap, and target pretty carefully, requiring an eye-look. How that compares with familiar blind swipe near the right side? If that sounds like a petty complaint, you've got to use that yourself! Remember, I started all ecstatic about the box, and that dissatisfaction grew subconscious ways. It's like making you walk on the knees. Many people would say "So what? Connect any mouse you like, voila!" Well, but I'm buying a subnote to be light and lean and not carry extra stuff, and still being able to use it comfortably. If to start bringing around crutches everywhere, why bother with lack of selection, higher price, lower performance of subnote? Well, I started to drop into any notebook shop I saw in city motion and know what - all notebooks out there have sane touchpad scrolling, newer ones brag about multi-touch (2-finger) scrolling with stickers, couple of MSI models were the only ones with such brain-dead scrolling. I finally made a search over the Internet. And found dozen-of-pages hate-topics regarding MSI's touchpads. People go by any length to do something with them, like soldering out that thing and solder in normal touchpad.

So, the last issue and discoveries regarding it really freaked me out. What vendor's attitude could be regarding putting unusable and disturbing human interaction hardware into otherwise noticeable models (again, not all MSI notebooks are affected, it seems that subnotes are primary target). The most realistic would be "models are cheap, hence cheap hardware". But that's some $5, really, and that difference makes the computer unusable! So, simple answers don't cut. The must be some conspiracy theory. Like, MSI bought those broken touchpads in millions for $0.5 each, and puts them out to clear stock, wildly ignoring user complaints. Or MSI was bribed by touchpad vendor. Or that they have attitude like "We make few cool points, so no matter what other crap we put there, you'll buy it".

No, I will not. I'm not keen on returning stuff, but that box went back to the shop. And I even wrote this blog post ;^).

Mercurial goes down in my list comparing to git

2010-12-29T08:08:00.000-08:00

For a long time a valued Merurial not less, if not more, than git. Well, until I started to use it for more than just local tracking of files.

So, you have working copy changes, do hg pull/update which conflicts with them. You're told:

use 'hg resolve' to retry unresolved file merges

So you edit the file to resolve conflicts, then run

hg resolve hg.txt

Right? No, because you get very strange output:


merging foo.txt
warning: conflicts during merge.
merging foo.txt failed!

And see that all your careful edits are blown away and file is back to conflicted state. Now you read man, to find out that you need to use -m option to mark file as resolved.

The question is: how can someone design such a UI that not only requires additional option for the most common operation, but also by default silently clobber users changes, which may be result of an hour or so of work? They say that git's interface is not that good (I used to think that too). Just look around.

Some WinCE links

2010-12-16T04:10:00.000-08:00

Enlightment on WinCE
Qt/KDE on WInCE - includes notes on CAB packaging using pocketpc-cab script and lcab
Windows CE .NET Advanced Memory Management (CE 3.0/4.x)
Windows Mobile 6.1 Memory Management Changes (CE 5.x)
Windows Embedded CE 6.0 Advanced Memory Management

WebKitGtk vs QtWebKit

2010-12-04T11:20:00.000-08:00

Comparing functionality and features of Qt (QtWebKit) and GTK+ (WebKitGtk) ports of WebKit.

Scrolling Performance

It seems that as of 1.2.5, WebKitGtk has one fairly big usability issue comparing to QtWebKit: it has very slow (and high CPU usage) scrolling on some pages/sites. All browsers based on WebKitGit are slow on those pages, while all browsers based on QtWebKit are OK there, so that's indeed a framework issue.

Midori FAQ has an entry on this ("Scrolling on website xyz is very slow").

It turns out that this can be result of multiple bugs:

[Cairo] Enhance the performance of shadowed elements by tiling the shadow area - biggest contributor apparently
[Cairo] Font fallback determination is very ineffecient

WebKitGtk 1.3.7 status: Seems to be mostly fixed, all pages from below show good scrolling performance, though ones with image backgrounds show not as smooth scrolling (but that's yet another issue).

Examples:

http://www.cmlenz.net/archives/2008/03/python-httplib-performance-problems: glorious example - scrolls well in the post body, but as soon as reaches table of comments, it's a crawl if not a hang.
http://careers.stackoverflow.com/Jobs/7000/stack-overflow-developer-stack-overflow: entire page scrolls bad (note: most StackOverflow pages are not affected).
http://forums.urbanterror.info/topic/22445-intel-gma-hd-performance-gma5700mhd/
http://techfreaks4u.com/blog/?p=1021: just degraded scrolling performance.
Login to Twitter, go to http://twitter.com/#!/search/#linux

http://blogs.igalia.com/alex/2010/09/17/rendering-shadows-and-tiles/
https://bbs.archlinux.org/viewtopic.php?pid=860692

Image Scaling Quality

On the other hand, when scaling images, QtWebKit 4.6.3 appears to (by default?) use nearest neighbour filter, while WebKitGtk uses smooth bilinear filter. In Qt 4.7.1 it's the same.

But it seems to be fixed in the latest QtWebKit, this post tells:

[01 Sep 2010] Re: no interpolation after scale image to a larger size?

This was fixed here:
[Qt] Enable smooth pixmap transforms by default

The change was too late for Qt 4.7 but will be part of the upcoming
QtWebKit 2.1 release.

As of now, QtWebKit 2.1 is still not released.

Btw, according to the patch, nearest-neigh filter is used exactly by default, it can be changed by client. Need to try that in Arora. - Well, not in Qt 4.6.3, there GraphicsContext::setImageInterpolationQuality() is empty.

Bash Braindeadness: Logical Connectives

2010-12-02T17:20:00.000-08:00

UPDATE: As was pointed out on Ubuntuforums, "true -a false" on its own is running command "true" with parameters "-a" and "false", and "true" deliberately silently ignores its arguments. So again, "-a" & "-o" have logical connective semantics only as arguments to test/[. The below is stylistic feature ;-).

So I've been debugging a shellscript which didn't do what it should have been (not mine). Everyone likes using kewl idioms, so there was:


check val1 -a check val2 && do_something

Well, just gotta choose right language. Because in bash:


$ false -a false; echo $?
1
$ false -a true; echo $?
1
$ true -a false; echo $?
0
$ true -a true; echo $?
0

Wanna more? Easily:

 $ false -o false; echo $?
1
$ false -o true; echo $?
1
$ true -o false; echo $?
0
$ true -o true; echo $?
0

So, from looks of these examples, in bash, both logical AND and OR have the same truth table, and semantics of "return first argument". Now, wazzup?

Googling surprisingly doesn't give good hits - obviously, because you have troubles searching for "-a", "-o", "and" or "or". Googling for "logical and in bash" gives one good hit on 1st page - http://ubuntuforums.org/showthread.php?t=754338. There, some guy wonders why both [ 0 -a 0 ] and [ 0 -a 1 ] are true, but not really being answered.

So, by reading man bash a really careful reader may notice that -a and -o (in a sense of binary logical connectives) are defined within description of test aka [ command. The description also says "Expressions are composed of the primaries described above under CONDITIONAL EXPRESSIONS." And CONDITIONAL EXPRESSIONS list only checks like -a and comparisons, and no thing like shell commands, integer or string literals, etc. So, careful deductive reader might pose hypothesis:

Logical -a, -o are defined only within scope of test aka [ command. And there, they must apply only to legitime boolean expressions - checks and comparisons. Usage of -a, -o in any other context silently produces undefined result.

Of course, any decent language would give error if some operator is used in wrong context. But Unix shell in general, and Bash in particular, have always been special. So, be it historically preserved bug, or GNU Bash own invention, the end result is the same - you don't need the Brainfuck language or other alike novelties to have some fun - with bash, you can get unexpected results right at your fingertips, at any Linux workstaion around the world.

USB gives a lesson in physics

2010-12-02T14:30:00.000-08:00

With a recently bought mouse:

 [176149.256699] hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
[176149.256706] hub 3-0:1.0: over-current change on port 1
[176149.357643] usb 3-1: USB disconnect, address 3
[176149.569692] usb 3-1: new low speed USB device using uhci_hcd and address 4
[176149.734362] usb 3-1: New USB device found, idVendor=093a, idProduct=2510
[176149.734371] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[176149.734377] usb 3-1: Product: USB OPTICAL MOUSE

Googling shows affected are many, yet few good explanations are provided. This good post explains that it is indeed caused by an electrostatic discharge (ESD), which, kernel can be agreed with, may be seen as an extreme case of electo-magnetic interference (EMI).

Quest for Ultimate Browser

2010-11-18T11:55:00.000-08:00

Web browsing in one or another form is probably the largest share of activity performed on computers today. And yet it's far from being perfect or even largely comfortable. Actually, it wasn't like that all the time. Back in old good days, you can browse web equally comfortable with both Netscape Navigator 2 and Lynx. But the more advanced web standards become, the more dynamic and media-rich web sites become, the more overall browsing performance and comfort deteriorate. Note that I don't talk here about how sites look or how well they represent information - there's big progress in that no doubt. The talk is about how well browsing of hundreds and thousands of such cool sites is managed. There're two biggest problems with modern browsing: performance and stability.
[...]

Midori (0.2.9):

All windows block if there's a JS modal dialog
Has a setting to not load/render pages from restored session on restart, just show placeholders. - I miss this much in Arora.
Session recorded just for one (main) window. Tabs opened in other windows are lost over restart/crash. This is show-stopper bug, made me use Arora as a promary browser instead.

Arora (0.11):

Always puts a new tab as the last, no setting for that.
Show KBs downloaded for the page.
After some usage it turned out that session management is not robust: after the crash, I regularly get situation that windows and tabs are "restored" in the same numbers they were before, but each tab opens file://$HOME (yes, the local home dir). Or, Arora just forgets that it should restore session and shows its home page.

VI-like galore: dwb, jumanji, surf, uzbl (still review more), luakit

Floating Posts

2010-11-15T01:06:00.000-08:00

I'm going to maintain some "research" topics (posts) which are updated over time. Date of such topics may be reset to the current from time to time. Such topics are tagged as "floating".

Blog reloaded

2010-11-14T01:53:00.000-08:00

It seems that I need a blog, after all. There're so many interesting things around... And some of them I even do/tackle myself, so I don't want to forget what/how I did that while moving to other interesting things. I could write private notes, but I learn lot of interesting things by just reading the Internet and blogs in particular. But not all - again, some stuff I need to research in-depth or make myself. Then, I'd like to share it back.

I was thinking for some time if I should make a new blog or continue this one. But after re-reading old posts, now I'm sure I don't want to leave this little blog orphaned ;-).

The only issue, is that this blog was started as dedicated to Embedded Linux, and may be included in some thematic feed aggregators/blog planets. I still hope to write about Embedded Linux, but going to extend scope to other topics. It's still going to be IT- and technology-centered. So, if you're a planet admin and think that new format doesn't fit your resource, feel free to remove it. If you're a reader which started to get posts on unexpected topics, feel free to report to you aggregation service. (Either way, feel free to drop me a line too.)

Weekend project: porting a game to QVGA

2008-01-13T13:44:00.000-08:00

Following a mediaplayer, games would be next thing people ask for Angstrom. So, I decided to look what would be good candidates to add to feed. There're bunch of different games' recipes in OE, but I was thinking about some catchy, dynamic arcade. Of course, SuperTux came to mind! ;-)

OE already has recipe for SuperTux, and quick try in QEMU showed it works. In VGA mode. Attempt to run with QVGA screen resulted only in error that suitable video mode cannot be found. So, I decided to see if quick hack could solve this, and then document what it would take to do so.

Quick look at the source code showed that it is one of the critical cases of software engineering - 640x480 resolution is deadly hardcoded, with numeric coordinates spread around the code. Fortunately, short after I spent 10 mins figuring where to stuff divisions by 2, I googled for "supertux qvga". Hits followed! SuperTux was ported to GP2X and even to WinCE. I took GP2X version to look at.

GP2X port is nice produce of folks who have motivation to do something, but don't know what the diff is ;-). It was also done against SuperTux 0.1.3, while OE had 0.1.2. On the way, I bumped OE's version to 0.1.3 too, while finding that fixed-point patch for 0.1.2 no longer applies to 0.1.3 (will need to rediff). Finally, making diff out of GP2X version and cutting off changes related to autoconf-generated files, I got ~70K patch implementing --enable-320x240 and --enable-gp2x options (adding those was neat, unlike not producing a diff). Applying that patch on top of pristine 0.1.3 (with bitbake recipe of course!) and cleaning off some sloppy gp2x changes which were compiled in even though --enable-gp2x was not given, I finally got the package built. Quickly checking that it doesn't work in 240x320 mode, I had it run with xrandr applied, just to see garbaged fonts and graphics. Of course! Of course gp2x patch doesn't resize the original graphics on the fly, but expects it to be downscaled already, even though such gfx is not included in source archive. I pulled it from binary package though, and few minutes later saw the expected fun:

So, thank you scachi (Ingo Arndt) for doing all the fun work, and leaving dirty work of cleaning it all up to me! ;-D

On that route I proceeded, and next task was figuring out what to do with graphics. Having a binary drop of graphics was for sure no more acceptable than a complete source archive instead of diff. We talk port here, not something. I still don't target that at upstream, but not because it's not worth being there, but because it would be hard to explain what's it all about to people who write draw(537, 39) ;-(. Nonetheless, QVGA graphics must be produced from upstream version during build time. Just few days before I heard pH5 talking about imagemagick-native, so having checked it was not in OE (while target version was), I caught him on IRC to find out that it belongs to "would be nice to have" category. 15mins later it was there, fortunately "inherit native" was all needed for it.

My initial attempts at resizing original SuperTux graphics at 50% proved to give rather bad results, having size as big as original, or even bigger, and for sure much bigger than gp2x versions. But man'ing thru and recalling my old ImageMagick experience quickly gave its fruit by applying adequate color quantization after resize (I used --colors 64). Adding pngcrush-native and running magick's images thru it was final touch - in the end, I got image set ~30% smaller than gp2x's, while still looking better!

What's next? Too big a package. It would be nice to let people install this thing to flash, plus I target it for inclusion in LiveRamdisks, so 6.5Mb compressed package was not very bright. Glancing over data files shipped with SuperTux, it turned that music/ is nice candidate for slimming. First of all, there're few duplicate tunes, just one copy with "fast" suffix. Size was same, and diffing them, there were handful byte changed. Looking thru code, "fast" version is played when level's time limit is running out. I llluv that feature! But not at the expense of my flash ;-I. "fast" version went to /dev/null for the QVGA, and now, small-size version. Secondly, there was a credit.ogg file, which gp2x port replaced with some .xm. Trying .ogg still, I found that SDL can't scroll screen and play 160kbit ogg at the same time, on PXA 400MHz. So, bye, .ogg, good riddance! And thanks gp2x again for offering a replacement.

Now I finally decided to run game on full-fledged hardware - h4000, as earlier I ran it in QEMU and on h3900, which lacks audio. It immediately crashed on startup, complaining about not being bale to load a .mod music. A check of source, then libsdl-mixer recipe and - the latter has mikmod support disabled. Poor. With it on, I finally have a nice, commercial-grade arcade running on a Linux PDA! I even was able to quickly finish couple of levels, even though controlling PDA in a landscape position is not ideal.

Final touch I made was extracting bonus levels to separate packages. Level description are text files, taking more than a megabyte in raw size, but packages turned out to be ~50K. Well, let's save space for ext2 people nonetheless, and most importantly, have a complete experience of what it takes to produce a nice PDA port of a game.

So, that's how it was. I took time to write this long, if not detailed, description, in the hope that it will both motivate people to port games to OE/Angstrom, and will give hints how to do that. So, let's hope that people will care for their favorite OpenSource games, or choose to have such a weekend fun ;-). Otherwise, thinking about it, games are likely the best candidates for bounty-sponsored porting - after all, due to the manner many games are written, it's not too easy to port them to a lower resolution/smaller size/more CPU efficiency. So, if people want more fun, they should take the fun of doing a port (it's much more fun than playing a game itself, trust me ;-D ), or motivate other people who want to do that ;-).

Oh, and back to tux the super: the supertux-qvga recipe should land soon in OE. I hope to dump packages to unstable feed too. Then, there're following TODOs before it's perfect:

Forward-port fixed-point patch to 0.1.3 (I get ~25fps with sound, and that's not too much, and there's jerky scrolling sometimes).
There're few relatively big .mod's which are used relatively rarely. It would be nice to leave just a couple of smaller ones in a core package, to really slim it down, and put the rest in extra-music package.
Fully clean up gp2x patch, it's still too dirty.

info reg, for a ducat, info reg!

2008-01-06T12:57:00.000-08:00

Back in my childhood I was severely traumatized by debugging experience with Turbo Debugger 1.0. I mean, it was so nice, so perfect tool that I barely can use any other debugger with comfort since that. That's why I usually shrug on pushing different kind of "developer GUIs" - if it's good, it can be only worse on the large scale, as you won't be able to use more mediocre tools after that ;-).

GDB is one of the worst debugger UIs in this respect - debugging oftentimes requires thousands of repetitive simple actions, and if for step in/step over you need more then one keypress and need to press anything at all just to see the code/registers, it is a great chore. Nonetheless, having accepted that it's the baseline we have everywhere, and noone (including me) could write a decent frontend for it, I humbly condition me to use it, the same way as I did long ago for vi. And that's why I write - I still can't remember a command to dump registers. Maybe it's "show registers"? Or "dump registers"? Maybe "print registers" or - crazy - "data registers"? No, it's "info registers"! Whoa!

Smallscreen mod for GtkFileChooser

2008-01-05T19:22:00.000-08:00

OpenEmbedded have had smallscreen patch for GtkFileSelection widget for quite some time now, but unfortunately it doesn't affect usability of the most software, simply because many programs now use GtkFileChooser widget instead. GTK+ 2.12 manual also following about the matter: "GtkFileSelection has been superseded by the newer GtkFileChooser family of widgets."

Let's look how standard GtkFileChooserDialog looks on QVGA portrait device (240x320):

Note that "Places" pane on left cannot be shrinked beyond the size shown, which doesn't leave room for any useful display of filenames, so the dialog is clearly unusable.

So, I've took time to patch GTK+ 2.10.14 (this is the version used by Angstrom 2007.12, and my primary focus is to improve its usability on the supported devices) to make the widget be more PDA-friendly. I started with "data-driven" changes (meaning changing numbers and strings, but note code constructs):

Reduced Gnome Human Interface Guidelines mandated spacing and borders of 6 and 12 pixels to 2. It's nice to have standards (even though Gnome doesn't offer us opportunity to choose from ;-) ), but on small screens, there's simply not enough space to spend pixel-wealth on gaps.
Removed labels from Places pane's buttons, leaving only icons.
Made Places pane shrinkable.

Even these changes made big difference, but stopping there would be to leave the dialog in barely usable state, and I'm really hope for a Linux GUI environment which is comfortable to use.

So, adaptive relayout was required, based on "PDA" mode being active. I first started with defining PDA mode as being portrait screen orientation, but thinking further, the problem, at least for GtkFileChooser, can be defined as follows: there's just too little of horizontal space available, and there should be efforts applied to use it to show as much of user's filenames' length as possible. Based on this note, PDA mode was defined as having a screen width below some threshold. This threshold was set as absolute value, but is not really arbitrary, and tied to real-world available screen sizes. I found that standard dialog looks pretty well in VGA landscape orientation, but still leaves too little space for filenames
in portrait orientation. So, threshold was set to 490 (to account for fudge factor ;-) ).

Now, with the above note on horizontal space scarcity, and keeping in mind that screen area at all is scarce, for vertical space should be saved too, following dynamic layout changes are done to dialog when being in PDA mode (i.e. run on the screen <490 pixels width):

Vertical split pane is used for Places vs Filelist
Buttons are packed to the left instead of bottom of Places
Actually, only "Add" button was left, as "Remove" action can be easily accessed from Places list context menu, and most importantly, intuitively can be expected there. ("Add to shortcuts" choice is available for context menu on Filelist items, but who'd look for it there, without knowing it is?). This allows for more visually pleasing layout when Places pane is minimized.
Dialog itself is sized to take all available width (originally, GTK+ sizes it to take no more than 3/4 of screen width, if possible, or packed requested size otherwise).

All in all, that's how the dialog looks now:

A refreshing change, with pretty long filenames being easily visible.

I've tested the patch pretty well, plus code changes are pretty small, so I intend to commit it to OE soon, and RFC its addition to Angstrom stable branch after it gets more review and testing.

There're still few things to consider and do to make it even more usable on small, PDA-like screens:

Catch and process screen geometry change events - I'm pretty sure this is not done by GTK+ currently, and on dynamic screen device like PDA could make parts of dialog go offscreen when switching from landscape to portrait and vice-versa.
Possibly, adjust screen width threshold based on more testing (original value was based on review of big-gaps dialogs, maybe smaller gaps affect that).
Alternatively, gaps can be calculated on the fly, so original Gnome HIG-mandated values would be used on big screens, and small values only in PDA mode.
Default "File system" choice in Places is superflous, it can be accessed with the icon from the path buttons at the top of dialogs. Unfortunately, screenshots above have it scrolled away. And having "File system" is Places causes exactly same problem: it takes space and calls for scrolling, so we'd better skip it there altogether, letting user to access own choices easier.
Think about dialog height. Currently, as seen from above screenshot, it leaves bunch of screen area unused, and (apparently) due to Matchbox window management constraints, it cannot be resized by user. We could fit 1-2 more filenames if sized the dialog near-fullscreen. But that would look OK for QVGA, but already artificial for VGA.

Finally, it would be fun to have a look at GTK+ 2.12. As they say, it has stuff contributed by Nokia based on N770/N800 work, so I keep my fingers crossed that I didn't do monkey's job! ;-) Nonetheless, the focus is current Angstrom release, as I wrote above.

Real C#/Java support in OE

2007-12-29T09:22:00.000-08:00

I finally found time to read Cliff Brake's excellent article summarizing his work on adding realy-working C#/.NET support to OE. Well written, it gives info why C# is useful choice for embedded systems, compares it to C and Python (great choices!) and details how to use it in OE. What of course would be *really* interesting to know is bug/feature (in the sense of performance, memory/disk footprint, compatibility with existing standards, etc.) comparison of current open-source C# and Java implementations, to be able to make choice for some new, independent project. Well, that's not going to be that easy so far.

One point where .NET has win over Java is "by default" portability/device coverage. It's pretty to write simple applications which run both on full-fledged .NET and CompactFramework, which means it's easy to develop small utils on desktop, and have them run without extensive debugging on PocketPC device. Back in the days I still bothered with trying to make PocketPC do what I need, that was a big win! Example of real-worldly usable app written in such way is here. Of course, back then, it was very hard to get full benefit of that opportunity, due to the way vendor provided toolset for .NET development - overloaded with GUIs and unimportant features, it possibly helped someone with a good favorite editor, but made integration work a great chore. Reading thru Cliff's article, one may once again rejoice that we have OpenEmbedded, which handles task of integrating 3rd-party dependencies into the project and complete deployable solution a breeze.

Returning back to Java, we are going to have fresh Java support too, thanks to the work of
Robert Schuster. Hope it will land soon in OE mainline, so the application developers/integrators for Angstrom, OpenMoko, etc. will have unprecedented choice of tools available at their fingertips!

Angstrom 2007RC1 is here!

2007-12-16T07:25:00.000-08:00

Yesterday, Angstrom 2007 Release Candidate 1 was tagged in OpenEmbedded repository and corresponding images where built using autobuilder and uploaded to the autobuild area. They are waiting for machine mentors to test them and move to public download area. The latter was cleared from the older snapshots, and there even small FUD started among the users, so I've posted a small announcement to describe release-time order of things. That said, mentors are acting slow, with only your humble servant have moved h3900, h4000, and hx4700 images to there final location.

A word about versioning - as was announced, final release will be dubbed 2007.12, while RC go as 2007.11.

There're more exciting things to come, at least in PocketPC/WindowsMobile area - RFC was posted on very easy installation procedure for novice users, and that's in addition to LiveRamdisks, of course.

How to find out if USB mobile phone data cable is based on PL2303

2007-12-16T07:13:00.000-08:00

Recently, I hunted for a PL2302-based USB-Serial cable to make a generic serial cable for NAS hacking. Of course, it's not easy to figure out on what based some cable sold in a small shop next door. During my searches, I even found that phone vendors have gone so bold that include PL2302 right into the phone, and sell passive cables ;-\. In the end, I bought a cable with transparent casing thru which I could clearly see what chip is there ;-). But based on the packaging of this one and other packages I saw, I could make following generalizations for future searches:

If instructions on package mention Prolific (PL2302 vendor) site for future driver upgrades, that's good sign ;-)
If it mentions using SER9PL.INF for Windows driver install, that's also likely it.

Disclaimer: This post is just a note for myself. If you read it and then buy, for example, a cable in package which doesn't correspond to the content, don't blame me ;-D.

More Angstrom LiveRamdisks

2007-09-29T14:04:00.000-07:00

Last week, I spent some time to elaborate and automate LiveRamdisks production with the aim to mass-produce them from now on. Taking into account previous agreement with Angstrom maintainers to host them at the main Angstrom download area, this means that eventually there will be a user-friendly way to try a recent Angstrom snapshot on any supported PocketPC/WindowsMobile device.

With these new scripts, Angstrom x11 LiveRamdisks for the following devices were generated and uploaded:

h2200
h3900
h4000
h5000
hx4700

For h4000 and hx4700, also OPIE LiveRamdisks were uploaded.

Current problem with this is that uploading images in different formats (and LiveRamdisk is just another such format of course) means trafficking the same data over the net again and again, and I don't have such a big pipe. So, instead, I created a set of image conversion tools which would allow to upload master image format (apparently, tar.bz2) and convert it to other formats and make LiveRamdisk out of it right on the Angstrom hosting service

Right now, I'm building current Angstrom snapshosts, and going to try these tools on them...

Back from hiatus

2007-09-07T09:43:00.000-07:00

Having spent August on vacation and later working with my GSoC student, Maria Zabolotnaya, I now gradually come back to speed on embedded stuff, even though I likely won't have as much time to work on this as before.

The first aim is to get OE build again, which is "of course" broken after being away for some time and then coming back ;-). Then, process all the backlog of HH.org kernel patches and cleanup tasks. Further aims will be to automate process as much as possible (for example, I finally want to setup local Continuous Integration for OE builds, like I did for HH.org kernel), and upgrade HH.org kernel to 2.6.22 (though to that time 2.6.23 likely will be out).

Finally out of the list of pressing OE issues

2007-07-25T18:35:00.000-07:00

With the last changes to properly support modprobe 2.6 for kernel module configuration directive, I can't remember other pressing issues with OE which would prevent its proper and flexible usage for distro engineering. Among the other infrastructure changes done within the last half-year with I was involved are:

Support for building efficient initrd/initramfs images
Flexible and extensible initramfs to boot rootfs from different media
Adding support for machine screen properties
Image building speed improvements
Alleviating maintenance effort for kernel porting projects with lots of supported devices (using defconfigman)

With all these and other changes, era of grunt work on OE should be over, and finally more effort can be dedicated to more sensible work - Angstrom distro engineering and software/package porting and maintenance.

Modular initramfs for OE

2007-07-19T14:38:00.000-07:00

While all new initramfs-related features are yet need to be described, they are already put to work. Alex Osborne of Hack'n'Dev created a modular initramfs system to serve all the device booting needs. We discussed design principles and came to following tentative picture:

initramfs in question handles just the task of mounting rootfs and booting from it.
Doing so, it tries to follow both existing kernel behavior and interface, like command line parameters. For example, NFS boot uses standard root=/dev/nfs and nfsroot= parameters. Where extended feature is added, it tries to mimic existing parameters. For example, loop device boot uses root=/dev/loop and looproot=.
Support for different boot methods is implemented by modules with more or less well defined interface. It's possible to construct initramfs images with the given feature by combining modules.
Generally, new and extra features are expected to be added using modules, to keep design clean.

It is committed by now. Both loop and NFS boot modules are tested to work. I hope that Alex will describe loop module command line syntax in more detail in his blog.

WANTED: modules to boot via WiFi, with WEP and WAP support, and to boot via GPRS ;-D

Initrd and initramfs with OE: snippet 1

2007-07-19T07:55:00.000-07:00

One of the former weak areas of OpenEmbedded was creation of small, fine-tuned, (hand)optimized initrd and initramfs images. However, during few last months, the situation vastly improved, and by now OE offers all tools needed to create initrd/initramfs per your purposed and requirements. I would like to describe them, and as that would be quite a bit of contents, going to do it describing features one by one, in "snippets".

The first is:

Building initramfs with OE and everything you wanted to know about initramfs but didn't bother to figure out yourself.

IMAGE_FSTYPES = "cpio.gz"

Yes, that's all what you need to create an initramfs image, voila. After that, you can use resulting image instead of conventional initrd (in ext2 or some other format). For the kernel to be able to boot it, you need to have CONFIG_BLK_DEV_INITRD=y in its config (contrary to its name, this option actually means "support external initrd *or* initramfs images"). As initramfs support is unconditionally builtin into kernel, you don't need any filesystem enabled for initramfs support.

(Note that above is written for standalone initramfs image which is used in initrd-like manner. Support for initramfs which are linked into the kernel image so far is not provided OE, but would be pretty easy to add. Still, it's of more interest to vendors which work on specific products than OpenSource distros. By the way, mentioned config option is not required for builtin initramfs.)

Note that execution of initramfs starts with /init. If you want to rebuild initrd (or otherwise conventional rootfs image) as initramfs, you'll need to pass following parameter on kernel command line to have it started properly: "rdinit=/sbin/init".

Final note is that contrary to popular belief, initramfs does not completely covers and supersedes initrd functionally. Initramfs has relatively big memory requirements, which precludes usage of big initramfs images on low-memory systems. Specifically, initramfs is compressed, and needs to be uncompressed during startup, which already limits its size to at most half of the available RAM. But actually, ramfs, which is used as backing store for initramfs content, is pretty inefficient for such type of content (static), and that imposes even more limits. Also, my experiments show that kernel has poor error handling while uncompressing initramfs, and out of memory condition makes it just hang. So, when you need to fill memory up with lots of content, nothing would replace an initrd with builtin compression like cramfs or squashfs. Granted, that's rather adhoc need.

Finally a kernel hackers' initrd image in OE!

2007-07-18T02:18:00.000-07:00

When I only started with Linux-on-PDA hacking, I, as people usually do, combed internet for any kernel/initrd images which were marked as being for the PDA model I had at that time. In such way I picked up few initrd's, and after practically comparing among themselves, selected one for standard hacking use, like kernel testing. A bit later I augmented it by installing some missing stuff (like mc), and seeing that many people are not so thorough and searching the net, put it up for others' use. That's basically what I've been using since them and suggesting to others who needed environment to test some kernel feature with minimal userspace involvement.

Of course, that situation was rather ridiculous - using some random binary-only image instead of OE-built is not perfect at all, and I was just hoping that someone else would go for that. Well, with the latest changes in OE to facilitate creating efficient initrd/initramfs images, I finally got to this myself. So, here's now such image, codenamed 'devimage'. Consequently, recipe to build it as a complete image is called 'devimage-image.bb'.

Its purpose defined as: provide environment which by default runs only minimal userspace (busybox sh and dropbear now, to support different connection methods), but offers all needed "kernel userspace" utilities from udev to specific utils for ALSA, IrDA, Bluetooth, WiFi, etc.

At the current stage it's not as complete as that, so help with filling it right is welcome (caveat: size should be kept in mind).

It's all firefighting, right?

2007-07-13T05:18:00.000-07:00

Well, time for a nice "depressive" post ;-).

So, at the beginning of week I decided to port GParted. Was more or less easy, just a fix for an obvious thinko from the author regarding C++ std namespace ;-). However, it failed on linking stage with infamous rpl_malloc() and friends not resolved for libparted. Looking thru cofigure log, that's of course result of crosscompiling assumptions, but OE has defines for the corresponding tests in autoconf site files, so what was actually happening is shipped parted 1.8.7's configure not loading these site files.

It also turned out that autoreconf'ing of this parted version doesn't work, as it requires autoconf 2.61 and friends as minimal, while OE has 2.59. Trying autoreconfing 2.61 (which is DEFAULT_PREFERENCE=-1 in OE) lead to the same issue with site files loading. At this point I submitted bugs on this, and raised issue on #oe. Actually I didn't even expect immediate big attention, but it caught developers' eye, and with the help of XorA and hrw, to the end of the day we had a solution. (And the root of issue was bug in autoconf 2.61. They used "shell programming patterns" (cough) you really don't want to use in your scripts, and the result is proverbial - they outslied themselves).

Well, on the droop of day, GParted was built. I run in QEMU and was surprised that UI was pretty barely usable on QVGA. Run on a real device to try a real card brought a gore however. First of all, GParted didn't detected my SD card at all. I even went looking at GParted source for how it scans devices, but then run parted on it. "Overlapping partitions now supported" was abort message. Overlapping partitions? Me? No! Wrong call! Fortunately, running fdisk showed instead of the senseless bold accusation the fact that my camera indeed tried to dig weird holes in parttable, apparently confused with ext2 partition there ;-)

Well, finally GParted was run, bliss. But just going thru menus once made them no longer accessible. Already trained on such stuff with LiveRamdisks work, I knew it's out of memory. Running ps aux showed some unusual suspects. Killing them (btw, GParted's RSS was "merely" 15Mb comparing to those 6Mb's. Ah, it's all shared libraries, ok, ok, I shut up.), I finally had the thing live. Now closer look look showed it doesn't recognize EXT2 partition (at least FAT it did). The same in parted. Have no idea is it camera hosed it or it's just proverbial GNU software quality. It also turned out that the only operation I was able to do is to change boot flag for a partition ;-). I tried to format unrecognized partition as EXT2 for example, and it failed after shuffling a card for a bit. Getting to HTML report it laid in the home dir surfaced "sh: nice: Command not found". Oh, oops, dear app ;-).

Finally, I wanted to make a screenshot, but gpe-scap failed to write it, complaining that it can't do UTF-8 -> ISO-8859-1 conversion for PNG CREATOR chunk (soft laugh).

So, what are the conclusions? X is not an ultimate solution, but merely an option. Lure to run large body of existing, and updated, software is still a lure, as besides this opportunity X brings bloat, which on resource-constrained system vice-versa inhibits ability to run all that wealth of soft well.

Also, all those kernel-hacking games are really old. And I hope that everyone on the block understands by now that what they get once kernel is well and polished is havoc in userspace (this applies to new players like Neo1973 too). So, it's time (yes, finally now, if not long ago)
to leave machine-level feudalism behind, and bring all Linux PDA/phone communities together, to work on common aims. And OE is well established community crossroad project, so implementation-wise, that would mean making sure that any more or less developed device is available in OE, and that any newcomer for a questions "Is X supported?" or "Where can I find stuff for X?" could be answered "Use OpenEmbedded." Yes, right that - use OpenEmbedded, period. Not even "You can use OpenEmbedded, just copy one to another one, and tweak this and that".

Linux installers bumbo-jumbo

2007-07-11T03:36:00.000-07:00

On Monday, I decided, as a kind of change-activity rest, to review the situation on Linux installers market. I had closer look at what big players use, as well as googled and searched SF.net. Well, a generic, truly modular, lighweight and elaborated installer doesn't seem to exist. So, if we speak reuse, then considering an installer of specific distro is apparently the way to go. And big players are:

RedHat systems with Anaconda, written in Python (PyGTK) but with bunch of C code too. Seemed like nice design, I even checked out CVS repo, and tried to make it show me some dialog without complete build. Nah, written in Python doesn't automatically mean it's written nice. Building it also didn't work - it depends on bunch of RH-authored libs, which don't even packaged in Gentoo for example.
Debian with Debian Installer. This is apparently largely written in C, as one of the design goals was to support all architecture set of Debian, in particular lowy ARMs. The default version is text-mode, but recently(?) they got also GUI version (GTK+, and they build it against DirectFB). It is also said to be modular and reusing other Debian components, like debconf, and indeed, looking at the SVN repo from bird's view in browser was scary enough that I didn't proceed to specifics.
Ubuntu's Express-Espresso-Ubiquity. Reuse at run. Uses Debian Installer as the backend, with (apparently Python) frontend.
Gentoo Installer. This one will be finished when it will be finished, plus also I managed to spot bunch of UML diagrams but not the language it's written in.

Not very bright results. And thinking of it, the only thing in installer which calls for reusing some existing implementation is disk partitioning (and yes, PDAs do have secondary storage, and most users want to install Linux there (even though most of those most may not yet know that)). The rest of installer's work is pretty trivial and could be coded in Python in a day or two.

Well, ground-level solution is just present users with generic GUI partitioning app, and let them do partitioning themselves, right? So, I decided to quickly try how GParted runs on a common PDA, and that's all subject for another post.

Driver for ACX100/PCMCIA

2007-07-08T14:17:00.000-07:00

Thanks to Fabrice Crohas, htcblueangel maintainer, who have been tackling at acx_cs driver since we were able to achieve first WiFi ping on h4000 and htcbluenagle with the help of devmem2, the PCMCIA support for ACX100 WiFi driver now works! It took quite some time to figure out what issue with PCMCIA was and make it work after first slavemem-connected device (hx4700) had first ping, but finally we're there - ACX is support on the great majority of devices which have it (though it is still has something in store, as couple of newest device have it connected via SDIO).

Working WiFi also means that all hardware on h4000 is supported now, and it has A- support status per HH.org classificaion, with the only missing feature being a native flash bootloader for Linux. Of course, not everything works great yet, or even fully tested, like flash write at all (but it is known to work for h6300 which has the same DiskOnChip and uses the same driver). ACX itself for one needs lot of work to make it support suspend/resume properly and PM in general.

But all those are just things to test/bugs to fix, and not white spots in hardware information/support. We're past age of "Linux will never be able to support that device completely" for another bunch of devices, and the future is bright! ;-)

First steps at making OPIE fit well with OE filesystem structure

2007-07-02T21:37:00.000-07:00

One of the requirement set for OPIE to be supported for Angstrom was compliance with standard GNU/Linux installation location ($prefix and friends). There was bug in OE long enough for this, with few developers considering how to proceed with this.

I finally found time to test some ideas from it, and initial conversion from /opt/QtPalmtop to /usr went pretty smooth requiring besides rebuild few fixes to packages where the former path was harcoded in the literal form. Resulting opie-image booted in QEMU quite well, so I went with committing it, bumping snaphost date for OPIE 1.2.3-pre to 20070702 at the same time.

Hope other developers will help with testing it, and then the conversion needs to be fixed by moving data and plugin to appropriate locations (now they live at places like /usr/pics). This would take a bit more effort exactly because of this dichotomy - data vs plugins, with first should be living under /usr/share, and the latter (ideally) under /usr/lib. I wonder, if a solution like making QTDIR, etc. environment variables to accept list of paths is good enough (well, it is generic from system design point of view, but adds extra runtime overhead).

Running "user" QEMU emulation on Fedora Core 5

2007-06-27T11:25:00.000-07:00

I have few boxes around with different OSes/distros and try to use them in reasonable manner. For a some time I contemplated setting up continuous integration for OpenEmbedded, and the box suiting that purpose runs FC5 here.

Well, soon after running a test build on it, I hit issue that OE's binary locale generation, done by running target localedef under QEMU "user" emulation (qemu-arm) errors out there, and on closer inspection, just segfaults. Taking some time to run it thru gdb and strace, I found that it happens after mmap2() syscall, and in seemingly random places in code. More close look at the stuff showed that address parameter to faulty mmap() kind of correlates with VDSO location reported by gdb. Gotcha! So, somehow guest process manages to overwrite VDSO as used on FC5 system.

Now it took some time to figure out what's happening, but it turned out that FC5 applies whole bunch of patches (mostly labelled "execshield" and "xen") affecting VDSO handling to 2.6.15 kernel, when final set of VDSO randomization patches, etc. was not yet in mainline. In other words, FC developer took their own try on solving VDSO issues, with the outcome described above.

Well, it took only couple hours more to rebuild kernel without those patches and teaching it to pickup original initrd (maybe I should have rebuilt it instead, I just didn't do that before). And now I have pristine and full-feature OE builds on FC5 system, voila! ;-)

Porting "Industrial" PDA?

2007-06-26T12:05:00.000-07:00

On weekend on local second hand hardware resale board I spotted offer for an industrial PDA with a builtin barcode scanner. Second-hand PDA prices are generally crazy in this part of the world, but this was barely reasonably priced, and it included bare WinCE 4 OS (not PocketPC or Windows Mobile), which made it rather useless in hands of layman, and thus offered some room for bargain.

Being a big fun of "scientific organization of life", I contemplated getting a barcode scanner for quite some time, but anything besides pop supermarket "gun model" USB/RS232 is rather pricy/unavailable here. So, after all, I went with buying the piece. It was announced as PXA255, I checked that fact on vendor site, and didn't bother to check it during hand-off, but soon caught the fact that it's merely a StrongArm. Checking vendor's site closer, I understood that sloppy guys had a StrongArm device, which they later upgraded to PXA, added "-foo" to the name of model, and killed old one from the site. Lart such vendors, what can I say... Either way, the winner is PD-264 from Italian vendor EIA. I even wanted to call a guy to return it back, but then reconciled it as a good opportunity to revamp SA support in HH.org kernel. And unlike h3600 which I had before, PD-264 offers such opportunity in comfort - it has CF & SD slots, plus 64Mb RAM and 32Mb ROM. It lacks any networking interfaces though, and UART is taken by the scanner, so it's not that cool in the end, and debugging may be hard actually. Still, I got a barcode scanner with a whole PDA builtin cheaper than my previous favorites in shopping list, FLIC Bluetooth scanner, or Baracoda Pencil.

Now, this would be my first PDA I port from scratch (vs picking up existing port for maintenance), and I'm going to blog the process here, as it was raised many times that there should be a howto for newcomer porters. (Though I checked Michael Opdenacker's presentation, and it's [still] quite good, keeping in mind that it's presentation, not howto).

Power management for GPIOs

2007-06-25T04:15:00.000-07:00

I just committed to HH.org kernel CVS Roman Moravcik's patch for improved power management for rx3000, and among other things, he took care to setup currently unused input GPIOs as outputs, which is known trick to cut unneeded current drain on them. That's something what all other ports should be reviewed for.

Defconfigman support for S3C24xx ports

2007-06-24T16:59:00.000-07:00

Thanks to Michal Panczyk, support for S3C24xx CPU and ports (Eten G500, iPaqs rx1950 & rx3000) added to Defconfigman. Corresponding static_defconfig's already in HH.org kernel CVS, will go to OpenEmbedded soon. (They need more review/cleanup though.)

First Angstrom LiveRamdisk

2007-06-24T12:28:00.000-07:00

LiveRamdisk is a pun at LiveCD, hinting that it must be something which allows users to try Linux easily without much preparation and that entire distro will be loaded from RAM.

For PocketPC case, it is a single big .exe file which when being started from normal WinCE environment, loads initrd (or a something alike) and kernel into memory and boots the latter.

I wanted to do something like that for a long time, and rejoiced when Kevin O'Connor, another HaRET maintainer, added ability to create single-exe bundle to HaRET 0.4 this winter. Unfortunately, nobody picked up this possibility, so I decided to give it a try, finally. Alas, it turned out to be not so easy when came to loading realistic (~20Mb) images. So, bunch of hacking was needed both on HaRET and Linux side.

But finally, first LiveRamdisk, an Angstrom X11 snaphost for hx4700, was released two days ago. Besides announcing it on Angstrom mailing lists, I also did some cheap PR on local forums. Well, two days later, the reaction is rather mild - there were only 3 downloads. At the same time, I was pretty surprised that my unofficial Familair 0.8.4 release for h4000 was downloaded 900 times in total. So, time will tell ;-)

Blog start and older news

2007-06-24T04:31:00.000-07:00

I always treated blogs (and generally diaries) skeptically, but well, all tools have their uses. So, I'm going to start blogging on my Embedded Linux (well, probably not only embedded) endeavors.

And first of all, older news, which I kept in my Handhelds.org wiki page.

2005-11-13: Subscribed to the h4100-port mailing list.

2005-11-29: Confirmed by bisecting that PXA suspend/resume broke in 2.6.13 comparing to 2.6.12. Turned out ot was fixed in 2.6.15

2005-11-29: Subscribed to the kernel-discuss mailing list.

2006-02-03: Proposal for asic3_mmc cross-machine refactor.

2006-02-05: Faced strange issue with ASIC3 suspend/resume, took few months to resolve ;-)

2006-05-30: Posted patch for h4000 ASIC3 suspend/resume problem, turned out to be as "simple" as initializing MSCx PXA registers after resume, what Linux kernel doesn't do (leaving that to bootloader). Anyway, this was second big issue I solved, and after that I felt "force" ;-).

2006-06-03: Started to work on final version asic3_mmc cross-machine refactor, based on the previous experiments.

2006-06-19: Final version of asic3_mmc cross-machine refactor posted.

2006-06-21: Granted write access to !HandHelds.org Kernel CVS repository.

2006-08-20: Posted RFC for common button map for all HH.org PDA-type machines.

2006-08-24: Granted write access to OpenEmbedded Monotone repository.

2006-09-20: Unofficial Familiar 0.8.4 release for h4000.

2006-10-03: Received donation of h3900 device to support elaboration of 2.6 kernel port for it and advance userspace/distrubutions support. Contributor: Mr. Alex Deucher. Thank you!

2006-10-11: Posted patch for common button map for all HH.org PDA-type machines.

2006-10-18: Received donation of hx4700 device to support elaboration of 2.6 kernel port for it and advance userspace/distrubutions support. Contributor: preferred to stay anonymous, but many thanks!

2006-11-09: Upgraded HH.org kernel CVS to 2.6.18.

2006-11-14: Finished implementation of asic3_keys driver and making sure it works well with gpio_keys.

2006-11-21: With having common linux-handhelds-2.6_*.bb and consistent names for all iPaq machines, first phase of cleaning up HH.orh-maintained machines in OE.dev is complete.

2006-12-02: Upgraded HH.org kernel CVS to 2.6.19.

2006-12-19: Angstrom upgraded to 2.6.16-hh8 kernel with common buttonmap support.

2006-12-22: h3900 reached full "C" status, with partial "B" status, in other words, basic PDA functionality works!

2006-12-28: h3900 2.6 port added to OE.dev, requested support by Angstrom.

2007-01-04: Initial release of [http://sourceforge.net/projects/defconfigman/ defconfigman]

2007-01-10: Started to revamp OPIE support in OE.dev, starting with cleaning up qte patchset.

2007-01-18: Received new contribution: h3600 and palmtt2 devices. Thanks! Now I have access to PXA250, PXA255, PXA270, StrongArm, OMAP devices.

2007-01-20: asus620 port updated in CVS. Thanks to Vincent Benony, asus620 maintainer.

2007-01-21: defconfigman kernel's sound tested to work with GPE. Both h3900 and h4000 in OE.dev now have defconfigs generated by defconfigman. h4000 updated to use modules for sound.

2007-02-16: Upgraded HH.org kernel CVS to 2.6.20.

2007-03-05: Continuous Integration system for kernel tree set up, http://handhelds.org/~pfalcon/busyb/buildlogs/

2007-03-17: Proposal to use Defconfigman-generated configs for kernel CVS, to improve consistency and CI coverage.

2007-04-11: GPIODEV API RFC posted to LKML/LAKML

2007-04-26: All 30 ports in HH.org CVS are buildable now (for 2.6.20)!

2007-05-01: SoC base drivers RFC posted to LKML.

2007-05-07: Upgraded HH.org kernel CVS to 2.6.21.

2007-05-11: ipkg speedup patches committed to OE.dev

2007-05-15: Mystery of PCMCIA ACX is solved, first WiFi ping on h4000!

Linux, IT, DIY, Interesting Stuff...

NSLU Optware for Android

HC-04 Bluetooth module and BlueCore4 Deep Sleep

Enabling SPI logging in BlueSuite tools CSR BlueCore chips

Notes on Android EGL/native windowing system interface

Thoughts/notes on Android version upgrades and reusing Android drivers

New Hack Toy - Zenithink ZT-180

Stopping Android GUI services

Bluetooth Park Mode Exposed

Linux kernel Bluetooth ACL connection auto-disconnect

Bluetooth link key types

Pairing Bluetooth devices from command line

Shopping for 3D TV...

Kindle Packages I use

Links for November 2011

Fixing fan cooler in Asus X34F notebook

Making hcitool commands work

Links for September 2011

Towards decent mouse wheel support in Android

Links for June 2011

Hacking Luxeon SP-1

Hacking Technoline WS 585 weatherstation

Comparison of OpenSource PDF readers for Android

And the winner is...

Breaking out of Android sandbox

OpenSource Package Manager for Android

Critical review of build systems

WM8505 (VT8500, WM85xx) hacking timeline

Ubuntu, somebody's favorite Linux-based distribution

Xara Open Source - Sleeping Beauty

Hacking Osram NightLux

Links for February 2011

Links for January 2011

And the winner is...

Samba and iptables UDP broadcast issues

Notebook MSI X430 (aka X420 aka X410) - Big Disappointment

Mercurial goes down in my list comparing to git

Some WinCE links

WebKitGtk vs QtWebKit

Scrolling Performance

Image Scaling Quality

Bash Braindeadness: Logical Connectives

USB gives a lesson in physics

Quest for Ultimate Browser

Floating Posts

Blog reloaded

Weekend project: porting a game to QVGA

info reg, for a ducat, info reg!

Smallscreen mod for GtkFileChooser

*Real* C#/Java support in OE

Angstrom 2007RC1 is here!

How to find out if USB mobile phone data cable is based on PL2303

More Angstrom LiveRamdisks

Back from hiatus

Finally out of the list of pressing OE issues

Modular initramfs for OE

Initrd and initramfs with OE: snippet 1

Finally a kernel hackers' initrd image in OE!

It's all firefighting, right?

Linux installers bumbo-jumbo

Driver for ACX100/PCMCIA

First steps at making OPIE fit well with OE filesystem structure

Running "user" QEMU emulation on Fedora Core 5

Porting "Industrial" PDA?

Power management for GPIOs

Defconfigman support for S3C24xx ports

First Angstrom LiveRamdisk

Blog start and older news

Real C#/Java support in OE