
Running a mainline kernel on a cellphone - alecco
https://lwn.net/Articles/662147/
======
mercora
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.

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

~~~
mercora
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](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.

~~~
lucaspiller
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.

------
bobajeff
Here a link detailing the technical issues to mainlining devices:
[http://elinux.org/Kernel_areas_of_focus_for_mainlining](http://elinux.org/Kernel_areas_of_focus_for_mainlining)

------
mschuster91
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?

~~~
rwmj
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).

~~~
dmm
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](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

~~~
joezydeco
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.

~~~
digi_owl
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.

~~~
david-given
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...

~~~
digi_owl
Best i can tell, devicetree originated with Open Firmware.

------
jacquesm
Does this apply to the Ubuntu phone as well?

~~~
maheart
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](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)

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

------
gima
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.

~~~
rwmj
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.

~~~
jorlow
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.

------
rch
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?

~~~
david-given
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...](http://community.qnx.com/sf/wiki/do/viewPage/projects.community/wiki/UpdatedQNXSourceAccessPolicyFAQ)

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

~~~
KMag
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?

~~~
david-given
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.

------
rwmj
Does this also apply to Jolla?

~~~
nextos
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.

~~~
maheart
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)

~~~
nextos
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-...](http://www.phoronix.com/scan.php?page=news_item&px=Power-VR-Open-
Chatter)

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

------
voltagex_
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.

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

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

