Canonical Voices

Posts tagged with 'ubuntutouch'

Matt Fischer

This week I’ve been hacking some of the initrd scripts in Ubuntu Touch and I thought that I’d share some of the things I learned. All of this work is based on using Image Update images, which are flashable by doing phablet-flash ubuntu-system. First, why would you want to do this? Well, the initrd includes a script called “touch” which sets up all of the partitions and does some first boot migration. I wanted to modify how this process works for some experiments on customizing the images.

Before getting started, you need the following packages installed on your dev box: abootimg, android-tools-adb, android-tools-fastboot

Note: I was told after posting this that it won’t work on some devices, including Samsung devices, because they use a non-standard boot.img format.

Getting the initrd

The initrd is inside the boot.img file. I pulled mine from here, but you can also get it by dding it off of the phone. You can find the boot partition on your device with the following scriptlet, taken from flash-touch-initrd:

for i in $BOOT; do                                                              
    path=$(find /dev -name "*$i*"|grep disk| head -1)                           
    [ -n "$path" ] && break                                                     
echo $path

Once you have the boot.img file by whatever means you used, you need to unpack it. abootimg is the tool to use here, so simply run abootimg -x [boot.img]. This will unpack the initrd, kernel and boot config file.

Unpacking and Hacking the initrd

Now that you have the initrd, you need to unpack it so you can make changes. You can do this with some cpio magic, but unless you have a UNIX-sized beard, just run abootimg-unpack-initrd . This will dump everything into a folder named ramdisk. (UNIX beard guys: mkdir ramdisk; cp initrd ramdisk; cd ramdisk; cat initrd | gzip -d | cpio -i)

To make changes, simply cd into ramdisk and hack away. For this example, I’m going to add a simple line to ramdisk/scriprts/touch. My line is

echo "mfisch: it worked!" > /dev/kmsg || true

This will log a message to /var/log/kern.log which can assist us to make sure it worked. Your change will probably be less trivial.


Repacking the initrd is simple. To repack, just run abootimg-pack-initrd [initrd.img.NEW] Once you do this you’ll notice that the initrd size is quite different, even if you didn’t make any changes. After discussing this with some people, the best I can figure is that the newly packed cpio file has owners and non-zero datestamps, which make it slightly larger. One clue, when compared to mkinitramfs, abootimg-pack does not use the -R 0:0 argument and there are other differences. If you want to do this the hard way, you can also repack by doing: cd ramdisk; find . | cpio -o -H newc | gzip -9 > ../initrd.img.NEW

Rebuilding the boot image

The size change we discussed above can be an issue that you need to fix. In the file bootimg.cfg, which you extracted with abootimg -x, there is a line called bootsize. This line needs to be >= the size of the boot.img (not initrd). If the initrd file jumped by 4k or so, like mine did, be sure to bump this as well. I bumped mine from 0×837000 to 0×839000 and it worked. If you don’t do this step, you will wind up with a non-booting image. Once you correct this, rebuild the image with abootimg:

abootimg --create saucy-new.img -f bootimg.cfg -k zImage -r initrd.img.NEW

I’ve found that if your size is off, it will sometimes complain during this step, but not always. It’s best to check the size of saucy-new.img with the line you changed in bootimg.cfg at this point.

Flashing and testing

To flash the new boot image, reboot the device and use fastboot.

adb reboot bootloader
fastboot flash boot saucy-new.img

Use the power button to boot the device now.

Once booted you can go check out the kern.log and see if your change worked.

Aug 13 16:11:04 ubuntu-phablet kernel: [    3.798412] mfisch: it worked!

Looks good to me!

Thanks to Stephane Graber and Oliver Grawart for helping me discover this process.

Read more
Matt Fischer

The past few weeks I’ve been on loan to work on Ubuntu Touch, specifically the power daemon, powerd. Seth Forshee and I have been working to enhance the power daemon so that system services can interact with it to request that the device stay active, that is, that the device not suspend. The initial round of this work is complete and is landing today. (Note: There is a lot of low-level kernel interaction stuff landing in the code today too, that is not covered here)

What’s Landing

What’s landing today allows a system service, talking on the system bus, to request the Active system power state. We currently only have two states, Active and Suspend. When there are no Active state requests, powerd will drop the state to Suspend and suspend the device. This is best illustrated by showing how we use the states internally: For example, the user activity timer holds an Active state request until it expires at which point the request is dropped. The system then scans the list of outstanding state requests and if none are left, it drops the system to Suspend and suspends the system. Pressing the power button works in the same way, except as a toggle. When the screen is on, pressing the power button drops an active request, when off, it makes an active request.

For now, this ties screen state to system power state, although we plan to change that later. There is no way currently to request a display state independently of a system state, however that is planned for the future as well. For example, a request may be made to keep the screen at a specified brightness.

The API is subject to change and has a few trouble spots, but is all available to look at in the code here. Taking a look at the testclient C code or will best illustrate the usage, but remember this is not for apps, it is for other system services. The usage for an app will be to request from a system service via an API something like “playVideoWithScreenOn()”, and then the system service will translate that into a system state request.

Trying it Out

If you want to play with it on your phone, use gdbus to take an active state request and you can block system suspend. You will need to install libglib2.0-bin on your phone if not already installed.

# request active state from PID 99 (a made-up PID). This returns a cookie, which you need to later drop the request. The cookie here is “1″

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path\
   /com/canonical/powerd --method com.canonical.powerd.requestSysState 1 99
[sudo] password for phablet: 
(uint32 1,)

show the outstanding requests.

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path /com/canonical/powerd --method com.canonical.powerd.listSysRequests
([(':1.29', 99), ('internal', 36)],)

now we pass in the cookie we received earlier and clear our request

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path /com/canonical/powerd --method com.canonical.powerd.clearSysState 1

recheck the list

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path /com/canonical/powerd --method com.canonical.powerd.listSysRequests
([('internal', 36)],)


If you want to see everything that is going on, check the powerd log file. sudo tail -f /var/log/upstart/powerd.log. For now we have it logging in debug mode, so it will tell you everything.

But My Device Isn’t Suspending

Even though we request suspend, we may not get to suspend, because it appears that at least on some devices (Nexus4 and maybe others) Android’s sensor service is holding a wakelock. We are also working on this issue.

<6>[ 1249.183061] lm3530_backlight_off, on: 0
<6>[ 1249.185105] request_suspend_state: sleep (0->3) at 1249179158043 (2013-05-21 16:38:57.769127486 UTC)
<4>[ 1249.185441] [Touch D]touch disable
<4>[ 1250.217488] stop_drawing_early_suspend: timeout waiting for userspace to stop drawing
<3>[ 1250.244132] dtv_pipe is not configured yet
--> <6>[ 1250.248679] active wake lock sns_periodic_wakelock
<6>[ 1250.248710] PM: Syncing filesystems...
<6>[ 1250.329741] sync done.

Next Steps

We have a bunch of stuff left to do here, the first obvious one is that using a monotonically increasing int for the cookie is not a great plan, so we will switch that to something like a UUID. We also need to send out dbus signals when the system goes into suspend so that services can react. We need to clean-up some of the dbus code while we’re doing that. Finally we plan on implementing display state requests using a similar model to the power state requests. Throughout all of this we need to start integration with the rest of the system.

Read more