
64-bit ARM Kernel Development Demo on a Nexus 9 - andreiw
http://osdevnotes.blogspot.com/2014/11/64-bit-arm-oskernelsystems-development.html
======
andreiw
A short demo showing that your Nexus 9 is actually the cheapest and most
accessible 64-bit ARM development platform for systems programming.﻿

~~~
voltagex_
I got pretty sick of "Linux on xyz Android device" meaning a chroot with
varying levels of usefulness. This is the first post in a while that shows
some actual low-level dev work being done.

How difficult would it be to get a (mainline?) kernel booting on this, maybe
even into Debian?

~~~
ojn
Nvidia hasn't submitted any platform patches, nor device tree contents, for
mainline yet.

Nearly all the drivers carry over just fine between 32- and 64-bit, and
they've been actively moving a bunch of the little glue code out of arch/arm
lately, so there's not a _whole_ lot left to do.

I haven't seen anything posted yet so it's not looking all that promising that
it'll make 3.19 either (but it's still possible).

~~~
uaygsfdbzf
ARM SoC support in Linux mainline is usually pretty good but support for
individual mobile devices that normally run Android's version of Linux is
almost non-existent. Basically we are never going to get the usual Linux
distros running on Android devices without using Android's version of Linux.
There isn't anyone with the available, time, skills and motivation to get new
or old Android devices supported by Linux mainline. I expect the same goes for
other vendor-controlled Linux based mobile distros (Tizen, Sailfish, FirefoxOS
etc). Probably the closest to mainline is the very old Nokia N900 but that
doesn't even support all of the hardware on the device:

[http://elinux.org/N900](http://elinux.org/N900)

~~~
sandGorgon
Does anyone know what the differences between the mainline kernel and the
Android kernel are?

This is actually surprising to me - I had expected that the only differences
were in username (unit system, ipc, etc). Is it a question of one time
development to make driver _format_ compatible in Linux?

~~~
ojn
(upstream arm-soc kernel maintainer here :)

It's not really about anything Android-specific that's in the "android
kernel", it's about all the other code that's needed for a platform to run
well.

The main problem is that besides the base kernel, most mobile platforms
require a lot of code that hasn't been upstreamed. In some cases, "hasn't
yet", in some cases "probably never will be" \-- it depends on the vendor
involved if they have any such ambitions.

Most of this is drivers of various kind. Some vendors are better than others
at upstreaming them and the other pieces that are needed, but nearly none of
them have upstreamed sufficient amount of power management to make a real
device useful and have reasonable battery life. There's also usually drivers
missing for modems, etc.

And, of course, graphics is a very sore topic in this area -- no vendor today
ships a phone that uses an open graphics base. Ironically enough, Nvidia is
the vendor that has done best here, with work happening in the open on their
DRM drivers (but no products have shipped with those drivers at this time).

The vendors that have done best are normally those who have more embedded-type
platforms and not primarily mobile phone chipsets. By the time upstreaming of
a mobile platform is done, the next generation is already out and nobody will
build new products with the old one. It _does_ get better over time as more
and more share code goes in, but most vendors have enough of a backlog that
they don't see those benefits yet and as a result don't prioritize it as high
as I wish they would.

Then there is of course some vendors who don't participate at all, or does
very very little. The Chinese manufacturers used to be notorious here, but
even some of them have started doing better as of late (Rockchip in
particular, but MediaTek has started posting some patches too).

The vendor that traditionally has done best is TI, but they've gotten out of
the mobile business. ST-Ericsson was making a good attempt too, and they also
got out of it. Nvidia has actually been really good at working upstream on
their 32-bit Tegra support, it's unfortunate that it's taken them this long to
get going on the 64-bit support upstream.

~~~
tonyg
When you say that there are drivers missing, does this go as far as GPL
violations? Or is it not quite as toxic as that?

Also, what is the situation like with regard to figuring out what has been
changed in a vendor-supplied kernel vs. a generic kernel source tree? Is it
reasonably straightforward to get a clean diff so you can see what was
changed? Non-upstreamed hacks and bodges seem less terrible to me if it's
possible to at least see how they work.

~~~
ojn
Not necessarily GPL violations (there are cases of those too, but the bulk of
it is not). It's just a matter of nobody having cleaned up the drivers enough
to get them submitted for upstream inclusion. It can be quite a bit of work to
do, and the next generation of product is sitting there waiting on the same
people to make that work instead.

You can usually download and diff the source tarballs. Some vendors keep git
repos so you can see changelogs as well. There's usually a lot of noise in
there though, lots of various imported vendor drivers that duplicate things,
firmware files in hexdump format, etc. It's pretty common to see diffs of
millions of lines.

~~~
sandGorgon
could you elaborate on what you mean by "cleaning the drivers" ?

I'm really curious, because it seems that Android has built an architecture
where vendor supplied drivers (binary blobs?) can be dropped in without too
much changes. But upstream linux needs a considerable amount of rework to
"absorb" a driver.

Is this deliberate (the same reason why GCC is obfuscated) or is there a
technical reason behind it ?

Because Android Linux works on thousands of different platforms with a lot of
stability - I'm beginning to think that the Android driver model is
superior... and perhaps mainstream Linux would do well to move to that.

~~~
mcpherrinm
I work on an embedded Linux device. Sometimes, we do whatever nasty hack we
need to make _this kernel_ work on _that device_ \-- but those changes aren't
portable, aren't maintainable, and don't meet the quality requirements to be
in the upstream tree.

There can also be a perception it's "a waste of time" since "nobody will run
another kernel on this anyways"

------
higherpurpose
> It's unclear if the "oem unlock" allows reflashing custom unsigned firmware.

I don't think it does. I think you usually need "root" to install another
ROM/OS on the device as well.

~~~
andreiw
The oem unlock allows you run a custom OS (e.g. a custom Android build) that
is not signed. This is well known, and is what allows this demo to work.
However, the comment I was making is whether the firmware (i.e. the
bootloader, "BIOS" if you may - in particular the Secure OS) can be reflashed.

The reason the existing firmware could be desired to be replaced is that the
Secure OS component specifically disallows an OS to run in hypervisor mode
(i.e. no KVM or Xen), or because of terrible bugs in HBOOT that cause hangs if
the boot.img exceeds a certain arbitrary size (a few tens of MB). All these
limitations mean that even an OEM-unlocked device is not quite entirely
available to the mercy of a developer.

Of course, the ability to reflash the low-level boot code is not very useful
unless you have sources to build a better replacement.

------
lancemjoseph
Are there any devices that ship with Android that could be reflashed to
support a Linux kernel with KVM or Xen bits? Either Intel Atom or ARM-based
devices?

------
Aissen
It's weird, because according to this page:
[https://en.wikipedia.org/wiki/Qualcomm_Snapdragon#Snapdragon...](https://en.wikipedia.org/wiki/Qualcomm_Snapdragon#Snapdragon_410)
, there are already 25+ 64bits-capable Android phones out there.

