idle();

This post is a reminder about rabbit holes one goes down when working on technical problems. Some time ago, I received an Inforce IFC6410 to add to my testing while I modernize the thermal sensor driver found on many Qualcomm platforms. This is a fairly old Snapdragon 600 SoC and isn't being tested in any of the kernelci.org labs leading to a patch recently getting merged that broke the thermal sensor on the board. I figured I'd wire it up to my board automation setup - a glorified mess of an ATX PSU, a switchable USB hub and an 8-port relay - that automates the toggling of power and vbus to a board to allow for automated kernel flashing and testing. HW Lab automation - work in progress So I wired up the IFC6410, connected a USB-serial cable for console and added the requisite port numbers to my scripts to toggle power to the board when I built a kernel to test on that target. Except that the board didn't enter fastboot mode to flash a new kernel. The messa

mdz pointed me to Idea 24782 over at Ubuntu Brainstorm that urges the Ubuntu community to increase focus on making Ubuntu run longer on devices with batteries. I support the idea wholeheartedly. Since the advent of laptops and netbooks, users have wanted to stretch the battery to last that extra 15 minutes it'll require for them to finish up their email or their documents. In fact, the most popular idea ever on Brainstorm is about fixing suspend and hibernate. Unfortunately, it ended up becoming a whirlpool of several different ideas, albeit with a common theme - making the battery last longer . There are several things that can be done to make the battery on a mobile device last longer - some under user control, others under OS/firmware control and some others dependent on HW capabilities. I am going to attempt to summarize the various use profiles and what Ubuntu does (or can do) to prolong battery life in those profiles. Power management, when done right, should not requi

Sigh! I don't think I'm going to get the cross-compilation article right, ever! The repository has now moved to a Launchpad PPA . So, for Maverick, you can do the following: sudo apt-add-repository ppa:hrw/arm-cross-compiler sudo apt-get update sudo apt-get install gcc-arm-linux-gnueabi g++-arm-linux-gnueabigcc Eventually, the idea is to replace this PPA as well, because the cross-compiler will be available in Ubuntu.

It has been a while since my last blog post about developing for ARM platforms. We last looked at how to cross-compile the kernel. It is time to revisit that recipe. Linaro I've been working with Linaro for the last few months to improve the toolchain, kernel and other components of Linux plumbing on ARM. There is also work to refactor the partner BSPs so that they can co-exist peacefully i.e. single kernel source tree, single u-boot tree, etc. We're just getting started but you can see the status for the first Linaro release in November. Cross-compile toolchains One of the first things that an embedded project has had to do is roll their own toolchain. This is obviously wasted time and effort. Linaro is attempting to fix this problem by pushing fixes into gcc upstream and by providing a standard toolchain for ARM development. This toolchain will take advantages of features of the ARMv7 architecture (NEON acceleration, various performance optimisations, SMP support, etc.).

Do you have a touchscreen that isn't working in Ubuntu? We need your help! We are trying to get as many touchscreens working as possible for Karmic. Bug #317094 is attempting to collect hardware information about these them. As a first step, we'd like to enable the ones that can use the in-kernel usbtouchscreen driver. Do you have a touchscreen? Is it connected over USB? ( lsusb is your friend) Get the vendor and product id of the USB touchscreen (lsub) Load the usbtouchscreen module and add the new id to it through sysfs A made-up example follows (I don't have a touchscreen handy, sorry!) example output from lsusb Bus 005 Device 002: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader 0483 is the vendor id, 2016 is the product id sudo modprobe usbtouchscreen sudo sh -c "echo 0483 2016 > /sys/bus/usb/drivers/usbtouchscreen/new_id" Replace the vendor and product id with what you found from lsusb. If this makes your touchscreen work in Karmic, plea

So I have a laptop that I've been upgrading since Hardy (currently on Karmic Alpha) that I would like to boot faster. It has probably accumulated a lot of crufty daemons along the way that probably aren't being pre-loaded into memory. I picked up this tidbit from the fast boot expert . Add profile to your kernel command-line (at the grub prompt, press Esc e and then edit the line) . This will update your system's readahead file list after a lot of disk churn. On my machine, it sped up boot by only about 5 seconds, but YMMV. Also, if you have a machine or netbook with SSD (flash) disks, sreadahead might give you a boost. Again, apt-get install sreadahread is your friend . sreadahead also schedules profiling of the system every month-or-so, so it keeps those boot-essential programs in the readahead cache always.