Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

arstechnica.com

Post reply on HN
Print view View original

131–140 of 226 posts

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#131

Post by coder543 »

jamiek88 wrote: post #85
swiley wrote: post #58

Earlier quoted context omitted.

Everything on the application processor is open source (think your laptop running debian.) The only thing that could break are the radios (wifi,bt,modem) becoming incompatible with the networks they communicate with but they're separate components anyway and the modem speaks a standard protocol so I'm sure it could be replaced.

>Everything on the application processor is open source (think your laptop running debian.) Even GPU?

The ancient Mali-400 GPU in the Pinephone seems to have an open source driver, yes. It also looks like it has been upstreamed into the kernel for years now.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#132

Post by Something1234 »

koolba wrote: post #123
dathinab wrote: post #83

Earlier quoted context omitted.

NoyesNo, Nvidia tried to make a doggy legally questionable workaround for license aspects, so it's not quite the same. Also as far as I remember (I might be wrong) the google HAL isn't a abstraction/redirection in the low level kernel module layer it lives on a higher abstraction level and was meant to make the amount of ways braking less but never planed to add abstractions on top of which you could build a graphics…

Still not as a bad as Linuxant: https://lwn.net/Articles/82305/

I'm having trouble understanding the issue was here. Linuxant produced a module that lied to the kernel about being a non-binary blob. Am I correct, but I'm still having trouble understand how the company survived since they seem to have a website up still.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#133

Post by codewiz »

dathinab wrote: post #15

It's not just Qualcomm it's closed source driver blobs in general. Even if your CPU might still be supported your other hardware might not. A common offender is camera drivers as far as I know and while you sometimes can still make the camera work it often comes with noticeable decreased quality (as the special patent encumbered closed source image post processing sausage is missing). Besides that potential but as fa…

> It's not just Qualcomm it's closed source driver blobs in general.

To be precise, Qualcomm's Linux drivers are GPL'd like the rest of the kernel. Drivers often come with firmware blobs and proprietary binaries in userspace, but it should be possible to keep the kernel driver compatible with both.

The actual reason why older SoCs stop working on newer Linux kernels is that Qualcom's drivers were not fully upstreamed, either because they didn't submit them, or because they tried, but there were quality issues.

In theory, anyone could port those drivers onto the latest Android kernel, but without hardware documentation it's not an easy job.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#134

Post by fakename11 »

garaetjjte wrote: post #100
bri3d wrote: post #77

Earlier quoted context omitted.

This is because the Linux kernel itself is constructed and developed in a way where driver interfaces (API) are ruthlessly refactored and the linker interface for kernel modules (ABI) is intentionally version-incompatible. If the driver's source code is not in the kernel, it doesn't gain the benefit of kernel developers doing this ruthless refactoring and falls behind immediately from a source point of view, and from…

>as an effort to make the cost of keeping drivers closed-source high I don't think it is intentional. Linux development is very pragmatic, they just want to have freedom to refactor anything without caring about stable kernel APIs.

It's somewhat pragmatic for the Linux developers. Support a stable kernel API probably wouldn't be that expensive. It's clearly a political decision against writing close source code that does anything low level.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#135

Post by codewiz »

bri3d wrote: post #77
techrat wrote: post #44

Earlier quoted context omitted.

What I don't understand (due to my ignorance, please explain if you can)... what keeps the driver blobs from continuing to work from one version of Android to the next? What prevents people from using the same drivers for a device on Android 7 and upgrading the OS to 9 or 10? I always understood that drivers would continue to allow the OS to recognize the component that the drivers are for unless something drasticall…

This is because the Linux kernel itself is constructed and developed in a way where driver interfaces (API) are ruthlessly refactored and the linker interface for kernel modules (ABI) is intentionally version-incompatible. If the driver's source code is not in the kernel, it doesn't gain the benefit of kernel developers doing this ruthless refactoring and falls behind immediately from a source point of view, and from…

Project Treble is already fully supported by Qualcomm and other SoC vendors, that's not the issue.

The issue is that Treble simply shifts the compatibility issues from on from one layer (kernel) to another (Android HAL). There's still a compatibility horizon, because newer Android systems will eventually want to use newer kernel features and HAL APIs which were not present on ancient HALs which have been abandoned by the vendor.

And even if the OS could theoretically maintain backwards compatibility with older HAL APIs for 10 years, in practice the System + HAL combinations which aren't fully tested tend to break for various unforeseen reasons, making it unwise to push OS updates to devices which aren't fully supported by their vendor.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#136

Post by boring_twenties »

rubatuga wrote: post #101
boring_twenties wrote: post #75

Earlier quoted context omitted.

When Intel released the microcode updates for the MDS family of vulnerabilities, in May 2019, they declined to support my Westmere Xeon, which launched in May 2010. So, not quite 10 years. Still a hell of a lot better than Qualcomm, though.

HP Z400 series got the microcode updates, so it was actually up to your vendor.

Hmm, don't think so. Vendors cannot create CPU microcode, Intel has to do that. And the relevant Intel document[1] clearly stated that they weren't going to do that.

The HP400 specs I found only list Bloomfield processors[2], not Westmere. Perhaps that is the source of your confusion?

1- https://www.intel.com/content/dam/www/public/us/en/documents...

2- https://support.hp.com/us-en/document/c01709672

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#137

Post by someperson »

someperson wrote: post #90
swiley wrote: post #63

Earlier quoted context omitted.

The answer is a monolithic GPL kernel that forces manufactures to publish driver source code but they don't want to admit it.

Or a Windows-style stable ABI with drivers remaining closed-source. That's what Google are doing with their new Fuchsia OS and Zircon kernel, which is expected to replace the GPL-licensed Linux kernel on Android and ChromeOS devices. Basically their moving away from the copyleft Linux kernel. Given Google's awful track record with Android and security updates, and their lack of ability to force companies like Qualcom…

> Hopefully Google's capability-based microkernel approach with Zircon will stop this ever happening.

Just a correction, I meant "Hopefully Google's capability-based microkernel approach with Zircon will reduce the incidence and severity of vulnerabilities being exploited once they are inevitably discovered".

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#138

Post by rubatuga »

boring_twenties wrote: post #136
rubatuga wrote: post #101

Earlier quoted context omitted.

HP Z400 series got the microcode updates, so it was actually up to your vendor.

Hmm, don't think so. Vendors cannot create CPU microcode, Intel has to do that. And the relevant Intel document[1] clearly stated that they weren't going to do that. The HP400 specs I found only list Bloomfield processors[2], not Westmere. Perhaps that is the source of your confusion? 1- https://www.intel.com/content/dam/www/public/us/en/documents... 2- https://support.hp.com/us-en/document/c01709672

X5690 (Westmere) works well in Z400. Here’s another article specifying the BIOS update:

https://www.techpowerup.com/forums/threads/new-microcode-for...

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#139

Post by surround »

> First, your SoC (System on a Chip) manufacturer (usually Qualcomm) has to get hold of it and customize Android for a particular SoC, adding drivers and other hardware support. Then, that build goes to your phone manufacturer (Fairphone, in this case) which adds support for the rest of the hardware—things like cameras, the display, and any other accessories.

Why is it so easy to boot any linux distro on almost any desktop computer? What makes it more difficult for phones?

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#140

Post by guerrilla »

surround wrote: post #139

> First, your SoC (System on a Chip) manufacturer (usually Qualcomm) has to get hold of it and customize Android for a particular SoC, adding drivers and other hardware support. Then, that build goes to your phone manufacturer (Fairphone, in this case) which adds support for the rest of the hardware—things like cameras, the display, and any other accessories. Why is it so easy to boot any linux distro on almost any d…

They aren't PCs. That was the purpose of the PC and open architecture. I don't know why mobile manufacuteres don't see it as beneficial to them though, but it's possibly just because it was such a rapidly developing space until recently and has yet to settle but something else could be at play.
Post reply on HN