Categories
Bali (Indonesia) embedded systems English articles My life OpenWrt qi-hardware Tech Trips

trip trip – hurra!

Long time no news…

some things happened which weren’t worth a particular post (or I was just too lazy), so I’ll try to summarize of a few things which happen(ed):

== tech stuff

OpenWrt is still my focus – the qt4 package now got libX11 support (besides DirectFB / linuxfb, both accessed by the QWS-part) – thanks a lot to Michael Büsch at this point!

I’m also very interested in the new features of qt4.7 – especially the declarative UI part of qt4.7 called QML – an approach of designing UIs in a declarative way, means, from the UI’s point of view (more in the mentioned links above).

I’m curious about how/whether it can/will be used/accepted by “native” designers to write fully functional GUI applications.

It’s approach is looking quite promising to me – the language style as well as the implementation – really curious about how it’ll do on embedded devices without graphics acceleration. After some talks to qt developers GL support is not required; a number of animations, effects and transitions were optimized for software processing and should be even smoother than rendered via GL.

First usecase is going to be a picture frame, which has the same SoC built in (Ingenic JZ4740) as the NanoNote and therewith is pretty well supported.

The picture-frame is an ID800WT manufactured by Sungale.

Before somebody is going to think, whether I want to promote/support/recommend this brand/product:

From the board layout’s point of view it is the worst product sold in Germany I’ve ever seen! And it’s too expensive! And the company violates the GPL!

Take a look at the board by yourself:

Sungale pictureframe ID800WT board
Sungale pictureframe ID800WT board

The USB Wifi-stick got hot-glued onto the board, it seems they even unsoldered the USB-socket manually (because it looks really charred all around) and connected it with some random wires to a SMD-chip which in fact is an USB-hub. Around there’s hot-glue all around, partially charred, partially way too much. This is really the worst in Germany sold product ever!

However it serves the purpose – has supported wifi (atheros), an 800×600-display, a touchscreen, USB-host, etc.

After my holidays I’ll try to evaluate and play around with qt4.7-features on that device on top of OpenWrt.

== trips

After almost one week spent in Croatia, Split, participating at the “nothing will happen” conference – which was really amazing and organized by very nice people – I’m going to travel to Bali for one month, leaving in two days.

Actually I wanted to go to Burma (Myanmar), however I mixed them up and booked my flight to Bali, Indonesia… anyway – more beach and sea this time…

This is going to be my third trip to Asia and I’m really looking forward to it – this time for holiday, backpacking without any fixed plans.

Actually I also didn’t want to take a computer with me – still I bought an EeePC 1015. Resolution is disappointing, however price, weight, battery life (about 8 fucking hours!) and site serve the purpose of just having a terminal perfectly.

See you there 🙂

Categories
embedded systems English articles OpenWrt qi-hardware Tech

QT/KDE on OpenWrt

As you may know OpenWrt’s collection of ported packages is continuesly growing.

Many graphical stuff gets ported, as well as graphical desktops and toolkits (lxde, xfce, gnome based on GTK2 – e17 based on the enlightenment foundation libraries – etc.).

However there was no approach yet to port the last missing Desktop “KDE” and underlying Toolkit “QT”.

That’s why I went to “Tokamak 4” this weekend, a meeting organized and founded by the KDE foundation, intended to communicate and hack together related to several KDE software projects.

We were about 25 people from all over the world and I really enjoyed the stay and nice, friendly and mixed party – surprisingly I was the only one not using KDE (however not for a special reason – just got used to my current environment) :).

They showed lot’s of interest in the UCI-System (Unified Configuration Interface) OpenWrt is using.
It’s a simple, human-readable, easy-to-parse configuration file format and library OpenWrt uses for services to make it easy writing Administration Interfaces for them (e.g. the webinterface “LuCI”).
We were spinning around about KDE Plasma applets which will list available OpenWrt-devices ready to get administrated right through native applications.

Key deal for me however was to get in touch with people who know the QT/KDE architecture very well, for sure promoting a bit OpenWrt, qi-hardware and it’s concept of open hardware and why I think having QT/KDE support within OpenWrt is opening lot’s of opportunities for both projects.

Since QT is able to use DirectFB (a very powerful but light abstraction for the linux framebuffer) – and therefore does not require a X11 system necessarily – it would be also great for limited hardware such as the Ben NanoNote (32MB of RAM) where I got GTK2-based apps running on top of DirectFB quite some time ago.

I expected to get basic support for QT within OpenWrt done this weekend, however I underestimated the size and complexity of QT – never touched QT-code before.
I realized QT is not just a toolkit as GTK2 is, but a whole framework which tries to abstract as much as possible from the underlying system. It features own backends for multimedia, sound, graphics, even networking – to achieve a stable API and platform compatibility without the need of code modifications, no matter which backends or systems are used below.

In which way the typical issues of such a abstraction-concept – such as getting bloated, having performance issues, being feature-limited as you’re usually just able to support the least common denominator of all supported backends, etc. – I’ve no idea yet – maybe they found a way, will find that out sooner or later.

They also use “qmake” as build-system which is structured quite different than e.g. GNU make, so this got another temporary road blocker as I used qmake never before and had to dig in first.

Back to the port of QT to OpenWrt: I’m having promise to see the first basic QT based application running on a OpenWrt supported device within the next days.

Will let you know 🙂

Categories
English articles fun misc Tech

PHP – fooled me once again…

I was asked to take a look at several free and opensource software web-projects which are capable for so called “ISP configuration management”, managing web-, mail-, database-servers, etc. – handling clients, resellers and admins and having specialized frontends for them…

Anyway… I trigerred a weird bug in one of the projects where I got into an if-condition where I shouldn’t get into… which not just caused a weird behaviour of the application but was also a big security hole in this special case.

The code was something like that (simplified and not tested):


get_sql($value) {
   if ($ret = mysql_query ("SELECT * FROM `table` WHERE foo='%s'"),
       mysql_real_escape_string($value))
   {
     return $ret;
   }
   else
   {
     return false;
   }
}
<br />
$result = get_sql($foo);
if (count($result) &gt; 0) {
&nbsp;&nbsp; // privileged area...
}

Ugly code – anyway… how it was expected to behave by the author?
1) function get_sql() gets executed and therefore a sql-query
2) get_sql() returns an array of results
3) the number of results is checked via count($result) and when the result-array is greater than 0 jump into the if-block

Okay, so far so good…

However – I finally found out the SQL-query in get_sql() fails because of a typo.
No error was thrown in the above code – so what’s happening?
1) function get_sql() gets executed and therefore a sql-query
2) get_sql() returns the boolean false, because the sql-query failed
3) count($result), evaluated count(false) is called

As the software just did behave different and didn’t throw an error an intermediate result is:

count() applied on a boolean is valid !

So what’s count(false) going to return?

1! – the integer one!

count(false) is 1 and in PHP therefore true!

Proof:


$ php
&lt;? echo count(false); ?&gt;
1
$

Even better: this behaviour is kind of “documented” within an example at http://php.net/manual/en/function.count.php without any comment.

Okay, now guess:
What’s count(true) returning? And this is not documented!

1! – the integer one!

PHP – dine in hell…

Categories
embedded systems Openmoko OpenWrt qi-hardware Tech

GTK2 running on top of DirectFB on OpenWrt!

OpenWrt is now able to run applications based on toolkit GTK+ on top of DirectFB!

Using DirectFB avoids having a full blown X11-server (most times Xorg) running, but having the possibiliy of getting nice GTK2 widgets onto your display without altering applications which are using the toolkit.

I was quite happy I got that working, because unfortunately DirectFB-support on part of gtk2 is quite broken in most versions.

Due its incredible slowness of GTK2 on the Openmoko Freerunner (400 MHz ARM, 128 MB RAM) I didn’t expect much of gtk2 on top of DirectFB.

Surprisingly, a simple gtk2 app runs quite well and responsive on my Ben NanoNote by qi-hardware (366 MHz mips, 32 MB RAM).

I was curious and started some benchmarking with the gtk2 performance testing tool “gtkperf”. However I had to patch gtkperf that it’ll be usable with the qvga-resolution on the Ben NanoNote (otherwise parts of the app were hidden and the benchmark will get falsified because not the whole gets redrawed).

Do not compare your results of an original version of gtkperf with mine – varieties may be caused due to mentioned changes! (Patch: http://nanl.de/files/patches/gtkperf/gtkperf-adjust-layout.patch)

What got tested?

gtkperf using GTK2 on:

  1. Openmoko Freerunner with DirectFB
  2. Openmoko Freerunner with Xorg and glamo driver
  3. Openmoko Freerunner with Xorg and fbdev driver
  4. qi-hardware Ben NanoNote with DirectFB
  5. qi-hardware Ben NanoNote with Xorg and fbdev driver (not yet done)
1 2
GtkEntry – time: 0.91
GtkComboBox – time: 16.01
GtkComboBoxEntry – time: 10.18
GtkSpinButton – time: 2.37
GtkProgressBar – time: 1.04
GtkToggleButton – time: 2.54
GtkCheckButton – time: 1.72
GtkRadioButton – time: 4.16
GtkTextView – Add text – time: 9.47
GtkEntry – time: 2.08
GtkComboBox – time: 30.40
GtkComboBoxEntry – time: 21.65
GtkSpinButton – time: 3.54
GtkProgressBar – time: 2.55
GtkToggleButton – time: 4.66
GtkCheckButton – time: 2.71
GtkRadioButton – time: 6.64
GtkTextView – Add text – time: 26.06
3 4
GtkEntry – time: 1.73
GtkComboBox – time: 22.70
GtkComboBoxEntry – time: 16.52
GtkSpinButton – time: 2.60
GtkProgressBar – time: 1.93
GtkToggleButton – time: 3.60
GtkCheckButton – time: 2.28
GtkRadioButton – time: 5.73
GtkTextView – Add text – time: 18.81
GtkEntry – time: 1.07
GtkComboBox – time: 18.61
GtkComboBoxEntry – time: 10.98
GtkSpinButton – time: 2.81
GtkProgressBar – time: 1.51
GtkToggleButton – time: 4.31
GtkCheckButton – time: 2.60
GtkRadioButton – time: 7.42
GtkTextView – Add text – time: 12.48

 

The results are really interesting!

On the Openmoko GTA02 (Freerunner) GTK on DirectFB seems to be almost twice as fast as GTK on top of Xorg!

Even though the Hardware of the Ben NanoNote is quite limited compared to the GTA02, the benchmark looks quite promising and GTK2-applications seem to be – unline I expected – really usable on that kind of limited hardware.

What’s really confusing to me: running gtkperf on top of the accelerated Xorg-glamo driver for the glamo graphics chip is slower than using the not accelerated Xorg-fbdev driver. However this myth should not be part of this article; I’ll get in touch with Lars – the author of Xorg-glamo – regarding this issue.

UPDATE: Lars told me this is related to the glamo-overhead. Data transferred to the framebuffer via fbdev only consists of pure pixmap-data. Data transferred via the glamo-driver consists of data AND special glamo-related commands (telling the chip what to accelerate) which results in more data to be transferred. Normally this shouldn’t cause such a discrepancy, however the glamo memory-onnection is a bottleneck and only capable of tansferring around 4 MB / second which slows down unacceleraed content. The glamo chip provides the interface for the SD-card, so the whole bus is shared by graphics- and SD-carc-traffic. That’s the reason why e.g. playing videos (unaccelerated) stored on SD-card is that damn slow!

Further tests, benchmarks, evaluation coming soon…

Versions:

gtkperf: 0.40 (with patch: http://nanl.de/files/patches/gtkperf/gtkperf-adjust-layout.patch)
DirectFB: 1.4
GTK+: 2.17.0
cairo: 1.8.6
pango:1.26.0
freetype: 2.3.9
glib: 2.22.2
atk: 1.22.0
pixman: 0.14.0
Xorg X11 server: X11R7.4-1.5.1
xorg-driver-glamo: b45d78c927715b8814404fc2a34ae0aa1d003c29

Categories
embedded systems English articles OpenWrt qi-hardware Tech

OpenWrt on the Ben NanoNote!

The Ben NanoNote I got a few weeks ago by qi-hardware is now running OpenWrt!

The patch, published by the manufacturer ingenic itself, which provides linux support for their SoC’s (System-on-a-Chip’s), is roughly cleaned up, unneeded stuff is cleared out and it’s levelled up to 2.6.25.20 (originally the patch refers to 2.6.24.3) and – running!

That’s the good news…

…now the bad ones:

  • The mentioned patch by ingenic contains not only linux kernel source but also binary data – ELF-formatted binary code for the mips instruction set! For more details you may want to look at my post on the developer-mailinglist (http://lists.qi-hardware.com/pipermail/developer/2009-August/000162.html). They patch in a proprietary mtdblock-replacement which seems to differ to the original in nand-flash error correction and handling of bad blocks. That’s a no-go – not just because of the reaosons of open hardware/software but also as not being able to forward the patchset to a newer kernel version.
  • Strange problems appear with the MMC / SD-card hardware. Randomly the hardware does not recognize the card correctly (more precisely, the card is recognized but not the partition table why the kernel panics because of not finding it’s given root device). Spent days not on this issue, but weren’t able to figure out yet what’s causing this kind of behaviour 🙁

What’s next?

  • get this bloody MMC/SD-card issue fixed
  • get the NAND flash supported – either we get the sourcecode of the modified mtdblock driver or get it supported elsewise
  • further cleanups of the existing patchset
  • level up the patchset to a recent kernel version (2.6.31 would be best – much stuff went upstream / is now handled nativly, e.g. nand-chips > 4 GB don’t need the ingenic hacks anymore, also there’s a new interface for gpio-based keyboards which should make it pretty easy to write a keyboard-driver and allows us to get rid of the existing stuff).
  • (re)writing some (of the) drivers (e.g. MMC/SD-card support and support for SDIO, keyboard-driver as mentioned above)

I was in Hamburg this weekend meeting Lars for a hack-session on the Ben NanoNote. He’s also part of the OpenWrt-team and now another proud owner of such a device 🙂

Besides his ongoing contributions to the Openmoko-project, hopefully he will also help us* spending some of his time on the NanoNote – thank’s a lot at this point for your great work and efforts!

*i’m happy to announce that last week I “became an official developer of the [qi-]core team” with “focus
on the OpenWrt integration” – let’s see what will happen 🙂

Categories
embedded systems English articles OpenWrt Tech

Linksys WRT160NL

I got a Linksys WRT160NL and because I didn’t find any pictures of the board nor any data about the serial – here’s what I got:

Linksys WRT160NL
Linksys WRT160NL (click to enlarge)
Categories
embedded systems English articles Openmoko OpenWrt qi-hardware Tech

qi-hardware

qi-hardware is a startup (announced 20th of July on linux.com) which set itself the target of manufacturing and deploying  hardware under the idea of “Open Source Hardware” (for details you might want to read the mentioned article on linux.com or on qi-hardware.com itself).

This idea might call some analogies to Openmoko and – indeed – not just the ideas, also the people are almost the same 🙂

Same idea? Same targets? Same people? Let’s face it: same mistakes? At least qi is saying: “no!” as described in their post “Lessons learned

Based on the saying “back to the roots” aka “the more basics the fewer problems” they announced their first device:

the “Ben NanoNote”, which (at least for now) comes with no RF-hardware at all.

Nevertheless the project looks very interesting and promising – even more when I was told that OpenWrt is going to be used as default operating system.

Shortly after I was asked whether I’m interested in helping getting OpenWrt running on it – I agreed, got one and am now hacking on it 🙂

Let’s see how things will do…

Categories
embedded systems English articles Openmoko OpenWrt Tech

…and because everybody likes screenshots :)

Categories
embedded systems English articles Openmoko OpenWrt Tech

OpenWrt on the Openmoko Freerunner – some updates…

Long time no news regarding OpenWrt <-> the Openmoko Neo devices; but it
happened much!

It now reached a state where I think it’s justified to announce a ready-to-work(/debug?) OpenWrt-Image for the Openmoko Freerunner.

This should be a short overview of what happened

– kernel 2.6.30.1 is running
all neo-specific patches were extracted from the OM-kernel-tree and
created an atomic and maintainable patchset for the Neo (thanks to Lars !!)

– clean, stable and accelerated graphics system
thanks to the gorgeous work of the xf86-video-glamo developers (especially Lars (again)), finally
there’s no need for <Xglamo> anymore – acceleration is done from within
an usual <Xorg> with the glamo-driver used. The infamous WSOD (white screen of death) should be
ultimately purged out.

– GPS works
the amazing application <tangoGPS> is also available as an
OpenWrt-package now

– performance tuned
due to it’s architecture itself, fixed bugs and found ways for
optimizations through all layers, OpenWrt now boots in less than 1
minute into illume (very first boot excluded)

– software added/upgraded
besides lot’s of just OpenWrt-related improvements, also typical
OM-community-used packages were added and upgraded to recent versions
(e.g. tangogps, enlightenment/the whole efl-suite, paroli, fso, connman,
etc.)

– a beautiful bootsplash
real beauty can’t be described by words 😛

– phone calls are still possible
thanks to paroli, the basic phone stuff is (still) working (phone calls,
messages, contacts, etc.)

== Images / environment

Images can be found here: http://nanl.de/files/openwrt/openmoko/
Mind – that, as usual for OpenWrt – the default IP of your device will
be “192.168.1.1” and the only running service will be <telnet> on port
23.
After logging in and setting a password, <telnetd> is getting replaced
through <sshd> (port 22).
The mentioned files/images have the prefix “20090706_r16709_1”, based on
svn-revision 16709.

Suggestions / critism is welcome… 🙂

The original announcement on the mailinglists can be found here (http://kerneltrap.org/mailarchive/openmoko-devel/2009/7/6/6147903)

Categories
embedded systems English articles OpenWrt Tech

asserts in python may not work as expected

While getting the phone suite “paroli” (http://paroli-project.org) working on OpenWrt, I got some thrown exceptions in the OpenWrt-environment which I didn’t get in the official OM-builds.
I tried to figure out what exactly is causing the exception on the OpenWrt-target and created a minimal program which raises it:

You don’t have to know what’s <tichy> and its <Item> class, nor what <issubclass> is doing exactly – just mind the return values.

root@OpenWrt:/# DISPLAY=:0 python
Python 2.6.1 (r261:67515, Jun  8 2009, 09:18:20)
[GCC 4.1.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> from tichy.item import Item
>>> issubclass(bool, Item)
False
>>> assert issubclass(bool, Item)
Traceback (most recent call last):
File “<stdin>”, line 1, in <module>
AssertionError

Ah, ok. On the OpenWrt-target the assert throws an exception, because <issubclass> returns <False>

So, logically, within the Openmoko-environment, the <issubclass>-statement must return <True> to not get assert raising an exception – but that’s not the case:

root@om-gta02:~# DISPLAY=:0 python
Python 2.6.2 (r262:71600, May 31 2009, 00:18:54)
[GCC 4.1.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> from tichy.item import Item
>>> issubclass(bool, Item)
False
>>> assert issubclass(bool, Item)
>>>

Huh – ok, let’s take a closer look here:

<issubclass (bool, Item)> is returning False, but <assert issubclass(bool, Item)> is not throwing an exception – that’s weird and caused me to do test the assert-statement in a very simple way:

root@om-gta02:~# DISPLAY=:0 python
Python 2.6.2 (r262:71600, May 31 2009, 00:18:54)
[GCC 4.1.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> assert False
>>>

That’s definitely not the expected result of assert.

So, why is that happening? Why python’s assert is just doing nothing?

Some research about that got me into this statement:

“[..]The current code generator emits no code for an assert statement when optimization is requested at compile time. Note that it is unnecessary to include the source code for the expression that failed in the error message; it will be displayed as part of the stack trace.[..]” – http://docs.python.org/reference/simple_stmts.html#grammar-token-assert_stmt

Let’s check that with a regular python-installation:

$ python
Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47)
[GCC 4.3.3] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> assert False
Traceback (most recent call last):
File “<stdin>”, line 1, in <module>
AssertionError
>>>
$ python -O # enable optimizations
Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47)
[GCC 4.3.3] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> assert False
>>>

Conclusion:
– some distributions are shipping their python-package configured for executing python-scripts with optimizations enabled
– asserts may not act as expected, means, they may don’t do anything when above is true
– i’m not using asserts anymore when my app is relying on asserts and I don’t know for sure which target/distribution my scripts are running on