Running a mainline kernel on a cellphone | Hacker News Reader

Running a mainline kernel on a cellphone

lwn.net

94 pointsalecco34 comments

I recently bought a windows tablet to toy around with it. It has an Intel CPU (Baytrail SoC) and was very cheap. It comes with an integrated Intel graphics one is used to see in Desktop CPUs and for which free drivers do actually exist. It has an UEFI firmware and it was fairly easy to boot Linux on it out of the box. It has some flaws like unstable clocksource and wireless drivers (not mainline). But there seem to be much development currently.

It was a really nice feeling seeing a device of this class running Linux with near to zero effort and really wished it would always be that simple.

Do you have any recommendations on which Windows/Intel tablet is best for this? I've been thinking of doing the same.

Sorry but i can not recommend any device in particular. I noticed that most of the cheap devices ship with a Z3735F/G CPU. I bought this[0] one but the main reasoning was getting it cheap. I think most of the Baytrail SoC based devices will work quite comparably. I would now watch out for a mainlined wireless driver/chipset.

[0] http://www.i-onik.de/en/node/182

Edit: It will be easier to get a device with UEFI firmware. It seems possible to replace the firmware with a manufacturing tool published from Intel. But i haven't looked into that yet. I might try at some day to compile TianoCore or coreboot for it. Getting fastboot to work for Android seems possible too.

I'd be interested in a write up of how you set it up, what you run on it, and how it compares to a standard tablet.

If you live in the US take a look at the HP Stream 7. They run about $100 brand new, $60-70 for refurbs.

Here a link detailing the technical issues to mainlining devices: http://elinux.org/Kernel_areas_of_focus_for_mainlining

What I don't get is the "why". Are the differences between mainline and "customized" kernels so huge that integrating at least the common parts of code into mainline is impossible?

Or is it because HW manufacturers just ship code as soon as it builds and doesn't crash in rudimentary testing, leading to a code quality far below Linus-acceptable?

Back- and forward-porting code is just hard. There are ~183000 commits between current Linux and Linux 3.10, and even though most of those are driver changes or make only minor changes to core APIs, there are going to be dozens or hundreds of small changes you'd need to make to a driver to forward-port it to modern Linux, or to a security fix to backport it to an Android kernel.

You could have a long-term stable API between the drivers and the rest of the kernel, but the kernel developers don't want that because it would restrict their ability to make breaking changes in the interests of performance or maintainability. It would also encourage proprietary drivers even more, and make them explicitly legal (at the moment, proprietary drivers are at best in a grey area, and most likely illegal).

The lack of a stable kernel API may be part of it but I think the main reason drivers don't get into the mainline kernel is that they are written as big hacks: hard coding values and not following standard kernel practices.

Check out the wondermedia wm8850 sources on github: https://github.com/wondermedia/wm8850

Instead of using a device tree the drivers expects memory address to be passed to the uboot command line and other venders just hardcode the addresses, making you modify the sources to run the driver on a different device

Devicetree. Ugh.

On one project I attempted to move the kernel from 3.0.35 to 3.10 and even that was a huge pile of problems, asking vendors to bring their drivers up to speed. Some did, some didn't. It wasn't worth the trouble so off we went, shipping with 3.0.35.

Well i think it is the closest ARM has to PCI enumeration right now.

Best i recall, Intel started Moblin (that later merged with Maemo to from Meego) because their mobile Atom SoC didn't provide PCI enumeration. Thus MS was reluctant to provide a Windows version for it, as Windows was highly reliant on just that for hardware management.

Didn't Open Firmware solve all these problems years ago? I'm pretty sure I remember operating systems being able to use Open Firmware to query option ROMs for driver details in a scalable (and machine independent!) way, way back in the 1990s.

It's always saddened me that Open Firmware never got picked up for IA. They went for EFI instead...

Best i can tell, devicetree originated with Open Firmware.

Proprietary drivers already exist and they are legal. (Whether or not that's a good thing, is a different, controversial topic.) They work by having the user compile an open-source shim module which allows device control from userspace. Then the user installs a proprietary program into userspace (i.e. as the root user) and this program permits control of the device from the rest of userspace.

There is nothing explicitly stopping a user from installing a different, open-source program that talks to the open-source shim module.

Does this apply to the Ubuntu phone as well?

Ubuntu Touch (mobile) is forced to use an older version of the Linux kernel.

An overwhelming majority of SoC manufacturers develop drivers for Android's Linux Kernel 3.4 (and I think more recently? 3.10, etc). As per GPLv2 the kernel part of the driver needs to be FOSS, so most of the driver logic exists in the (proprietary) userland code.

Since there is no FOSS drivers for many of these SoCs, Ubuntu (and Jolla) use these proprietary drivers (targeted at Android's Linux Kernel 3.4) in conjunction with the GNU userland, by using libhybris (https://en.wikipedia.org/wiki/Hybris_%28software%29).

This allows Ubuntu (and Jolla) to:

1. Run the Linux kernel (3.4, or whatever version the driver was developed for) 2. Run the GNU userland (including glibc) 3. Run the Android drivers (using libhybris)

Iirc, FirefoxOS is basically Android stripped of the Dalvik/ART runtime environment for the same reason.

They want to be able to change the kernel [easily], but nobody discusses anything about how nothing in the kernel can be changed [easily]. Maybe if the kernel wasn't monolithic, it would be easier to provide security updates when the whole system's stability didn't depend on the change not breaking the whole circus.

They're free to base their tablets on QNX (highly modular) or FreeBSD (no reciprocal license obligations). The fact that they've decided to use Linux means they have to abide by the technical decisions, and licensing, of the Linux community.

At this point, androids kernel is really just a fork of Linux that's wildly more popular. I'm not sure why they need to abide by anything unless they want to.

At one point I think QNX was an 'open engineering' project - that is, sharing design and development communications, but not accepting source contributions.

Was there anything useful gleaned from that approach, and would companies not able to share code be willing to try something similar?

It was a look-but-don't-touch license, and source was only available for parts of the system (I don't think you got the microkernel secret sauce). After QNX was bought by Blackberry, all the community features quietly evaporated.

Here is a good example of the new, caring, Blackberry side of QNX:

http://community.qnx.com/sf/wiki/do/viewPage/projects.commun...

Foundry27, their hobbyist community site, is now a desolate wasteland.

I was always a bit surprised that I never heard of an effort to create a GPL'd QNX clone. Do you think that L4 has more conceptual purity with performance and stability close enough to QNX?

I've never used L4, sorry. But I do know that the two operating systems are completely unlike each other. L4 is a bare-bones hypervisor task/switcher kernel. QNX is a complete Unix, which is (to me) where all the value lies.

How L4 compares with the QNX kernel, I don't have the knowledge to comment on.

It appeared to be very much a half-hearted attempt, quite probably to be seen to be more 'open' without taking any risk or making an actual commitment.

Does this also apply to Jolla?

Sadly I think it does, as there's some closed hardware over there with no drivers in the kernel. Also, Jolla's OS itself is partially closed.

I miss the Nokia Maemo days, which was not completely open hardware wise. But almost there. In practice, it was running Debian on your phone (but again with some caveats, including a non-mainline kernel).

Perhaps DragonBox Pyra, about to be released, will give us the chance to re-create that experience. In theory it will be possible to run a mainline kernel and Debian, ArchARM, GuixSD or whatever ARM distro you like.

I've just had a look at the DragonBox Pyra. It looks like it's going to use a PowerVR GPU (i.e. no FOSS drivers).

Can you clarify how a mainline kernel can be run on such a device? I assume PowerVR are written only for specific kernel versions (e.g. in the same way GPU drivers are written specifically for Android's Linux kernel 3.4)

That's true. My plan was to run the Pyra without 3D acceleration, as I will use it just as a minilaptop for maps, chat and ssh. AFAIK, the Vivante chip included in Pyra has a usable free driver, which is what matters most for my usecase.

PowerVR is also said to be working on a free driver [1]. This might do the trick.

Generally, GPUs are the showstopper in ARM architectures. Otherwise, it is possible to run not only a mainline linux kernel, but a deblobbed one (linux-libre). I do this on a Chromebook C201 [2]. Note you don't even need CPU firmware, as it is the case with Intel.

[1] http://www.phoronix.com/scan.php?page=news_item&px=Power-VR-...

[2] http://www.libreboot.org/docs/hcl/c201.html

Thing is that the Maemo days is perhaps what has spurred many controversial changes to Linux userland, the biggest of them being the development of Wayland.

On the surface Wayland is fairly innocuous, but it is having the effect of moving a whole lot of what used to be done by X onto the DE/toolkit.

Such a badass thing this, DragonBox Pyra.

I tried, I failed. I'm probably just going to run Nemo Mobile on my Nexus 4 if I can find the time to build it.

Presumably, this is the reason that most phones can't be upgraded to the later Android releases?

Once you mainline a Linux kernel, you'll crave it on more and more of your devices.

Reply on news.ycombinator.com