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... :)

MontaVista Vision 2008 Embedded Linux Conference

Next week I will be at MontaVista Vision 2008 Embedded Linux Conference in San Francisco. Bill will be giving his keynote speech on Friday. Jason also has a session on Friday.

See you there!

Getting even more dangerous with pstage

In my previous post I explained why and how to setup your build environment to have deploy and pstage directories outside the temp directory of a standard OE build. It works fine for building a filesystem, but when it comes to building a kernel or a bootloader, it brakes. After spending some time debugging this issue I submitted a bug report and followed up on the oe-dev mailing list. Below is the full text of my post.

I just submitted a bug report #4580, but wanted to follow up here as my description/fix maybe controversial or at least touches the low-level stuff.

Here is the description from the ticket:

When DEPLOY_DIR is configured to be outside of TMPDIR, building a kernel breaks, as cp cannot copy a file into itself:

cp: `/OE/deploy/glibc/images/omap3evm/uImage.bin' and `/OE/deploy/glibc/images/omap3evm/uImage.bin' are the same file

What happens is inside the do_deploy() function of the kernel.bbclass it calls package_stagefile_shell() with the uImage binary in DEPLOY_DIR as a parameter:

package_stagefile_shell ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE_BASE_NAME}.bin

That function is supposed to save a copy of the file in the staging directory (packaged-staging magic):

package_stagefile_shell() {
    if [ "$PSTAGING_ACTIVE" = "1" ]; then
        srcfile=$1
        destfile=`echo $srcfile | sed s#${TMPDIR}#${PSTAGE_TMPDIR_STAGE}#`
        destdir=`dirname $destfile`
        mkdir -p $destdir
        cp -dp $srcfile $destfile
    fi
}

The problem there is it substitutes (sed) TMPDIR with PSTAGE_TMPDIR_STAGE in file's path. It works if DEPLOY_DIR is inside TMPDIR, but the path remains the same if otherwise, leading to the mentioned error.

The function above is a shell counterpart of the python package_stagefile(). I grepped both of them and it appears the python function is used inside the package.bbclass to do some actual staging, while the shell function is only used in recipes for kernels and bootloaders (u-boot, x-load) and is always called with files in DEPLOY_DIR.

So, changing above sed command to:

sed s#${DEPLOY_DIR}#${PSTAGE_TMPDIR_STAGE}#

makes it work and doesn't seem to break anything else for me. I think the function maybe renamed to package_stagefile_deploy() to reflect its purpose, but that would require changes in several recipes.

I'm attaching the actual patch for review. It works for me, but I'm not sure how correct it is, so I'm asking here. Thanks.

Koen thinks my "patch is a step in the right direction", whatever that means... :)

Getting dangerous with packaged staging

As part of my work on a custom OE-based SDK for our platforms and the requirement to cut the initial build time, I was looking into packaged staging feature of OpenEmbedded. The basic concept is to package first-time built binaries, libraries etc. from the staging area of temp directory into ipkg (or deb) form and reuse them to populate the staging area back when temp directory was blown away, significantly reducing the "build from scratch" time later on.

This feature needs to be enabled by

INHERIT += "packaged-staging"

Which is default in Angstrom. And deploy/pstage directory needs to be preserved from being erased along with temp, which is not done automatically, relying on a user to do the content management on his own. So, by default packaged-staging.bbclass is configured to install ipkgs in the deploy/pstage directory, which is inside the temp directory:

DEPLOY_DIR_PSTAGE ?= "${DEPLOY_DIR}/pstage"

As the variable is conditionally assigned, it can be overwritten in the local.conf file to have the pstage outside the deploy and temp directories, automatically preserving packaged staging:

DEPLOY_DIR_PSTAGE = "somewhere/else/pstage"

The logical next step is to have the complete deploy directory outside of the temp as well. Unfortunately, Angstrom has it hardcoded in the conf/distro/include/angstrom.inc file like this:

DEPLOY_DIR = "${TMPDIR}/deploy/${ANGSTROM_MODE}"

So, in order to "free up" deploy from the tyranny of temp directory, the above file needs to be overlayed.

This takes care of fast consecutive "from scratch" builds by reusing previously built files from pstage. It especially makes sense to save time on rebuilding native, cross and sdk packages, as they usually don't change for regular users, who develops applications for a target platform. But what can be done to speed up the initial build time? Can those native, cross and sdk pstage packages be shared among users?

Apparently, it's not that easy. To provide controlled environment, many of those native and cross apps are built with hardcoded absolute path to their location in the staging area, so they won't interfere with similar system apps. Thus, implying the per-user, per-project naming rule and making sharing pstage contents between users almost impossible. This rule is specifically handled by the packaged-staging.bbclass in the following code:

# These classes encode staging paths into the binary data so can only be
# reused if the path doesn't change/
if bb.data.inherits_class('native', d) or bb.data.inherits_class('cross', d) or bb.data.inherits_class('sdk', d):
    path = bb.data.getVar('PSTAGE_PKGPATH', d, 1)
    path = path + bb.data.getVar('TMPDIR', d, 1).replace('/', '-')
    bb.data.setVar('PSTAGE_PKGPATH', path, d)

One way to solve it, is to set the staging area path to be the same for all users, say in the global /tmp directory. But that may lead to problems if more than one user tries to do a build (multi-user environment) or the same user does more than one build at the same time (parallel build from different project directories)... So, this proves to be doable, but needs to be handled carefully.

Stay tuned...

Cleaning up old hacks in gcc

Now, since glibc has been fixed properly to access GCC header files in include-fixed directory, there is no reason to keep old hacks and workarounds in corresponding gcc recipes. The recipes for upstream GCC were cleaned by Khem in his commit, but CodeSourcery recipes were left behind.

It is definitely a trivial patch and probably not worth mentioning here, but I had Bugzilla ticket #4560 opened with the following patch:

diff --git a/packages/gcc/gcc-cross-initial_csl-arm-2007q3.bb b/packages/gcc/gcc-cross-initial_csl-arm-2007q3.bb
index 99656db..c9f03a7 100644
--- a/packages/gcc/gcc-cross-initial_csl-arm-2007q3.bb
+++ b/packages/gcc/gcc-cross-initial_csl-arm-2007q3.bb
@@ -4,9 +4,3 @@ require gcc-cross-initial.inc
 S = "${WORKDIR}/gcc-4.2"
 
 EXTRA_OECONF += "--disable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap "
-
-# Hack till we fix *libc properly
-do_stage_append() {
- ln -sf ${CROSS_DIR}/lib/gcc/${TARGET_SYS}/${BINV}/include-fixed/* ${CROSS_DIR}/lib/gcc/${TARGET_SYS}/${BINV}/include/
-}
-
diff --git a/packages/gcc/gcc-cross-initial_csl-arm-2008q1.bb b/packages/gcc/gcc-cross-initial_csl-arm-2008q1.bb
index 99656db..c9f03a7 100644
--- a/packages/gcc/gcc-cross-initial_csl-arm-2008q1.bb
+++ b/packages/gcc/gcc-cross-initial_csl-arm-2008q1.bb
@@ -4,9 +4,3 @@ require gcc-cross-initial.inc
 S = "${WORKDIR}/gcc-4.2"
 
 EXTRA_OECONF += "--disable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap "
-
-# Hack till we fix *libc properly
-do_stage_append() {
- ln -sf ${CROSS_DIR}/lib/gcc/${TARGET_SYS}/${BINV}/include-fixed/* ${CROSS_DIR}/lib/gcc/${TARGET_SYS}/${BINV}/include/
-}
-
diff --git a/packages/gcc/gcc-cross-intermediate_csl-arm-2007q3.bb b/packages/gcc/gcc-cross-intermediate_csl-arm-2007q3.bb
index 114d983..5423626 100644
--- a/packages/gcc/gcc-cross-intermediate_csl-arm-2007q3.bb
+++ b/packages/gcc/gcc-cross-intermediate_csl-arm-2007q3.bb
@@ -4,9 +4,3 @@ require gcc-cross-intermediate.inc
 S = "${WORKDIR}/gcc-4.2"
 
 EXTRA_OECONF += "--disable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap "
-
-# Hack till we fix *libc properly
-do_stage_append() {
- ln -sf ${CROSS_DIR}/lib/gcc/${TARGET_SYS}/${BINV}/include-fixed/* ${CROSS_DIR}/lib/gcc/${TARGET_SYS}/${BINV}/include/
-}
-
diff --git a/packages/gcc/gcc-cross-intermediate_csl-arm-2008q1.bb b/packages/gcc/gcc-cross-intermediate_csl-arm-2008q1.bb
index 114d983..5423626 100644
--- a/packages/gcc/gcc-cross-intermediate_csl-arm-2008q1.bb
+++ b/packages/gcc/gcc-cross-intermediate_csl-arm-2008q1.bb
@@ -4,9 +4,3 @@ require gcc-cross-intermediate.inc
 S = "${WORKDIR}/gcc-4.2"
 
 EXTRA_OECONF += "--disable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap "
-
-# Hack till we fix *libc properly
-do_stage_append() {
- ln -sf ${CROSS_DIR}/lib/gcc/${TARGET_SYS}/${BINV}/include-fixed/* ${CROSS_DIR}/lib/gcc/${TARGET_SYS}/${BINV}/include/
-}
-
diff --git a/packages/gcc/gcc-cross-sdk_csl-arm-2007q3.bb b/packages/gcc/gcc-cross-sdk_csl-arm-2007q3.bb
index bc66b51..0e77b57 100644
--- a/packages/gcc/gcc-cross-sdk_csl-arm-2007q3.bb
+++ b/packages/gcc/gcc-cross-sdk_csl-arm-2007q3.bb
@@ -20,8 +20,3 @@ EXTRA_OECONF += " \
 CFLAGS = ""
 CXXFLAGS = ""
 LDFLAGS = ""
-
-# Hack till we fix *libc properly
-do_install_append() {
-        cp -a ${D}${gcclibdir}/${TARGET_SYS}/${BINV}/include-fixed/* ${D}${gcclibdir}/${TARGET_SYS}/${BINV}/include/
-}

gcc or glibc?

Here is one more story of running into another problem with OpenEmbedded toolchain/SDK feature.

When couple of weeks ago I built a gcc-4.3.1 based SDK (gcc-cross-sdk_4.3.1.bb recipe is being used in this case) and tried to use it to compile something else, I was getting the following error message about not finding limits.h header file:

/usr/include/limits.h:122:61: error: no include path in which to search for limits.h

It appears most of the OE-based SDK-providing distributions I know of (namely, OpenMoko and Poky) are based on older versions of gcc (4.1.2 at the moment for both of those mentioned). And they don't have this problem. In recent versions of gcc they've added a new include-fixed directory with some headers:

GCC trunk now has multiple internal headers directories, one containing the self-contained GCC-provided headers and one containing the (not self-contained but including libc's or a fixed version thereof) and the fixed headers; more such directories may be added in future.

So, I looked at the way non-SDK version of OE gcc-4.3.1 (gcc-cross_4.3.1.bb recipe used for that) solves this and found this hack:

# Hack till we fix *libc properly
do_stage_append() {
    ln -sf ${CROSS_DIR}/lib/gcc/${TARGET_SYS}/${BINV}/include-fixed/* ${CROSS_DIR}/lib/gcc/${TARGET_SYS}/${BINV}/include/
}

Trying to reproduce it in the SDK recipe as well, I ended up submitting a similar fix to Bugzilla and posted it on the oe-dev mailing list. Which brought up a short discussion about the proper fix in glibc and resulted in it being fixed properly by Khem Raj here.

Add CodeSourcery as OE SDK toolchain

In the previous post I mentioned about some issues I faced while working on the SDK feature of OpenEmbedded. One of them was the absence of the CodeSourcery toolchain from the SDK targets - all of them were upstream GCC-based, which for the most part is fine. But I have a specific requirement for my work to use CodeSourcery 2007q3 (as the most stable at this point) toolchain, and even more, the binary version of it...

While making it possible to build a minimal OpenEmbedded/Angstrom system using a binary CodeSourcery toolchain, I had to produce a CodeSourcery-based SDK with the OpenEmbedded, which required a new recipe to be added:

PR = "r0"

inherit sdk

require gcc-csl-arm-2007q3.inc
require gcc-cross-sdk.inc
require gcc-configure-sdk.inc
require gcc-package-sdk.inc

EXTRA_OECONF += " \
  --disable-multilib \
  --disable-libssp \
  --disable-libgomp \
  --disable-libunwind-exceptions \
  --disable-libmudflap \
  --with-mpfr=${STAGING_DIR_NATIVE}${layout_exec_prefix} \
  "

#We don't want i686 linux ending up in the CFLAGS_FOR_TARGET like this: -isystem/OE/angstrom-tmp/staging/i686-linux/usr/include
CFLAGS = ""
CXXFLAGS = ""
LDFLAGS = ""

# Hack till we fix *libc properly
do_install_append() {
        cp -a ${D}${gcclibdir}/${TARGET_SYS}/${BINV}/include-fixed/* ${D}${gcclibdir}/${TARGET_SYS}/${BINV}/include/
}

After testing and making sure it works, I opened up a Bugzilla ticket and started persuading OE developers to accept it in the development branch.

And eventually, after talking to Philip Balister on IRC, the patch was committed to the upstream.

The mystery of libgcc...

I've been playing with external-toolchain/SDK feature of OpenEmbedded for quite some time now. Apparently, the support is there, but in a less-than-perfect state, i.e. its broken in several places. Maybe some time later I will elaborate on other issues I faced and either fixed or worked around...

But for several hours today I was struggling with the problem of failing gcc-noemu, which shouldn't be even built, as nothing supposed to depend on it. While trying to trace down the dependency on this package, I noticed the following messages given by bitbake:

NOTE: multiple providers are available for runtime libgcc (gcc-noemu, gcc-cross);
NOTE: consider defining a PREFERRED_PROVIDER entry to match runtime libgcc

That's when I realized gcc-noemu is being built to satisfy runtime libgcc dependency. Unfortunately, the suggestion to define a PREFERRED_PROVIDER given by bitbake is misleading and I ended up wasting couple hours trying all possible combinations of that variable w/o success.

Long story short, external-toolchain.bb was missing definition of libgcc as one of the provided runtime libraries. Here is the fix for it:

diff --git a/packages/meta/external-toolchain.bb b/packages/meta/external-toolchain.bb
index ad30ff7..9c532fd 100644
--- a/packages/meta/external-toolchain.bb
+++ b/packages/meta/external-toolchain.bb
@@ -14,7 +14,7 @@ PROVIDES = "\
     virtual/libiconv \
     "
 
-RPROVIDES = "glibc-utils libsegfault glibc-thread-db libgcc-dev libstdc++-dev libstdc++"
+RPROVIDES = "glibc-utils libsegfault glibc-thread-db libgcc-dev libgcc libstdc++-dev libstdc++"
 PACKAGES_DYNAMIC = "glibc-gconv-*"
 PR = "r1"

Here is the corresponding bug report.

All id Software games 50% off!

Buy id Super Pack

I remember playing most, if not all, of those games, including little bit of Commander Keen (which was rather a scroller type of game, not a first person 3D shooter). Wolfenstein, Doom, Doom2, Hexen, Heretic, Quake... Right around second Quake was becoming popular I kind of lost interest and time to play 3D games, unfortunately. Later 3D shooters were getting more and more realistic, but less fun, IMHO.

Anyway, go grab some of them for prices ranging from $2.49 to $9.99 or a whole pack for just $34.99! Offer valid through this weekend only.

Time to start blogging?.. Again.

It seems everyone and their pet has a blog these days. For many years I thought starting my own would be unoriginal and waste of my free time, which I lack anyway.

But then I've been thinking lately, that blogging would help me in several ways - express myself, enhance my social and communication skills and gain some visibility, to name a few.

Come to think of it, I used to blog at the turn of the century, when blogging was not yet all the hype. It wasn't even yet called "blogging" back then. It was sort of a personal journal about my first experiences and impressions in the new country, as I just came in the US. I still have those early pages archived offline...

As a long-standing Open Source and Linux follower, developer and activist, I would try to stick to that topic in my posts, keeping personal matters and other offtopic issues to a minimum. I hope my posts will find their audience.

Anyway, please welcome the new/old member of the blogging community.