Profile cover photo
Profile photo
Riku Voipio
Riku Voipio's posts

Post has shared content
standardized embedded nonsense hacks, and other freedreno updates!

Post has attachment
Cross-compiling with debian stretch
Debian stretch comes with cross-compiler packages for selected architectures: $ apt-cache search cross-build-essential
crossbuild-essential-arm64 - Informational list of cross-build-essential packages for
crossbuild-essential-armel - ...

Post has attachment
Now we have phones with 8GB of Ram. 

Post has shared content
It's been online since a few weeks, so it was time to announce it officially: +Free Electrons is proud to publish Elixir, its new Linux kernel code indexing tool, providing numerous improvements over the older LXR tool we had been using so far.

Read our blog post at to learn more about this tool, and head to to discover it!

We welcome feedback, such as issues and suggestions, on the project bug tracker at

Post has shared content

Been awhile since I've posted any updates on 96boards devboards in AOSP, so I figure it's past time I do so.

On the HiKey front, things continue to move upstream, although it's been slower of late due to working on other activities.

In 4.12, the i2s audio driver landed (although the DTS changes to enable it didn't make it) for HDMI audio support, as well as +Rob Herring's work to get the TI bluetooth chip working via his new serial device bus.

The serial device bus is really nice, because it allows the kernel to handle basic initialization like loading the firmware, setting the baud-rate etc, which normally would have to have been done in some device-specific userspace code before the standard hci device protocols could be used over the UART. Now, the kernel handles all of that, and we just get a standard hci device, same as with a usb bluetooth dongle. BlueZ userspace already knew how to handle this device-specific initialization for standard Linux environments, but with Android we were having to use TI's out-of-tree kernel driver and HAL. So this is really nice to have a generic solution upstream, and we're in process of backporting it to the android-linaro-hikey-4.9.

Coinciding with switching from an out-of-tree bluetooth driver in the kernel, +Satish Patel has been working on getting a generic linux bluetooth HAL up and running in AOSP/master. This is based on an older bluetooth HAL in AOSP that has become somewhat unmaintained, and stopped working awhile back. So having a generic bluetooth HAL that works with standard linux hci devices (usb or serial) is really nice! That code is still in submission and review, but once it lands, we can drop the out-of-tree TI patches from the mainline based HiKey kernel!

Speaking of out-of-tree patches, we did work with ARM to get updated r7p0 binaries. This allowed us to move forward to their r7p0 kernel driver, which has support for the upstream dma-buf fences and SYNC_FILE interface. This let us drop a terrible hack I was carrying since 4.6 basically reverting the dma-buf fence code to the old Android Sync driver in staging so the mali driver would work. Dealing with binary blob drivers against an constantly moving upstream kernel is still the worst, but I do really appreciate ARM's help in getting their driver updated!

Of course, mainline always keeps moving, and you drop one terrible revert hack, you sometimes have to pick up another. +Laura Abbott's persistent and continual effort working on the Android ION driver in staging took a big leap, and some major refactoring of the interface landed in 4.12-rc. I'm really excited to see things start to happen here, and tons of credit goes to Laura for continually pushing the upstream community here. That said, as often happens with established code as it gets pushed upstream, there have been some interface changes, which make the upstream driver now incompatible with older gralloc implementations. So for now in the hikey tree I have those patches reverted. :( Now, Laura awesomely has already submitted examples on how to convert HiKey's gralloc HAL to the new interfaces, and +Sumit Semwal is working on extending that so HiKey's gralloc implementation can support both new and old interfaces, which will be important as we still support running HiKey in AOSP w/ the 3.18, 4.4 and 4.9 kernels. Once those userspace changes land, I'll be able to drop my ION interface revert patches and we'll be moving happily into the future.

There's also been recent work by +Antonio Borneo to fix up support for SPI, and work by +Ulf Hansson to improve some of the clk handling to support non-UEFI bootloaders like u-boot.

The patch set I manage continually shrinks and grows, as bits get upstreamed and new bugs are found and fixed, but other then mali and the ion revert, the board is pretty functional with just mainline. The main upstreaming todos I have left are the HDMI audio dts changes, patches to allow the kirin drm mode-limitations be expressed across the hdmi bridge chip, and taking another pass at the android cgroup migration feature. The rest are mostly warning fixups and other polish level patches.

We’re also really starting to feel the benefits of the effort to get the HiKey board upstream. There’s a lot of testing work that can now be done with the HiKey against mainline kernels, and thanks to efforts from +Milosz Wasilewski and others we’ve uncovered some pretty hairy generic bugs with upstream and LTS kernels that I’ve not been able to trigger elsewhere. And while having some unplanned ugly bugs to chase might wreck one’s plans for the week, it is good to see them uncovered through testing and eventually resolved upstream.

Of course, since my last update, we've also announced the HiKey960! It was great to see the press response to the board announcement, although also a bit frustrating to see it constantly called a "RasPi killer" in the majority of headlines, which is silly. It is similar form-factor, but both its power (and expense) makes it a whole different animal. The benefit I see most with the board is that it gives us flagship class hardware to do development and prototyping with. Of course, it's not going to be for everyone, and for folks who are price sensitive and don't need the extra power, we still support the cheaper original HiKey board in AOSP. But for those who are trying to develop new features like the EAS scheduler, or new block layer or filesystem features, having the latest ARM processor and fast UFS storage in an affordable devboard will be really valuable.

Since the release, +Leo Yan also has enabled thermal management support, which also fixed some cpufreq issues with the kernel that shipped on the device. Those changes along with parameterizing and naive tuning of the powerHAL has resulted in some really nice performance gains recently on some benchmarks. Its still early days, and folks really haven't spent much time tuning the performance on the board, so I think we still have quite a bit of power to pull out of the device.

HiSi has also been really key in helping us migrate from proprietary binary blobs for things like gralloc to ARM's opensource reference implementations. This is really great, because now HiKey960 is on the same footing with regard to binary blobs as the original HiKey, which makes handling updates to new kernels (and dealing with issues like the ION kernel abi changes upstream) much easier to manage. Also big thanks to +Vishal Bhoj for helping with getting all the blobs properly packaged.

Additionally, while the device shipped with the now fairly old v4.4 based kernel (though, to be fair, it shipped just days after the first commercially available Android phone that used 4.4 was released) +Guodong Xu and others on the Landing Team have been putting together a mainline based branch and a v4.9 based branch. There's still some heavy churn to the patches for the USB and graphics subsystems that have kept us from moving to v4.9 for AOSP, but hopefully that will happen soon.

And since the announcement, and really, even before that, +Zhangfei Gao, +Guodong Xu and others on both the Linaro HiSi Landing Team and in HiSilicon have been pushing some of the early core board support upstream.

There’s also been lots of smaller things, like +Vishal Bhoj recently submitted enabling of selinux on HiKey960, and firmware updates by +Guodong Xu to help prep for +Haojian Zhuang's work to migrate from the HiSi proprietary booloader to UEFI. (And I'm now feeling terrible as I'm sure I've left some folks out).

So yea, its been busy of late! And as always, everyone has been doing amazing work to collaborate together, so many thanks to everyone (explicitly called out or not) involved! 

Post has attachment

Post has shared content
They were already doomed when car makers started using embedded linux, network connectivity, no isolation from safety systems and no security updates. Now they are just slightly more doomed as exploit writers can use common android knowledge to write exploits.

Post has shared content
The Cockpit server web interface has now been in Debian unstable and Ubuntu 17.04 and devel for a few weks. Time for a quick introduction!

Post has attachment
ARMv8 cloud virtual machines from 2.99€ / month

Post has attachment
Wait while more posts are being loaded