ubuntu-phone team mailing list archive

[sturmflut <sturmflut@xxxxxxxxxxxxxx>]

Good morning,

(I saw your later reply, but was already pretty much finished writing
this long list of sadness, so I sent it anyways for future reference).


Am 12/08/2015 um 02:47 AM schrieb ubuntu.mexon@xxxxxxxxxxxxxxx:

> I didn't know that.  I was naively assuming that since the Linux kernel
> has had support for various ARM processor architectures for ages, and
> the process of integrating the Android fork was almost complete,
> customisation would be the exception rather than the rule.

If that was the case, Android wouldn't be stuck at the 3.10.x kernel
version :( Google doesn't even make sure their own Android extensions to
the kernel are fully merged upstream.


> Can someone provide more background on this?  Are we talking adaptations
> for the processor architecture, for particular peripherals, or what? 

Peripherials, but sometimes also core parts of the system are heavily
modified, e.g. Meizu decided that the CPU scheduler of the MX4 mostly
runs in userspace.


> Are the customisations in modules or in the core kernel code?

Sometimes it's modifications to the core kernel code, but usually drivers.

Sometimes drivers are shipped in source code form (e.g.
https://github.com/bq/aquaris-E4.5/tree/aquaris-E4.5/mediatek/kernel/drivers)
and just compiled into the kernel at build time. It would be possible to
merge these upstream if somebody did it.

Then there's the usual round of hardware abstraction layers shipped in
source code form which then link/load binary blobs, e.g. for all the GPU
drivers. To my knowledge not a single ARM SoC vendor ships an open
source GPU driver, it's all reverse engineering.


>  Are efforts underway to push any of the changes upstream? And does this
> apply to all phones now and in the future or does it depend on the
> model/chipset supplier?

It's pretty much completely up to the chipset manufacturer. Nobody pays
them to keep their forks up to date or upstream anything, and Google
doesn't pressure them.

The ARM world also has much more variety when it comes to peripherals, BTW.


> What would it take for a chipset to support a
> stock kernel, UEFI?  Is there any movement towards standardisation among
> chipset suppliers?

Up to ARMv7 you're out of luck and probably will be forever. ARM
completely failed at defining any standards, and Google also didn't set
any for Android. The situation is so bad that ARM even "forgot" to add
auto-discovery features to their own on-chip AMBA bus system, which means:

- There is no standard way how an ARM SoC boots, so every SoC
manufacturer comes up with his own idea on how to do it, and every
device manufacturer has to build his device around it.

- There is no standard bootloader (no BIOS or UEFI), so every SoC
manufacturer needs to build and ship their own. The clever ones use
u-Boot, but many don't.

- There is no standard on how to partition the flash storage. Some
bootloaders (e.g. MediaTek) use magic values and fixed partition
layouts, others use partition tables. MediaTek thus even requires a
different bootloader binary for different variants of the same model
(e.g. the 16 GB MX4 has a different bootloader than the 32 GB MX4).

- There is no standard way how the bootloader hands over control to the
operating system. For example the MediaTek Little Kernel (2nd Stage
bootloader) writes some data to magic memory locations, and the Linux
kernel has to be patched to fetch this information from the right places.

- There is no standard way how the operating system could find out what
the hardware looks like (no ACPI), so a list of all core hardware
peripherals, their interrupts, memory locations etc. has to be
statically compiled into the kernel at build time.

It's all completely custom and every device needs its own bootloader and
kernel binaries. The only "standard" in this whole are is the Fastboot
protocol specified by Google, so you at least can flash images to
partitions using a standard command.

If you're interested in these things, you might head over to
http://sturmflut.github.io/ where I documented some low-level internals
for MediaTek devices.

For ARMv8 there is a standard developed by ARM called the Server Base
System Architecture (SBSA,
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029b/index.html).
It mandates UEFI and ACPI and would finally make it possible to boot a
single, standard operating system image on every SBSA-compliant phone,
as long as it comes with all the drivers. Your phone would become just
like a generic PC.

Will this happen? Don't think so, at least in the medium term. Google
doesn't mandate the SBSA as a minimum for all devices, and I would
expect that many companies are not interested in the customer being able
to easily install arbitrary operating systems on their devices. Imagine
a phone that just installs and dual-boots stock Windows and Ubuntu from
a normal USB stick.


> The issue, obviously, is security.  How long will Ubuntu be integrating
> security patches for?  I want my phone to still be usable in 10 years.
> Maybe not as a phone, but I would like to see it honoroubly retired to
> some useful function, media player, doorbell, opening the catflap for my
> cat, whatever.  But not if it's too compromised to be allowed on to my
> network.

To be honest: Your device never was secure to begin with. The baseband
chip has its own, unknown operating system with full access to all
memory and peripherals. It responds to commands from the mobile network
you will never ever get to see. Governments can track your location and
access all your data whenever they want. The kernel is full of binary
blobs we can't patch, the Android userspace bits we have to use are
binary blobs.

There will most likely never be a truly open source phone because there
simply are too many firmware and driver bits to replace, and even if we
could do it there still is the issue of the baseband. Building and
validating a state-of-the-art 4G baseband is a many-million-dollar project.


(Yeah, it's all completely horrible, and sometimes I just want to become
a gardener and bury my phone between the flowers.)

cheers,
Simon