Comment by djsumdog | Hacker News Reader

Comment by djsumdog | Hacker News Reader

Parent Full thread

I wrote this about Android a while back:

http://penguindreams.org/blog/android-fragmentation/

The TLDR is that it'd be nice if Android was more like Windows/Intel: install the OS (i.e. AOSP), drivers (or binary driver package format and an SDK to auto-build it) and boom you're done. Clean, stock, standard. Same with many Linux distros on x86/64.

I need to write an update to the article though. Lately I've been struggling with a Clearfog ARM board, and coupled with Torvald's recent comments on Intel vs ARM, I wonder if a huge chunk of the problem is ARM itself.

I've noticed for every distro there are really specific images, not just for each ARM chipset, but for individual boards, even when those manufacture patches make it into the mainline kernel.

I haven't looked closely at Android and I'm really curious at the build system/workflow used by things like Cyanogen and Omnirom. Are kernels really specialized per device? Does the ARM architecture itself make it difficult to have general purpose kernels that will boot on all of them like in the x86/64 world?

Any ARM hardware people care to chime in?

> Any ARM hardware people care to chime in?

It's not really about the CPU architecture, but the peripherals of the devices. In the x86 world, the peripherals are governed by the "PC" standard, which these days is implemented by the chipset on your motherboard. They all have similar functionality, although you still do need some chipset-specific drivers in your kernel.

In the ARM world, the landscape is different. There has never been a de facto standard configuration of an ARM computer like the PC was/is for x86. There are ARM computers that are more like a micro controller and there are tablet/mobile devices based on ARM that have a system on chip (SoC) that's got all the peripherals, including GPUs, network adapters, etc. Every SoC is pretty different, there's a bunch of devices connected with i2c, spi and other buses. These are required to control the power and clock management and all the I/O devices.

ARM (the company) doesn't really design these, they just license ARM (the architecture) to a SoC manufacturer and call it a day. This leads to a very diverse and fragmented landscape.

The ARM world has been making strides to reduce the amount of chip-specific code. One good example is the device-tree configuration which, in theory, allows running the same kernel binary on different devices. With device-tree, you pass a config file from the bootloader to the kernel, which contains configuration (i/o memory maps, etc) of the peripherals (which you'd query from the hw/firmware in a x86 machine). This is a huge improvement over what was before it, but there's still a long way to go. And there's still plenty of older ARM SoCs out there that don't support this.

But yes, it's pretty much a mess. There's a lot of duplicate work that every ARM SoC manufacturer has to go through. Given that the mobile world is financed by a planned obsolescence cycle where they expect customers to upgrade every few years, I find it unlikely that this issue will be solved any time soon.

To be honest, x86 seems to be heading in the same direction these days. It generally has enough of an emulation of traditional PC architecture for boot purposes, but look at - for example - how CPU power saving on modern Intel chips requires the co-operation of stuff like the SATA links, or how traditional PC interfaces like PS/2 for keyboard/mouse and HD Audio are being replaced with more embedded-like interfaces such as I2C touchpads and I2S audio links connected to vendor-specific controllers.

Sure, but it isn't as diverse so you can reasonably expect to boot a mainline kernel on a PC regardless of your motherboard vendor.

It is like the old days of home computers.

We had Z80, 6509, 68000 and so so, but everything else that was plugged into their pins was different.

So it doesn't matter if the Assembly is the same, the kernel also needs to talk to the hardware.

Also ARM just resells the base designs, each company usually adds they own set of Assembly instructions or fine tunes the designs in some other way.

The IBM PC clones were the only ones that had some kind of standardization going on, and even that seems to be gone now, with OEMs going to the same kind of hardware designs we used to have (everything bolted on the board).

Debian is shipping one Linux kernel build that runs on a bunch of different ARM devices that are supported by the mainline version of Linux:

https://wiki.debian.org/DebianKernel/ARMMP

Unfortunately most mobile devices are not supported by mainline Linux (N900 is best supported, but not fully), usually only server/desktop/laptop vendors have any incentive to mainline their drivers.

The 2013 Nexus 7 was, at some point, 50 patches away from running mainline [1]. I know, single datapoint, but it gives me hope that there's some way out of the tabletification of computing.

1: https://wiki.linaro.org/LMG/Kernel/FormFactorEnablement

Android kernels are built differently from PC kernels because unlike a PC where you might upgrade the motherboard, or add/remove hardware that would change what kernel modules are needed (and still expect the PC to boot), a cell phone almost never changes its hardware configuration after installation. If the phone is a Wombat 4s, it'll have X, Y, and Z hardware components and these will never ever change. If it's a Foobar 8000, it'll have X, Y, and Q, and there might be two different sizes of W which aren't even something that requires a driver and those will never change either. Including all the modules that might be present on any device compatible with the same CPU architecture would mean wildly more than 90% of the space used by the kernel/drivers would be completely and utterly wasted (and theres at least four more types of resources that would also be wasted that come to mind). This is not a thing one does with a device expected to run as long as it possibly can with a very limited supply of power and less RAM than pretty much any desktop machine you'd care to use.

Some related posts:

https://cascardo.eti.br/blog/GNU_on_Smartphones_part_II/ http://bonedaddy.net/pabs3/log/2012/12/03/debian-mobile/ https://wiki.debian.org/Mobile

Reply on news.ycombinator.com