Kernel Testing News 11/30/2018

Posted: November 30, 2018 in Uncategorized

Nov 26th saw the release of 4.4.165, 4.9.141, 4.14.84 and 4.19.4

For these LTS kernel versions, results were reported upstream, no regressions were found.

2018-11-26: Rafael Tinoco – bug 4043 – Asked Greg to backport a fix for v4.4, Sasha forwarded to the mm list.

For Android Kernels, regressions were detected.


  • 4.14.84 + HiKey boot regression – observed in with 9.0 and AOSP
  • 4.4.165 Regression:
    VtsKernelSyscallExistence#testSyscall_name_to_handle_at – Unknown
    error: test case requested but not executed.
    VtsKernelSyscallExistence#testSyscall_open_by_handle_at – Unknown
    error: test case requested but not executed.
    VtsKernelSyscallExistence#testSyscall_uselib – Unknown error: test
    case requested but not executed.

No Others Regressions: 4.4.165 and 4.9.141 on Android 9.

X15: 4.14.84 + O-MR1 – Baselining activity has been particularly effective over the past two weeks, dropping the number of errors from 65 failing tests to 16 as of today. That’s really good progress towards setting a clean baseline.

Bug 4033  Sumit has been looking at the failing CtsBluetoothTestCases android.bluetooth.cts.BluetoothLeScanTest#testBasicBleScan and android.bluetooth.cts.BluetoothLeScanTest.testScanFilter failures.

These tests both pass across all kernels with 8.1. They however fail with both 9.0 and AOSP. Looking at historical AOSP results it appears that failures there started approx in the September timeframe.

Last, successful test builds and test boot to UI with 4.4.165 and 4.9.141 with Android 9) using the newly released clang-r346389 compiler.


Having been at Google IO 2018 I happened to be lucky enough to attend the “What’s new on ChromeOS.” session at the end of which they handed out not only groovy socks but also 75% off on Pixelbook.

During the session however Google had all sorts of things to say about enabling both Linux and Android development on ChromeOS. Now these are two things the world has needed and wanted for some time.

The Chromebook offer is for the midrange i5 based Chromebook. I received mine on Friday so I’ve had a few days with it.


Setting up to Android development, meaning having Android Studio running as well as being able to run/debug Android Apps running on the Chromebook wasn’t too hard to setup.

Instructions are here but they are wrong in a few spots.

First, do turn on developer unstable and turn on Linux. BUT in order to debug Android Apps via Android Studio, you need to then turn on developer mode on your Pixelbook (or other akin device). You can’t debug Android Apps over USB (yet) so really I view this as an essential step.

Developer mode of course wipes the device so yeah, takes a bit longer to get to the end goal. You’ll live. I’ll link to the ‘snarky’ guide because there’s reasons not to enable developer mode if you don’t know what you’re doing. Remember you JUST need to enable developer mode, nothing else from this guide.

With developer mode on, again, turn on Linux mode, and now follow the rest of the guide. When you get to the point where you need to Mount Linux Files, before you do that you need to enable ssh server first in the debian environment.

> sudo rm sshd_not_to_be_run

> sudo service ssh restart

Ok now go back to the guide.

Then when you get to the Android Studio part, make sure you download the current preview, 3.2. If you don’t you’ll end up in a world of frustration where your new shiny Pixelbook will be at great risk to you throwing it across the room.

That done, you’ll find App development is pretty darn smooth. I’ve pounded out a couple of simple apps this weekend and everything ‘just worked’.  I’ll note that your very first compile will take awhile. This is down to some gradle files getting downloaded in the background. In real world terms, my first “hello world” app took about 3 minutes to build. After that, more like a second or two.


Apple Watch and wearables thoughts

Posted: February 28, 2015 in Uncategorized

On March 9th will be the Apple event fully revealing the Apple watch. I don’t think we saw the full set of features that will be made available as part of the Apple watch.

Tim Cook mentioned the use of the Apple watch as a replacement car fob, thus this week.

It’s pretty widely known that the Watch Edition is going to cost a very significant amount of money given the gold involved. $10,000-$20,000 seems to be the current guess and frankly when one compares to other high end watches, this is normal.

Consider tho that consumer electronics have tend to be on a pretty aggressive replacement cycle. You’re not going to make inroads with your customers if next years model is supposed to replace the $10,000 or $20,000 watch you bought the year before. Sure if you can afford a $10,000 watch you might not care. Still, other high end watches really follow this same model. They are built to last. A person holds on to a Rolex for a long time. Apple knows this and they do pride themselves in customer service.

With the ARA project we’ve seen a move to components that can be upgraded/replaced over time. I wonder if we’re going to see something akin to this with the Apple Watch, especially for the Watch Edition if not even the lower end models. You might have to take your watch into an Apple store, but for this class of hardware, that doesn’t seem like to much to ask. See the S1 called out in the marketing materials.

If this happens, and it’s an if, the Android wearables will certainly need to catch up.

Even then, are we seeing a change in the consumer electronics market, one toward devices which can be hardware upgradable and built to last longer?

This would seem to be an important design characteristic for an operating system such as Android to find it’s way into other use cases.

There is an interesting article I ran across today. Entitled, “Why would anybody buy an Apple Watch?” the article,  asks an interesting question through the lens of history. In 2007, many predicted that the iPhone would fail and had plenty of data to back up their stories. All of these people were right. Based on the data available at the time, it should have been a complete utter failure. None of this data took into account the human condition. The experience of being exposed to a mobile device with converged functionality and a multi-touch display. People liked it and smartphones across the board evolved into a new way. How many years did it take Apple to get to the point?

Next week Linaro Connect begins. Many experts within the ARM ecosystem will assemble in Burlingame California to interact and set plans for the next 6 months of engineering activity. Our collective job is not to just predict the future, it is to implement it.

At the heart of Open Source development is the mantra of release early, release often. Apple does not do this. They work and work and work and work some more and eventually release something. Open Source on the other hand iterates quickly. We strive to hit the stage where the human condition can be exposed to a design and implementation as soon as possible and subject our work to the rigors of many eyes so that evolutionary dead ends don’t last long.

The longer you wait to release something, the larger your risk.

Member companies that join Linaro are at an advantage. Through their membership they live at the nexus point of good fast iterative upstream engineering united with technical leadership. Failure happens. The faster you can fail by exposing the code to experts, the more you lower your risk and the quicker, through iteration, get onto the right track. Our members in turn are first to receive the fruits of those labors for their future products.

At a website called kickstarter inventors bring their ideas and expose them to a marketplace where people evaluate and fund the promising inventions.

Linaro is like kickstarter but better for our member companies. The ideas flow in from our members and engineering teams, are discussed at Connect and even outside of Connect, great engineering happens and the promising becomes the next great thing. At kickstarter you don’t get to influence the design, in Linaro a member company does.

See you at Connect. It’s going to be a great week.

Back to Gentoo

Posted: July 12, 2014 in Uncategorized

Back in 2003 I became a gentoo developer. I had been using gentoo prior to that as my Linux distro since it had good amd64 hardware support pretty much out of the gate. I had pieced together an amd64 box and at the time I thought trying out a new Linux distro was a good idea.

Then, I worked really hard on getting ppc64 up and running. At that time, while you could run 64 bit kernels on Power and ppc64 hardware, the user space was pretty much all 32 bit.

Gentoo today in 2014 is still in my opinion a good distro. There are essentially two modes of operation where you either build a package at the time you install it, or you can install from binaries via

As an open source developer I treasure the ability to easily install and test anything from source. Further I very much enjoy the ability to change compilation options for fiddling -O3, -mtune etc options to test out new compilers and see how performance improvements in codegen is coming along. I find it a much better environment than Open Embedded.

For me, I’ve been adding arm64 support to gentoo and this will be my primary focus in my “copious spare time.”

Both the Samsung Gear Live and LG G Android Wear watches are first generation hardware and software implementations.  I don’t have a copy of either. They are about the cost of a dev board so in the grand scheme for a developer it’s not necessarily hard to justify the cost to leap in and get involved.

From the WSJ review by Joanna Stern it feels like as an industry we best roll up our sleeves and get to work optimizing:

Performance wise, the Samsung edged out the LG, which tended to stutter and lag. And for their bulk, both watches’ battery lives should be better. They had to be charged at least once a day in proprietary charging cradles.

Really when you think about it, this is far more than just a wearable problem, we’ve got to evolve mobile devices so a daily charge cycle isn’t the norm.


Linaro Mobile Group

Posted: July 8, 2014 in aarch64, android, linaro

I’m pleased to say I’ve taken on the responsibility to help get the newly formed Linaro Mobile Group off the ground. Officially I’m the Acting Director of LMG. In many ways the Group is actually old as advancement of the ARM ecosystem for Mobile has always been and continues to be a top goal of Linaro. What is happening is we’ve refined the structure so that LMG will function like the other segment groups in Linaro. Linaro has groups formed for Enterprise (LEG), Networking (LNG), Home Entertainment (LHG), so it makes perfect sense that Mobile was destined to become a group.

I am quite grateful to Kanta Vekaria for getting the LMG’s steering committee up and running. This committee, called MOBSCOM started last fall and will morph to be called LMG-SC, the SC of course being short for Steering Committee. Members of LMG are in the drivers seat, setting LMG direction. It’s my job to run the day to day and deliver on the goals set by the steering committee.

Mobile is our middle name and also a big term. For LMG, our efforts are largely around Android. This is not to say that embedded Linux or other mobile operating systems like ChromeOS aren’t interesting. They are. We have and will continue to perform work that can be applied across more than one ARM based mobile operating system. Our media library optimization work using ARM’s SIMD NEON is a very good example. Android is top priority and the main focus, but it’s not all we do.

It’s a great time to form LMG. June, for a number of years, has brought many gifts for developers in mobile with Apple’s WWDC, and Google I/O. Competition is alive and well between these two environments, which in turn fuels innovation. It challenges us as developers to continue to improve. It also makes the existence of Linaro all the more important. It benefits all our members to collaborate together, accomplish engineering goals together instead of each shouldering the engineering costs to improve Android.

Android 64 is a great example. We were quite excited to make available Android64 for Juno, ARM’s armv8 reference board as well as a version for running in software emulators like qemu. We also did quite a bit of work in qemu so that it could emulate armv8 hardware. The world doesn’t need 20 different Android 64 implementations. The world DOES need one great Android 64 and in this way the collaborative environment in and around Linaro is important. While the 06.14 release of Android64 for Juno by Linaro is just a first release with much to do yet, things are on track for some great products by our member companies in the months ahead.

Stay tuned!