Cover photo
Olof Johansson
Works at Google
Attended Luleå University of Technology
Lives in Belmont, CA
3,156 followers|1,889,634 views
Have him in circles
3,156 people
Douglas Parrish's profile photo
Roser Blasco Cantavella's profile photo
Johannes Grad's profile photo
Paul Tenuto's profile photo
Eduard Lukash (EdZas)'s profile photo
Reynaldo H. Verdejo  Pinochet's profile photo
Kar Dargo's profile photo
Tarun Gehlot's profile photo
Eric Chen's profile photo
Google ChromeOS. Mostly linux kernel stuff.
  • Google
    2010 - present
  • Agnilux
    2009 - 2010
  • Apple
    2008 - 2009
  • PA Semi
    2005 - 2008
  • IBM
    2000 - 2005
  • Effnet
    1997 - 2000
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Belmont, CA
Austin, TX - Luleå, Sweden - Skellefteå, Sweden
Swede in California
  • Luleå University of Technology
    1992 - 1998
  • Balderskolan
    1989 - 1992
Basic Information


Olof Johansson

Shared publicly  - 
Anker has announced USB-C products. Nice.

Also, I noticed Monoprice has started selling some cables and adapters. Currently it looks like it's the Google products but sold slightly cheaper than the play store.
USB-C is the latest form of USB connection technology. For the first time ever, USB-C provides power supply, data transfer and video display through one single connection. Compatible with the next generation of computers, tablets and smartphones, USB-C will soon become the main way we connect ...
Russ Dill's profile photo
I really want my N4 to hold out long enough for a phone with USB3.1 type C. I think it might not be till spring 2016 till serious contenders get released though.
Add a comment...

Olof Johansson

Shared publicly  - 
Maker Faire! Family today, myself tomorrow. More arts, crafts, and interactive stuff today in other words. :)
Ben Pfaff's profile photoBrandy Johansson's profile photo
Ah! Maybe Olof will see them. :)
Add a comment...

Olof Johansson

Shared publicly  - 
Christopher Friedt's profile photoVladimir Pantelic's profile photoVadim Bendebury's profile photo
And I am trying to port coreboot to it, I wish its SRAM was larger ;)
Add a comment...

Olof Johansson

Shared publicly  - 
It's a long way to go to get the device usable for tablet-type usage, but the exercise is still a useful one to do, to get an actual Android device functional with a mainline kernel going forward.

Right now, there's no easy way to run just the base Android patchset on a fully working device to make sure it works(!).

Nice work, and nice writeup.
===Running mainline kernels on a 2013 N7(flo)===

So I’ve been working on trying to get mainline kernel up and running on a Nexus 7(2013), and I figured I should document a walkthrough of my current progress, so others who are interested can reproduce this themselves (and help point out where I’m going wrong!)

I want to give credit to dTatham and his site which provided some key insights in the process that this walktrough includes. 

== An Early Short Cut ==

I think it’s a really useful process to learn how to build AOSP images for the Nexus7, but admittedly it takes a long time to download and build everything, and most folks probably will want to skip over that. For now we can get by w/o modifying userspace too much, so if you want to cheat, you can do the following and then skip over the Building AOSP section.

Visit the Nexus Factory Images site, follow the instructions for unlocking your Nexus7’s bootloader, and download the latest image for the Nexus7 (razor), untar the directory and flash it to the device:

Next up unzip the image-razor-<ver>.zip file and copy the boot.img:
$ unzip
$ mkdir ~/flo
$ cp boot.img ~/flo/boot.img.orig

Ok, now skip on down to the Building the AOSP kernel section!

== Building AOSP ==
No easy outs for you! Before we get to running mainline on a 2013 Nexus7, the first step is to build the current AOSP tree for the Nexus7. Most of this has been well documented on the Android website, which we’ll link to in the following.

Make sure your system has pre-requirements by following the instructions here:

Download the AOSP source by following the instructions here (This takes awhile):

NOTE: When running repo init, you’ll want to specify the branch to be the latest official branch, not master, since we want fewer moving parts to deal with:
$ repo init -u -b android-5.0.2_r1

While repo sync is running, you might open a new shell and start unlocking your device and getting the firmware images for the device:

Again, I recommend building the last official release, instead of master since there’s less moving parts. So I’d recommend grabbing the firmware binaries from the following link. But whatever you pick, make sure it matches the branch you used for repo init.

Start a build:

Here, you’ll want to run “lunch aosp_flo-userdebug” or pick aosp_flo-userdebug from the list if you run lunch w/o an argument.

Once the build is complete, you can flash the device using the instructions at the bottom half of here:

Reboot the device and make sure your system comes up and when you log in you see the expected release data in the “about tablet” screen in settings.

After you’re done here, make a copy of the boot.img file to modify in the future
$ mkdir ~/flo
$ cp <path to built AOSP source>/out/target/product/flo/boot.img ~/flo/boot.img.orig

== Building the AOSP Kernel ==
The AOSP build process you just went through uses a pre-built kernel image. As a first step here, to make sure you have a functioning workflow, we’re going to regenerate the kernel!

First, clone a vanilla kernel tree:
$ git clone git://
$ cd linux

For clarity, rename the origin branch to linus:
$ git remote rename origin linus

Next add the AOSP common and msm kernel tree:
$ git remote add common   $ git remote add msm   $ git remote update

Check out the appropriate msm kernel branch for the N7:
$ git checkout msm/android-msm-flo-3.4-lollipop-release

Configure and start a build:
$ export ARCH="arm"
$ export CROSS_COMPILE="arm-linux-gnueabi-"
$ make flo_defconfig
$ make -j24 zImage

Once the build is complete, we want to extract the original boot.img and insert the new kernel into it.
$ cp <path to kernel tree>/arch/arm/boot/zImage ~/flo/zImage.aosp
$ cd ~/flo
$ abootimg -x boot.img.orig
$ abootimg --create boot.img -k ./zImage.aosp  -r ./initrd.img  -f bootimg.cfg

Flash the image and reboot:
$ adb reboot bootloader
$ fastboot flash boot boot.img
$ fastboot reboot

Make sure the system comes up, and in the settings, about my tablet screen, in the kernel section, you should see your username and host in the description.

== Debug Tooling == 
So before we try to boot our own kernels, we’ll need some extra tooling to get things going.

First of all, mainline kernels won’t come up with graphics, or adb support, so we need a serial port.

CAUTION!!!: This is leveraging an undocumented feature on most Nexus hardware, and does so by placing voltage where it normally is not placed. I’m unsure what voltage levels are “safe” here, so consider yourself warned. This works for me on a number of nexus devices without issue, but I CANNOT PROMISE YOU WON’T DAMAGE YOUR SYSTEM by doing so.

First grab a 3.3v ftdi serial adapter. Note its really important you use a 3.3v adapter and not a 5v adapter. I’ve found some are incorrectly labeled, and I’d confirm with a multimeter before using.  Depending on which websites you read, some may say 3.3v is too much, but I’ve had the most success on various devices with 3.3v.

Then grab a TRRS headphone cable. Note, as opposed to standard headphone plugs (TRS) which only two insulative rings and 3 wires (left, right, ground), there should be 3 insulative rings on this sort of plug, which supports 4 wires (left, right, mic and ground lines).

And some male to male 1mm jumper cables:

Cut the headphone cable, and strip the 4 lines, and solder them to different colored jumper cables. You may need to use a multimeter to figure out which wires are which. You’ll want to identify them as the following Tip,  Ring 1, Ring 2, Sleeve.

I’d recommend the following jumper cable color mapping:
Tip(RX): Yellow
Ring 1(TX): Orange
Ring 2(GND): Black
Sleeve(V): Red

You’ll then want to plug those jumper lines into the ftdi serial adapter lines (be sure to confirm the color mapping on your ftdi serial adapter):
Ground(Black): Ring 2
3.3v(Red): Sleeve
TX(Orange): Ring 1
RX(Yellow): Tip

Plug the headphone jack into the Nexus7, and open a minicom session and connect to the /dev/ttyUSB<N> device and disable flow control.

Now this magic trick (usually called the “debug headphone uart”) works because on almost all Nexus devices since the Galaxy Nexus, there is a mux circuit that detects the voltage on the mic line and switches from being a headphone jack to connecting the wires to the device’s serial uart. Its very useful, and I wish more devices used the same trick!

Now when you reboot your nexus, you should see some bootloader information go by.

==Enabling Serial Debugging==
Now that we have a working serial port, lets enable it so we can actually watch the kernel logs go by.

Lets go back to our ~/flo directory where we extracted the previous boot.img file
$ cd ~/flo
$ abootimg -x boot.img.orig

Edit the bootimg.cfg and look at the cmdline string. Note that cmdline already has a console= argument!:
cmdline = console=ttyHSL0,115200,n8 androidboot.hardware=flo user_debug=31 msm_rtb.filter=0x3F ehci-hcd.park=3 vmalloc=340M

Now on the 2013 N7, the bootloader “eats” the first 26 characters of the cmdline and only passes the rest of the string along. This coincides with the console= argument, which I suspect was done for dubious security purposes (or possibly not wanting console messages to accidentally cause noise on the hardware muxer?). The solution here is to duplicate the console= argument in the string (here some extra arguments to increase verbosity & earlyprintk are also added):
cmdline = console=ttyHSL0,115200,n8 androidboot.hardware=flo user_debug=31 msm_rtb.filter=0x3F ehci-hcd.park=3 vmalloc=340M loglevel=7 console=ttyHSL0,115200n8 debug earlyprintk=serial,0x16640000,115200 verbose

Save the edited file to “bootimg-mod.cfg” and now reassemble the boot.img file:
$ abootimg --create boot.img -k ./zImage.aosp  -r ./initrd.img  -f bootimg-mod.cfg

And flash and boot the device:
$ adb reboot bootloader
$ fastboot flash boot boot.img
$ fastboot reboot

You should be able to watch the kernel boot log now stream over the serial line, and if you built userdebug AOSP images yourself even get a shell prompt once it has booted!

== Manually Rebooting the Device ==

Should you run into trouble and the device hangs and doesn’t boot. Hold the power-button down for ~10 seconds, the screen should power off. At that point, quickly press volume-down and hold it. If the system doesn’t immediately enter the fastboot prompt, push the power-button while continuing to hold down volume-down.

== Working with a Mainline Kernel==

Now we have a debuggable system, so we can start trying to bring up a current mainline kernel!

Moving back to the kernel tree, checkout Linus’ HEAD (for reproducibility, we’ll pick a well known tag, but HEAD should work):
$ cd <path to kernel tree>
$ git checkout v4.0

There is also a few small patches we’ll need, so to make it easy add my tree as a git remote:
$ git remote add flo-mainline
$ git remote update

Make the msm defconfig:
$ export ARCH="arm"
$ export CROSS_COMPILE="arm-linux-gnueabi-"
$ make qcom_defconfig

Add the following config values to the .config:

Unfortunately at the moment there are a few patches needed (available in my repo), to get things booted to mmc:
$ git cherry-pick 163a4169f98ef0867312fdf70b9389bea7831a8d
$ git cherry-pick 2255e422b9af4d9879556780902654fc64529528
$ git cherry-pick 4cd95d8572024c170096eb864eae2e451e5d6eb5

Build the kernel:
$ export ARCH="arm"
$ export CROSS_COMPILE="arm-linux-gnueabi-"
$ make oldconfig
$ make -j24 zImage
$ cp arch/arm/boot/zImage ~/flo/

Make a copy of the ifc6410 dts and build a dtb:
$ cp arch/arm/boot/dts/qcom-apq8064-ifc6410.dts   \
$ make qcom-apq8064-nexus7.dtb
$ cp arch/arm/boot/dts/qcom-apq8064-nexus7.dtb ~/flo/

== Creating an Image the Bootloader Will Work With == 
Because the bootloader assumes the atags are at a different address, and does not support device trees, one needs a bit of fixup code to move the atags up 2 megs and to append the dtb to the kernel file.
Get the fixup helper and build it:
$ cd ~/flo/
$ wget
$ gcc -c fixup.S -o fixup.o
$ objcopy -O binary fixup.o ~/flo/fixup.bin

Merge the kernel file together:
$ cd ~/flo/
$ cat ./fixup.bin ./zImage ./qcom-apq8064-nexus7.dtb > ./zImage.dtb

The newer kernel uses a different serial chardev name, so we need to edit the bootimg-mod.cfg file and tweak the second console= argument in the cmdline string, changing it from ttyHSL0 to ttyMSM0 (again, the first console= argument can be ignored, since the bootloader skips over it):

cmdline = console=ttyHSL0,115200,n8 androidboot.hardware=flo user_debug=31 msm_rtb.filter=0x3F ehci-hcd.park=3 vmalloc=340M loglevel=7 console=ttyMSM0,115200n8 debug earlyprintk=serial,0x16640000,115200 verbose

Rebuild the new boot.img:
$ abootimg --create boot.img -k ./zImage.dtb  -r ./initrd.img  -f bootimg-mod.cfg
$ adb reboot bootloader
$ fastboot flash boot boot.img
$ fastboot reboot

== A Few Last Fixups to the Initrd ==
The below are dirty hacks, which need to be properly addressed. Feel free to let me know of better ways of resolving these issues!

At this point, you should see the device reboot, but hang before it finds the proper partitions w/ the following error:

fs_mgr: Failed to mount an un-encryptable or wiped partition on/dev/block/platform/msm_sdcc.1/by-name/system at /systy...

This is happening because the dts we’re using results in the /dev/block/by-name/ path to change. So we need to edit the fstab paths to make this work:

First extract the initrd.img:
$ cd ~/flo/
$ mkdir initrd
$ cd initrd
$ cat ../initrd.img | gunzip | cpio -vid

Replace all instances of “msm_sdcc.1” with “soc” in fstab.flo:
$ sed 's/msm_sdcc.1/soc/' fstab.flo >
$ mv fstab.flo

If you’re using the factory boot.img, enable a serial shell by editing default.prop and change:

Then regenerate the initrd.img:
$ cd ~/flo/initrd
$ find . | cpio --create --format='newc' | gzip > ../initrd-soc.img

Regenerate the boot.img:
$ cd ~/flo/
$ abootimg --create boot.img -k ./zImage.dtb  -r ./initrd-soc.img  -f bootimg-mod.cfg
$ adb reboot bootloader
$ fastboot flash boot boot.img
$ fastboot reboot

And the device should now reboot and boot up to the shell!

You’ll notice if you’re using the factory boot image instead of the AOSP one, that you’ll get a ton of selinux audit noise. So much that for me it seems to be causing mmc io errors on the userdata partition. I guess for now that’s what you get for taking short-cuts!

Also, with the mainline kernels, reboot does not function. So you’ll have to hard reset the device to get back to the bootloader.

== TODOs ==

While we have the device booting a mainline kernel, its obviously very limited functionally. The items remaining todo are:
- Sort out the SELINUX noise on the factory images properly
- Getting “reboot” to work properly.
- Enable the rest of the supported hardware on the device:
Display panel
gpio lines
usb (including adb support)
- Get mesa/DRM stack running w/ freedreno for graphics

If you’re interested in helping or have any insights with any of the above, please send me a msg!
8 comments on original post
Nicolas Dechesne's profile photoJohn Stultz's profile photo
+Nicolas Dechesne​ Yep, I'm excited that work is ongoing! But I'm still a bit away from being able to use it. Got to get a fbdev and the panel up. 
Add a comment...

Olof Johansson

Shared publicly  - 
Caturday, you say? I don't think so.
Christopher Friedt's profile photoOlof Johansson's profile photoAlex Buell's profile photo
I just love cats.. very embodiment of all that is feline.

Add a comment...

Olof Johansson

Shared publicly  - 
So, the 4.1 merge window is closed, and I would like to highlight some of the highly anticipated code contributions for the new community board from +Linaro, the HiSilicon based 96Boards platform.

Are you ready? Here you go:


Not ONE LINE OF CODE has gone in for 4.1 for the supposedly new flagship platform from an organization that is supposedly all about open source and Linux.

Oh, what a disappointment.

(I'd love to be proven wrong on this, FWIW. Maybe there was some small patch that got accepted that I missed. But none of the major drivers needed for the SoC are in).
Rob Clark's profile photoOlof Johansson's profile photoMark Brown's profile photoJason Plum's profile photo
+Olof Johansson Well, it does depend somewhat on the SoC, obviously any boards that get done using something that's already well supported upstream will be a lot easier than things where people are just starting to work upstream.
Add a comment...

Olof Johansson

Shared publicly  - 
Turns out my 7-year old loooves proper rollercoasters. Who am I to complain?
Satnam Singh's profile photoOlof Johansson's profile photo
... And the three year old loved big thunder mountain today. This rocks. :)
Add a comment...
Have him in circles
3,156 people
Douglas Parrish's profile photo
Roser Blasco Cantavella's profile photo
Johannes Grad's profile photo
Paul Tenuto's profile photo
Eduard Lukash (EdZas)'s profile photo
Reynaldo H. Verdejo  Pinochet's profile photo
Kar Dargo's profile photo
Tarun Gehlot's profile photo
Eric Chen's profile photo

Olof Johansson

Shared publicly  - 
Next Makerfaire I'll buy printer filament last, and drones first. Then I don't have to lug around heavy stuff all day, and they'll still have the toy I'm curious about for sale and not be sold out.

But I think I'm happier with the +Bitcraze AB​ Crazyflie 2.0 than the other I originally considered anyway: it is fully open, so when (if?) I find some time to tinker I've got some fun projects in mind for it. And they're swedish, for extra bonus.

Besides that a fun weekend. I'm a bit torn on how I feel about the kick starter projects being there in general (feels more commercial than maker in spirit). Also, disappointing number of closed platform vendors there (mediatek labs were pushing some hardware platform that lacked docs and wasn't open for example).

Lots of beaglebones everywhere. Fewer RPis than previous year, it seems.

Not much ESP8266 stuff, which given that it is mostly a hobbyist platform doesn't surprise me all that much; most exhibitors are after all commercial.

All in all a lot of fun, a bunch of interesting stuff to look at and talk about.

John “Warthog9” Hawley's profile photoOlof Johansson's profile photoMarc Chutczer's profile photo
I skipped the faire this year but I have the bitcraze v.1 and v.2.
Plan on using a good quality joypad. For me at least piloting straight from the phone app using touch is impossible.
I had good luck with the VM setup and the gamepad connected the PC on the other hand.
Also, there are open source frames you can print for protection... You can use that or order a dozen motors ;-)
Add a comment...

Olof Johansson

Shared publicly  - 
New Beaglebone!
The new BeagleBone Green from +SeeedStudio​!
We talk to Jason Krinder about the new Beaglebone board, the Beaglebone Green from Seeed Studio.
10 comments on original post
Jon Disnard's profile photoPaul Larson's profile photo
This is great. Open hardware working as intended. 
Add a comment...

Olof Johansson

Shared publicly  - 
Thermooptical experiments?!
Bill Richardson's profile photoAaron Bieber's profile photoOlof Johansson's profile photoLeeep ster's profile photo
+Olof Johansson makes it sound like it might be reminiscent of Mexican Hot Chocolate... i'll have to look for some to try.  where did you find it?
Add a comment...

Olof Johansson

Shared publicly  - 
#opticalexperiments but too hazy to see the city tonight.
Add a comment...

Olof Johansson

Shared publicly  - 
For the past year I have been working on the kernel side to bring some ChromeOS features to upstream. One of the areas I'm currently working on is what Google calls Lucid Sleep, which is basically the ability of performing wo...
1 comment on original post
Add a comment...