HAL and external toolchain

While building an extended filesystem for my project, using an external toolchain/SDK, I found out that recent hal recipe in OpenEmbedded fails to build. It appears that hal uses a linux/input.h header file from glibc installation for its own configuration. Normally, glibc headers are installed in the staging area by corresponding -cross recipes. That's where hal recipe was trying to find it, which is not the case with the external toolchain:

EXTRA_OECONF += "--with-linux-input-header=${STAGING_INCDIR}/linux/input.h"

After some investigation and a short discussion on the oe-dev mailing list (with help from core developers Holger Freyther and Koen Kooi), I was able to create patches to the hal recipe, allowing it to be built by an external toolchain/SDK:

From 507ee230617603258736ecbcf4895de5429f8672 Mon Sep 17 00:00:00 2001
From: Denys Dmytriyenko 
Date: Mon, 10 Nov 2008 20:13:22 -0500
Subject: [PATCH] autotools.bbclass: allow autotools_do_configure to accept parameters and pass to oe_runconf


Signed-off-by: Denys Dmytriyenko 
---
 classes/autotools.bbclass |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/classes/autotools.bbclass b/classes/autotools.bbclass
index 82b5311..adb57f6 100644
--- a/classes/autotools.bbclass
+++ b/classes/autotools.bbclass
@@ -134,7 +134,7 @@ autotools_do_configure() {
  ;;
  esac
  if [ -e ${S}/configure ]; then
-  oe_runconf
+  oe_runconf $@
  else
   oenote "nothing to configure"
  fi
-- 
1.5.6.4

From 1a568f9490eb7bfd1060f47e2584d3ce41820b6b Mon Sep 17 00:00:00 2001
From: Denys Dmytriyenko 
Date: Mon, 10 Nov 2008 20:17:02 -0500
Subject: [PATCH] hal: Find and use the right linux/input.h to work with external toolchain


Signed-off-by: Denys Dmytriyenko 
---
 packages/hal/hal_0.5.11.bb |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/packages/hal/hal_0.5.11.bb b/packages/hal/hal_0.5.11.bb
index e93ad64..2b56fdf 100644
--- a/packages/hal/hal_0.5.11.bb
+++ b/packages/hal/hal_0.5.11.bb
@@ -1,8 +1,14 @@
 require hal.inc
 
-PR = "r1"
+PR = "r2"
 
 SRC_URI += " file://hal-right-input-h.patch;patch=1 \
              file://fix-configure.diff;patch=1"
 
-EXTRA_OECONF += "--with-linux-input-header=${STAGING_INCDIR}/linux/input.h"
+# The following code finds the right linux/input.h,
+# which also works with external-toolchain/SDK
+do_configure() {
+ linux_input_h=`echo "#include " | ${CPP} - | \
+  grep "linux\/input.h" | head -n 1 | awk -F '"' '{print $2}'`
+ autotools_do_configure --with-linux-input-header=${linux_input_h}
+}
-- 
1.5.6.4

DPF - my side project using OE

I have been looking into ways to utilize an old laptop, which been sitting on a shelf collecting dust for quite some time. One of the ideas was to convert it into a digital picture frame. There are many such projects explained on the Internet and specifically at Instructables. First, since the laptop had no hard drive in it, I needed a Compact Flash card with a CF-to-IDE converter. Luckily I had both and the next step was to think about the software.

The obvious choice was to use OpenEmbedded to build a small filesystem with necessary components to access my pictures from the fileserver (hopefully wirelessly...). That's one of the things I don't like about most of the DPF products available on the market - they can only load images from local storage or from flash cards. There are few WiFi-enabled picture frames, but they are limited and expensive. Since I have all of the required hardware components and necessary knowledge (I hope) to build a nice WiFi-enabled digital picture frame myself, I jumped right into this DIY project.

Since the laptop I was going to use is a PentiumIII based, I tried to build a minimal image for an i686 architecure. That's where I hit a snag - apparently, glibc refuses to build for any of the i686, pentiumpro or pentium3 architectures and it's been discussed a lot. Not sure about the actual reason it was never fixed in glibc, I was able to find a patch for eglibc from Khem Raj, which happened to apply to glibc as well. I have opened a bug ticket and emailed to the list (see below).

Now I'm able to build stuff for my future digital picture frame...

diff --git a/packages/glibc/files/march-i686.patch b/packages/glibc/files/march-i686.patch
new file mode 100644
index 0000000..0461603
--- /dev/null
+++ b/packages/glibc/files/march-i686.patch
@@ -0,0 +1,38 @@
+2007-02-15  Khem Raj  
+
+       * sysdeps/unix/sysv/linux/i386/sysdep.h: Re-define __i686.
+       * nptl/sysdeps/pthread/pt-initfini.c: Ditto.
+
+
+
+Index: sysdeps/unix/sysv/linux/i386/sysdep.h
+===================================================================
+--- sysdeps/unix/sysv/linux/i386/sysdep.h (revision 1469)
++++ sysdeps/unix/sysv/linux/i386/sysdep.h (working copy)
+@@ -29,6 +29,10 @@
+ #include 
+ #include 
+ 
++#if defined __i686 && defined __ASSEMBLER__
++#undef __i686
++#define __i686 __i686
++#endif
+ 
+ /* For Linux we can use the system call table in the header file
+  /usr/include/asm/unistd.h
+Index: nptl/sysdeps/pthread/pt-initfini.c
+===================================================================
+--- nptl/sysdeps/pthread/pt-initfini.c (revision 1469)
++++ nptl/sysdeps/pthread/pt-initfini.c (working copy)
+@@ -45,6 +45,11 @@
+ /* Embed an #include to pull in the alignment and .end directives. */
+ asm ("\n#include \"defs.h\"");
+ 
++asm ("\n#if defined __i686 && defined __ASSEMBLER__");
++asm ("\n#undef __i686");
++asm ("\n#define __i686 __i686");
++asm ("\n#endif");
++
+ /* The initial common code ends here. */
+ asm ("\n/*@HEADER_ENDS*/");
+ 
diff --git a/packages/glibc/glibc_2.6.1.bb b/packages/glibc/glibc_2.6.1.bb
index 1f72ff0..a6e2dd4 100644
--- a/packages/glibc/glibc_2.6.1.bb
+++ b/packages/glibc/glibc_2.6.1.bb
@@ -58,6 +58,7 @@ SRC_URI = "\
   file://glibc-use-isystem-include-fixed.patch;patch=1 \
   file://glibc-arm-no-asm-page.patch;patch=1 \
   file://armv4t-interworking.patch;patch=1 \
+  file://march-i686.patch;patch=1;pnum=0 \
 "
 
 # Build fails on sh3 and sh4 without additional patches

Recipe parsing issues and proxy settings

I guess it's a slow news day (or week)... From my OpenEmbedded-related work come 2 emails to the oe-dev mailing list:

1. One of the recent commits from Mamona developers, which is supposed to be isolated to their distribution, breaks bitbake's parsing for me and probably for other people. Apparently, bitbake parses through all the recipes in the tree (unless masked by BBMASK, I presume) regardless of whether the recipe is used by the current machine/distro configuration. So, if the recipe has parsing errors (like missing .inc file in this example), it will break for all the other people using the latest tree. Mental note to myself - when making changes to recipes, destined to public tree, make sure bitbake can at least parse them w/o errors... BTW, the issue got resolved quickly by good people of Mamona and I got a chance to chat with them on #oe IRC.

2. Trying to use OpenEmbedded in the corporate environment may be a painful experience. Most of the time it involves bypassing or working from behind a very strict firewall using some sort of proxy server. In many cases HTTP/FTP proxy is well established and employees are familiar with its settings. Same cannot be said for other types of transports, e.g. version control systems, like CVS, subversion and git. But it's an entirely different topic for some other time.
Anyway, on Linux/Unix systems it is standard to set http_proxy and ftp_proxy environment variables to point to respective proxy servers for corresponding type of network traffic. Those variables are used by most of the network applications, like browsers, fetchers and alike. Unfortunately, with the recent environment filtering feature in bitbake, those standard proxy setup variables are being filtered out and none of the sources can be fetched from behind a firewall/proxy. Hence, my proposal to add http_proxy and ftp_proxy variables to the white list.

Bluetooth A2DP stereo on Asus Eee PC

Since I fixed my Dial-Up Network setup issues, I was quite happy with my Asus Eee PC 901 Bluetooth capabilities. It works with my BT mouse and tethers with my cellphone over BT as well.

The next I wanted to use my Plantronics Voyager 855 stereo headset, but quickly found out the required A2DP stereo profile is not supported by the standard AzureBT Bluetooth application, shipped with EeePC 901. There are instructions on the Net to make A2DP work with many Linux media players, like xine & mplayer, but those involve installing the BlueZ stack (like I explained in the other post) and configuring ALSA output for it.

I guess, I'll leave it for later to make it work, when I have more free time (is there such thing, as more free time?)...

Back from MontaVista Vision 2008

I'm back from MontaVista Vision 2008 Embedded Linux Developers Conference. It was the second Vision Conference and I think this time it was better than the last one.

It has been interesting 2.5 days in downtown San Francisco (even though I didn't have time to peek my nose out of the hotel). But there is almost nothing to report - it was good overall, but nothing too specific to single out.

I liked the remote debugging session by one of the MontaVista guys, where he demonstrated techniques to remotely access the EVM/test-board on the testbench over the serial/ppp/telnet, power it on/off, reboot and even monitor it with a network camera.

Another interesting moment happened to me when I suddenly became perceived as an OpenEmbedded Guru (which I'm not - I'm still learning), when we were discussing different approaches to system builds during one of the birds-of-a-feather sessions and I happened to have the most successful and in-depth experience with OE out of the whole audience. Mind you, it was a Corporate Conference, hence not many people from the community. Contrary to the Embedded Linux Conference, which I attended in April, where there were many people from the community, including the OpenEmbedded one.

Asus Eee PC Bluetooth troubles

So, playing with my new toy and trying out things to make sure everything works before leaving for the conference. Got Bluetooth mouse paired with my Eee relatively easy, but hit a snag tethering it to my AT&T Tilt smartphone through the standard Dial-Up Network configuration...

Unfortunately, the Bluetooth app shipped with Xandros on 901 series is AzureBT (see on the right, click to zoom), which maybe very user-friendly with all the buttons and menus, but hard to debug, as it shows very little info when something fails. Plus, it does not use the standard Linux BlueZ stack and apps - i.e. it comes with own BT kernel modules and there are no HCI tools available from the command line, AFAIK.

Interestingly, all the forums and message boards are filled with instructions and tips on using the BluZ stack and hciconfig and hcitool commands, even for Asus Eee PCs. Which may be applicable to other Eee models, but not to 901. It is possible, though, to get the BlueZ working by installing bluez-utils and libbluetooth2 packages. Eee 901 even comes with all the necessary kernel modules, but they are just renamed out of the way of AzureBT - net/bluetooth/bluetooth.2.6.21.4.ko and drivers/bluetooth/hci_usb.2.6.21.4.ko, which need to be renamed or symlinked to their proper names.

After figuring all that out and especially the difference between BlueZ-way and AzureBT-way, I decided to get to the root cause of my problem of failing to establish a DUN connection with my phone. As it appeared the Bluetooth link to the phone was not the actual issue here - it was failing to make a logical connection to the ISP, i.e. the cellular provider access point (APN). As DUN runs PPP to establish a Point-to-Point connection with an APN, I had to enable pppd debugging (debug and kdebug settings in the /etc/ppp/options file), start SysLog sysklogd daemon and look at the log messages in /var/log/ppp/ to find out that AT&T/Cingular APN didn't want to authenticate itself to my client. Changing auth line in /etc/ppp/options to noauth effectively fixed the issue and I was able to use my AT&T Tilt as an HSDPA 3.5G modem!

New toy in time for my trip to Vision

As I was getting ready to go to the Vision Conference, I got myself a new business tool (or should I say a new toy?) - Asus Eee PC netbook. The model is 901 with 8.9" screen, 20GB SSD, 6-cell battery and Xandros Linux preinstalled.

The motivation was to have a small, lightweight and long-lasting notebook to use during business trips - you know, while sitting at the airport, on the plane, or in the middle of some boring conference session (hopefully there will be none during this year Vision).

Thus, the requirements:

• no moving parts - 20GB SSD and can be extended with SDHC cards (16GB max these days).
  
• small, but useful screen - previous generation 7" screen had too low resolution of 800x480, while bigger 10" screen has the same resolution of 1024x600 as 8.9".
  
• almost 6 hours of battery life.
  
• also comes with 802.11n and Bluetooth, which I plan to use for tethering to my cellphone, when not near the hotspot.

And being able to put it in my jacket's pocket beats carrying around my old big and heavy Precision M60 notebook, which Dell used to call a "mobile workstation" due to its size, weight and "used-to-be" powerful performance.

Or maybe the main reason is that I love playing with new gadgets. Anyway, it is certainly good to be able to justify getting myself a new toy... :)