Hacker News Reader

Comment by dublinben | Hacker News Reader

Blame the OEMs for that. The driver situation on ARM devices is quite dire.

Is this a side-effect of mobile devices having extremely tight requirement for power usage and packaging? I could see how that, and a huge number of functions being packaged into a single SOC would make each board design far less generalizable from either one generation to the next or one form factor to the next. On the other hand, that doesn't preclude drivers for the relevant chipsets being more easily available. Do phone manufacturers write their own drivers for all these chips as a matter of course, or do the chip providers ship something with what they put out?

I think in reality it's simply a matter of everyone having their own build of the kernel and needing their own set of kernel modules. Google could have solved this in some way with Android, went for something closer to the way drivers work on Windows, a single long term service kernel that everyone builds their drivers against.

But instead they told everyone to just build it themselves... resulting in the current situation. They could have also solved the updating problem in the same way.

No big deal though, someone will make this build on other platforms if there's interest. It's all open source and I'm sure some 14 year olds on XDA are already racing to make it build on their phone from 1982. Then I'll probably flash it. Because that's apparently who I trust to write my phone ROM.

Google's certainly at some fault here, e.g. by choosing to long-term fork Linux instead of trying to upstream their patches.

But my understanding is that they couldn't "just" do something like what Windows does, they don't get to boss the OEMs around in that capacity, some of the big ones effectively have their own Android forks (Samsung) or have already forked (Amazon), and if Google starts bossing them around they're just as likely to fully fork it as be brought into the fold.

I would point out that OEMs are unable to even release an Android device without Google's permission if they want any of their devices to have access to the Play Store. Google has an extensive compatibility suite that devices must pass to even qualify to request permission to release, and Google regularly changes the requirements to enforce what they feel is a good platform. They also mandate over 20 preinstalled applications, define default search settings, and the placement of app icons on the home screen.

They ABSOLUTELY do get to boss OEMs around in that capacity.

Amazon doesn't do this, and ship their own store. What do you think would happen if Samsung forked Android and didn't ship the Play Store? Now app developers would just upload their apps to both stores and Google's power over Android as a whole would be entirely eroded.

So no, they definitely don't get to boss the OEMs around. Unlike Microsoft with Windows they don't get to just say "you can't ship Windows^HAndroid anymore".

They do have a bit of hold over the OEMs in the form of it being a PITA to fork, access to Google's own apps etc. So I'm not saying they have no leverage, but it's a lot less than what Microsoft has, and definitely not enough to say "my way or the highway".

This is why Google cut a deal with Samsung to bring them more in line. (Terms are secret, as usual.) Samsung seemed like it was likely to fork before, and it's probably the only manufacturer large enough to draw app developers with it. So Google did some under the table things. Possibly actually a patent lawsuit threat, given that the deal they announced included a patent sharing arrangement.

It is because ARM has never really been standardized in embedded devices.

Not at all. Vendors just fork the kernel at the fixed releases Android versions ship (ex, 3.4, 3.10, 3.18, etc) and then merge in all their proprietary bullshit violating the GPL nonsense into that tree, ship (and publish) that kernel source tree, but never merge back into Linus' tree.

As a result, the device is supported only by the kernel they provide, rather than by generic Linux. And their kernel never gets updates.

The PC has PCI enumeration, that allows the kernel to ask each device on the bus for a id code. This in turn allows the kernel to load the appropriate drivers.

ARM do not really have this. Unless you know exactly what device is on what address range etc, you risk sending the wrong signals and fill its firmware with garbage or something.

This means you can't really cook up a generic kernel package and apply it across the product range as you can on PC.

This seems like a fatal flaw in the design of ARM.

U-Boot and linux have the Flattened Device Tree[1] (FDT) which allows the kernel to load and configure the appropriate drivers.

Your statement is true, however, that someone knowledgeable of the actual hardware has to create the correct FDT. This is slowly getting better and easier.

The more intractable problem, as others observed, is that ARM hardware vendors tend to throw together a custom kernel for a given ARM processor and board and then abandon it.

[1] https://en.wikipedia.org/wiki/Device_tree

It is very dire and painful :-(

Reply on news.ycombinator.com