Category Archives: All

Some more smartbook internals (big pictures!)

As requested I took my quality piece of tablet apart again to make some more pictures (especially of the daugtherboard). This time I did not downscale them to 800×600, so beware of the 5 megapixels!

This is the backside of the daugtherboard, the “press-on” connector connects to the frontfacing camera. Sticking out from below the battery is the ribbon cable going to the mainboard.

The daughterboard with the ribbon cable to the mainboard removed.

The ribbon cable going from the mainboard to the daughterboard is below the glued-in battery.

Anything else you want to see? Please don’t make me remove the battery…. ;-)

Parrot AR.Drone linux internals

Finally I got my hands on a Parrot AR.Drone! 299 Euros bought me a wifi-pilotable quadro-copter with linux inside. It is marketed as a drone which is controlled by an iPhone app. However there is a demo Android app (which i did not test, yet) and the control protocol is documented (plain old AT commands). :-)

After making a few first flight attempts (using my brothers iPad) it was about time to take a closer look at the embedded linux stuff inside the drone. Not wanting to tear down the drone (yet!) and search for a serial interface, I decided to take a shot at the wifi.

The communication between the iP(ad|od|hone) app and the drone is carried out using an unencrypted adhoc wifi. What a great secure concept…. So, I hooked up an Asus wifi ap (running openwrt) to the adhoc wifi and gave nmap a try:

Interesting ports on
Not shown: 65532 filtered ports
21/tcp open ftp
23/tcp open telnet
2049/tcp closed nfs
MAC Address: 00:26:7E:30:B5:C8 (Unknown)

Yep, it’s sporting an open telnet. And (you might already have guessed it) it drops you to a root shell without asking for a password. I am expecting to see a “Drone-be-gone” app in the appstore or market place very soon… ;-)
Probably all you need to do is to kill the closed source control binary named “programm.elf” or just type “reboot” if you see one of those drones fly by. And down it will go. Again, splendid security! :-)

So, let’s have a looksy at the CPU:

Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 233.47
Features : swp half thumb fastmult edsp java
CPU implementer : 0×41
CPU architecture: 5TEJ
CPU variant : 0×0
CPU part : 0×926
CPU revision : 5
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 32768
I assoc : 4
I line length : 32
I sets : 256
D size : 16384
D assoc : 4
D line length : 32
D sets : 128

Hardware : Mykonos Parrot platform
Revision : 0904
Serial : 0000000000000000

and the 128 MB memory:

MemTotal: 126036 kB
MemFree: 105472 kB
Buffers: 0 kB
Cached: 3404 kB

The drone has an Atheros AR6000 wifi. Both cameras (front and bottom) are exposed ad V4L devices. And we are running a 2.6.27 kernel:

Linux myhost #1 PREEMPT Fri Jul 2 15:23:06 CEST 2010 armv5tejl GNU/Linux

So, it’s a great device for playing/hacking at a good price! :-) But, the total lack of security (open wifi, open root shell) is really bad for a product that is pushed to average-joe consumers through major electronic retail stores!

Smartbook Surfer

Marktkauf (a German supermarket chain) sells a stripped down version of the Smartbook Surfer ( It was quite difficult to get my hands on one of these. Because there is not a single Marktkauf in Berlin one of our poor trainees had to go out of Berlin (by train….).

The bad news first, it’s a pretty disappointing piece of kit. Even the online shop of Marktkauf disagrees with the printed Marktkauf commercial about the number of USB ports, etc. Here are the actual specs of the device i received:

160 MB RAM (not 256 MB, although there are two 128 MB DDR2 RAMs), 1 x miniUSB (not 2x), 1 x microSHDC slot (not 1x miniSD), 1 x miniHDMI (not 1 x HDMI), 1280×720 HDMI out (not 1920×1080 HDMI out), 720p Videoplayback (no 1080p), 2GB Flash but only around 1.4 GB are usable as internal storage (the device itself only shows 300 MB available to the user)

It runs Android 2.1, but it is really slow (what did you expect from a ARMv6 cpu?). The CPU should be running at 720Mhz which i cannot confirm yet. To dmesg it looks like 500 Mhz: “### CORE CLOCK (500000000 Hz), BUS CLOCK (166000000 Hz) ###”.

And “cat /proc/cpuinfo” says pretty much the same:

Processor       : ARMv6-compatible processor rev 6 (v6l)
BogoMIPS        : 499.71
Features        : swp half thumb fastmult vfp edsp java
CPU implementer : 0×41
CPU architecture: 7
CPU variant     : 0×0
CPU part        : 0xb76
CPU revision    : 6
Hardware        : Telechips TCC89/91/92XX Demo Board
Revision        : 0000
Serial          : 0000000000000000

The “touch”screen should be renamed to “press”screen because you have to press pretty hard to get it to recognize your input.

The builtin speaker is plain crap! It sounds awful, the headphones are fine though….Until! the device went to sleep for the first time, afterwards you will only hear very unpleasant highpitched static! Which really hurts when you have the headphones in use…. :-(

It features a frontfacing camera. You might “Wohooo!” first, but then you find out that you can only take photos with it or make black (not black and white!) videos with it. Then you think about….video calling…and install Fring..just to be told that because of device limitations you cannot make video calls.

Softwarewise it doesnt get much better. Quite often you are greeted by the “Force close” dialog. The tablet comes with a Skype lite beta client installed which unfortunately does not fill the full screen. Did maybe somebody rip it from some phone? ;-)

But after all the software situation is a good thing! Mainly because when you connect to the device with adb you are ROOT! Which is quite nice because you can access anything on the device. That way i was able to copy the to my Nexus One and install it. :-)

Of course it is a Skype lite (meaning calls with cost credits and go over gsm) but chatting seems fine. UNTIL…you get a chat message while the app is not running in foreground. Then skype eats 100% cpu and freezes the phone, forcing you to take out the battery.  Exactly the same thing happens on the tablett, skype rockets to 100% CPU making it even slower.

I would not recommend this tablet to anybody who wants to actually use it! For playing and hacking it’s fine though. :-)

Some things I noticed while testing BRIstuff for * 1.4.31

During the last week i spent a lot of time debugging Asterisk 1.4.31 (BRIstuffed and vanilla). The locking “model” is really … well…let’s say “interesing”. Different threads lock mutexes in different order at quite a few places, which would normally result in insta-deadlocks. This is where the  deadlock avoidance (lock.h) kicks in.

When * fails to aquire a lock (with “ast_mutex_trylock”) while it is holding another lock, it will unlock the held lock, sleep for 1 microsecond and re-lock the lock it held before. This loops until it finally manages to lock the first lock:

while (ast_mutex_trylock(&lock1)) {



Oh, yes, sometimes it NEVER aquires the first lock! Which turns this “avoided deadlock” into a 100% cpu hog! And it makes it so much harder to actually find a race condition in the code…

In case you are wondering why your D channels sometimes go down for no reason (but might recover after some time) or why your Asterisk process is eating all your CPU cycles although it is only pushing very few calls, then you might have hit an “avoided deadlock”. You will mostlikely experience a degrading voice quality in this case, too.

If you happen to run Asterisk with realtime scheduling priority then your userspace will most likely be gone! You can still ping your machine but cannot login neither remotely nor locally. No, your kernel did not crash, also neither your RAM is dodgy nor your shiny quadBRI card. ;-)

I managed to “fix” some places in chan_dahdi which used the wrong locking order, but there are still a few remaining places which will need much testing after the locking order has been resolve, for example:

If a DAHDI channel receives events from the ISDN, it will have the pri->lock aquired and then will try to aquire the pvt->lock and channel->lock. On the other hand if the Asterisk core calls a function (ast_answer, ast_hangup…) on a DAHDI channel it will call it with the channel->lock locked and will try to lock the pvt->lock and then the pri->lock .

When both things happen at the same time we would have a deadlock (without the “deadlock avoidance”). With the “deadlock avoidance” there is a chance to create an infinite loop. If the Asterisk system is not pushing many calls then the probability of such a loop increases significantly because there will not be many other threads “disturbing” the steady timing of the two threads (they both always sleep for 1 microsecond and most likely will always be scheduled in the same order!). On a loaded Asterisk system the probability of such an event is much lower.

Maybe it might be a good idea to add a little randomness to the sleeping interval. For development and testing I will remove the “while-try-lock” loops and use the deadlocking regular ast_mute_lock function instead.