[HN Gopher] Fairphone suggests Qualcomm is the biggest barrier t...
___________________________________________________________________
Fairphone suggests Qualcomm is the biggest barrier to long-term
Android support
Author : thg
Score : 155 points
Date : 2021-03-26 15:30 UTC (7 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| rektide wrote:
| worth noting that there has been really good progress reverse-
| engineering support for 2017's Snapdragon 845[1] (SD845). quad
| A76 + quad A55 on Samsung 10nm. pretty modern, all in all.
|
| generally i still feel tortured by the situation, by highest of
| high tech devices being unsupportable, unmaintainable after a
| couple years, and it seems like upstream support is the only
| available path to keep devices from turning to e-waste. however,
| there are some positive signs. most chips still have seen nearly
| no support from the chip makers, but we have seen, for example,
| Qualcomm land some additional support for some additional the
| SD845 gpu, for which reverse engineered support had already been
| nicely developing.
|
| we're also seeing more phones with Samsung, MediaTek, & some
| other chips. it's notable that none of the other chip makers have
| much of a presence in kernel upstreaming either. it's not just
| Qualcomm: everyone is very bad at making mobile devices able to
| be supported.
|
| i'm very interested to see what starts happening with cars, which
| face a similar supportability problem, but which are less
| disposable. long term kernel support has been extended greatly to
| enable a longer life. Google's Project Treble has created a
| device-driver abstraction layer to try to ease things along some.
| but it's very hard to imagine the sea-change necessary for
| commercial teams to take their work, & rebuild it, safely,
| successfully, easily, atop the complex drops of vendor code &c.
| chip makers have had an enormously difficult job supporting the
| teams making software, providing them updates that they can
| readily begin to use, and it's been a very conservative, slow,
| deliberate process. most technical folk seem anxious to shift the
| mode, to get more upstream support, such that kernel & system
| upgrades don't require carefully tailored support packages from
| the chip maker to make updates possible. the current pace feels
| very logjammed, there's so much custom code people shipping
| products rely on, and trying to make folks less critically
| dependent is such a powerful compelling vision for so many
| techies to improve supportability, to make updates shippable both
| faster & doable in the long term.
|
| [1] https://en.wikichip.org/wiki/qualcomm/snapdragon_800/845
|
| [2]
| https://www.phoronix.com/scan.php?page=news_item&px=Qualcomm...
| traverseda wrote:
| Isn't this (binary blob drivers) an obvious violation of the
| linux kernel's GPL license?
|
| I presume that there's a good reason why that isn't being
| enforced, but I would like to better understand why.
| bayindirh wrote:
| There are intentional loopholes left in the kernel to allow
| such drivers (Nvidia, fglrx, etc. are also closed source).
|
| There are some rules though: Kernel module is always open
| source and cannot use all the symbols. Also, using such driver
| marks the kernel tainted.
|
| There are some very valid reasons for not releasing open source
| drivers. NDA bound 3rd party code is one (Java had it, fglrx
| had it, HDCP stuff has it, Intel's old GPU drivers had it).
| Another reason is software based secret sauce. Again GPU
| drivers are the worst offenders in this class. Third reason is
| greed/being insecure. Lastly, some companies use this method to
| _effectively deprecate_ their products, so they can sell newer
| units more. Embedded space is the biggest example of this. I
| also worked with such vendor in a very unrelated product
| category. It 's unpleasant.
|
| I don't support any of these reasons, but I understand them
| from an economic sense. Some companies started to bake their
| magic into their hardware (Mellanox, AMD), so they can open
| their software completely. This is a much better path IMHO.
| monocasa wrote:
| For the most part, yeah, the closed source kernel blobs are
| blatant GPL violations. I've heard a cute legal theory as to
| why Nvidia's GPU blobs are at least grey area, but most of the
| other blobs don't follow that model.
| nanna wrote:
| Congratulations to Fairphone. This sounds like a massive task
| especially for such a small team. I run a Fairphone 3 and I
| couldn't be happier. Sure it was on the pricy side but it's
| served me well, takes great photos, has survived numerous drops
| (the phone protector shipped with it is great), looks
| cool,strikes up interesting conversations now and then, and will
| apparently have Android updates well into the future. Fairphone's
| a great company shipping a great product. Well worth the
| investment!
| imiric wrote:
| It's a decent device, but feels several generations behind any
| mid-range phone released in 2019. The screen has color blurring
| when scrolling especially visible with text, the fingerprint
| reader often doesn't get a good read, and it's noticeably
| sluggish in everyday tasks.
|
| I justified the higher price to support their vision, not
| because it's a great daily driver, but it serves well as a
| backup phone with /e/OS. The cameras can be upgraded to the 3+
| ones, so it's great that it's the only truly modular and DIY
| repairable device on the market.
|
| I wish that a chipset swap and upgrade would be possible
| though. Google's Project Ara was interesting, but it was
| probably infeasible, and the technology might not be there yet.
| luckylion wrote:
| How happy are you with the audio quality? I've been reading
| about issues with echoes on coip connections that seem to have
| been plaguing some people for quite some time. I dislike the
| cell phone audio quality by itself, but additional echoes would
| be a complete show stopper for me.
| nanna wrote:
| Really can't say I've experienced anything like this at all.
| Audio has always worked fine for me.
| [deleted]
| hvemsomhelst wrote:
| some qcom competitors pay ip designers for new android version
| drivers for designs from more than a decade ago
| zozbot234 wrote:
| Chipset support from the manufacturer is not, strictly speaking,
| essential. What we need is support in the mainline Linux kernel.
| Many of the custom hardware blocks that a kernel has to support
| via its drivers are shared across chipsets generations anyway, so
| they end up being supported a lot longer than any single HW
| platform.
| kelnos wrote:
| Right, and we're not going to get support in the mainline
| kernel without chipset manufacturer support. Namely in the form
| of open sourcing all the binary blobs, because those aren't
| going to be accepted into the mainline kernel.
|
| Qualcomm just doesn't want to do this. I'm not sure if it's
| because they don't feel like spending the developer time
| (money) to do so, or if they believe 2-year obsolescence is
| better for their bottom line. Probably both.
| zozbot234 wrote:
| The kernel- and user-space binary blobs can be replaced by
| the community. See freedreno, lima, panfrost, nouveau etc.
| swiley wrote:
| Have you seen the sunxi project?
| dathinab wrote:
| 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 far as I know less likely offenders
| include the modem.
|
| Ironically both might be integrated into the SoC which then
| massively increases the chance for problems.
| nobodywasishere wrote:
| Android should have been GPL
| pmlnr wrote:
| And how would that make any difference when it comes to radio
| firmware?
| herogreen wrote:
| The radio firmware could be executed on different CPU than
| the Android kernel and communicate with a standard protocol
| ?
| monocasa wrote:
| That's more or less what happens already.
| teruakohatu wrote:
| It is but if the radio driver was open source then the
| interface with the radio SoC would be documented.
|
| Right now it is the worst of both worlds. Closed
| interface for a closed undocumented chip able to execute
| arbitrary code.
| techrat wrote:
| 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 drastically changes on the OS side of things.
|
| Why can't we say "Fuck you, Qualcomm" and continue to use the
| older drivers for newer OS versions without having to wait for
| them to officially support it?
| pantalaimon wrote:
| Are you implying the 'no stable binary ABI' policy is
| responsible for a lot of e-waste?
| cwyers wrote:
| I mean, that seems to be the result, yes? The intent is to
| compel device manufacturers to release the source of their
| drivers, but at this point, I think we have to admit that's
| not a great description of what's happening in the mobile
| space.
| DaiPlusPlus wrote:
| > The intent is to compel device manufacturers to release
| the source of their drivers
|
| I doubt that was the "intent"... perhaps a contributory
| argument in favour of a non-stable ABI, but I understand
| the reasons are far more pragmatic: maintaining a stable
| kernel ABI is a _lot_ of work which could have strangled
| Linux in its early years.
| detaro wrote:
| With new Android versions come new kernel versions, and the
| interfaces to drivers are not stable, and I assume Android-
| specific interfaces also do change.
| [deleted]
| AdmiralAsshat wrote:
| It's mind-boggling to me that Qualcomm only guarantees 2-3 years
| of support for their chipset. Compare that to the PC processor
| space, how much does AMD/Intel provide? 10 years? More?
|
| Somehow people seem to be running on 15 year-old Thinkpads
| without a problem, yet a $1000 phone apparently can't scrape by
| for more than three years due to vendor support?
| zokier wrote:
| That got me thinking, why aren't Dell, HP, Lenovo etc selling
| "enterprise" Android phones? They could get probably pretty
| good margins on basic devices if they'd have good well-defined
| support periods. Bonus points for good MDM compatibility and
| various silly standard compliances that nobody cares about.
| Just being able to do purchases from same supplier as
| workstations seems like a major benefit for IT depts. They
| could probably do some bundle deals ("buy/lease workstation and
| get phone for free").
| boring_twenties wrote:
| 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.
| gruez wrote:
| >Compare that to the PC processor space, how much does
| AMD/Intel provide? 10 years? More?
|
| They don't "provide" anything. It's the software (eg.
| linux/windows) that's providing backwards compatible support.
| Vendor support for pc hardware lasts a few years at most.
| dyingkneepad wrote:
| Well, Intel's employees are fixing Intel drivers for Intel
| hardware released >15 years ago on the Linux Kernel main
| repository, among other trees such as the Mesa project. So
| yes they are providing support. Other companies do that too.
| boring_twenties wrote:
| They provide microcode updates.
| ZiiS wrote:
| Amd and Intel CPUs are still 100% backwards compatable with
| 40 year old chips. Not just their own chips but also nearly
| all the features of their competitor's chip too.
| gruez wrote:
| >Amd and Intel CPUs are still 100% backwards compatable
| with 40 year old chips
|
| The CPUs might be, but the chipset drivers definitely
| aren't. You'll have a hard time booting windows 95 on a
| ryzen system, for instance. Hell, ryzen doesn't officially
| support windows 7. Still, I get your point, standardization
| in the PC space (mainly stemming from the "IBM compatible"
| standard) has made backwards/forwards compatibility much
| easier.
| zokier wrote:
| Somewhat controversially at the time, Kaby Lake from
| Intel dropped Windows 7 support:
| https://arstechnica.com/information-
| technology/2016/01/skyla...
| zrm wrote:
| What anybody wants is the other way around though. If you
| want to run Windows 95 on modern hardware you run it in a
| VM; running it on bare metal isn't that interesting.
|
| And the current versions of various Linux distributions
| _do_ run on 25+ year old PC hardware, if you really want
| to.
| josephg wrote:
| True, but old hardware can run windows 10, or modern
| Linux just fine.
|
| Windows and Linux (and others) seem to hold the policy of
| drivers for old hardware being maintained and supported
| seemingly indefinitely. This work isn't free, but there's
| no reason Qualcomm and Samsung and others couldn't do the
| same.
| mmastrac wrote:
| It will be interesting to see what Project Treble brings to the
| table w.r.t. long term support for Android devices. It should
| help with the bitrot problem, though it pushes a bunch of stuff
| into blobs instead of creating long-term maintainable kernel
| source code.
| ArkanExplorer wrote:
| Google has been promising to 'solve' fragmentation and long-
| term support for almost a decade, and it doesn't seem like
| there is any real solution.
|
| If you interested in long-term updates, the answer is simple:
| buy an iPhone.
| swiley wrote:
| The answer is a monolithic GPL kernel that forces
| manufactures to publish driver source code but they don't
| want to admit it.
| chickenbane wrote:
| We agree that Google hasn't completely solved the support
| problem, but it's not to say Treble hasn't improved things.
|
| Android Pie: https://www.androidauthority.com/project-
| treble-2019-1045370... Android 11:
| https://9to5google.com/2020/12/16/android-updates-4-years/
| gruez wrote:
| Hasn't treble been around for years now?
| kogir wrote:
| Qualcomm is only able to obstruct in this way because Linux
| doesn't keep the kernel driver ABI stable for any fixed period of
| time.
|
| If Android used FreeBSD and Qualcomm shipped drivers for the
| latest build when the SoC was released, you'd have up to five
| years of support from that kernel release.
|
| Windows Phone 10 was actually in a position to support phones for
| years and even got Qualcomm onboard. It's a shame the platform
| was never competitive, and they'd burned all their goodwill on
| the 7 and 8 fiascos.
| kogir wrote:
| I'm going to reply to a few sibling comments at once:
|
| Yes, they could upstream drivers, but they won't. It's not in
| their best interest. I'm taking about what could be done _in
| spite_ of this.
|
| Given that they won't upstream drivers, if the blobs they
| release keep working for the reasonable life of your device,
| your phone can get other software updates, including major OS
| updates. I don't expect or need the camera or radio driver to
| change across various android versions. The hardware is the
| same!
|
| And if you want a newer phone, you're free to buy one! It's
| just sad that you can't safely use older devices just because
| the blobs break compatibility with OS security and feature
| updates. This need not be the case.
| rowanG077 wrote:
| This is not true. They could simply upstream the drivers.
| yokaze wrote:
| Two things:
|
| 1. There are longterm kernel releases, with up to 10 years
| support, and Android uses those exactly to avoid major support
| issues (https://en.wikipedia.org/wiki/Android_(operating_system
| )#Lin...).
|
| 2. That doesn't fix the issue that Qualcomm themselves do not
| want to release documentation and only want to support their
| hardware for up to two years. Ergo, you would run some outdated
| binary blob.
| CameronNemo wrote:
| FWIW I do not want to use a 5 year old kernel and I do want to
| use a 5 year old phone (LG V20).
| NullPrefix wrote:
| Just be happy that the kernel you get on your brand new phone
| is only 5 years old.
| foepys wrote:
| Example: the Nokia 7.2 was released at the end of 2019 and
| is running on Linux 4.4.194 on the newest available Android
| update. 4.4 was first released in January 2016 and is
| currently at 4.4.262. 4.4.194 was released in September
| 2019.
|
| The newest LTS release at the end of 2019 was 4.19,
| released in October 2018. 4.9 and 4.14 are also LTS
| releases. 4.4 is a bit special because it's a Super Long
| Term Support kernel but 4.19 is SLTS as well.
| toast0 wrote:
| > Windows Phone 10 was actually in a position to support phones
| for years and even got Qualcomm onboard. It's a shame the
| platform was never competitive, and they'd burned all their
| goodwill on the 7 and 8 fiascos.
|
| Regardless of how much goodwill they burned with 7 and 8, their
| handling of the WM 10 release nailed the coffin shut. They
| actually made a release that ran ok, but it was 18 months after
| the initial release. And Edge managed to be worse than mobile
| IE, but they were pretending to be Apple and disallowed
| competing browsers in WP. Grumble mumble, live tiles were nice.
| realusername wrote:
| Because the solution would be to actually upstream the
| necessary drivers or publish enough documentation that they
| could be created instead of doing hacks.
| swiley wrote:
| The Linux driver ABI doesn't need to be stable because the
| drivers are supposed to be published under the GPL. This way
| manufactures just need to help get their drivers upstreamed and
| are largely off the hook for support after that.
|
| Androids awful graphics API is hack that allows Qualcomm to
| keep the driver source closed which means the BSPs rot and you
| can't use your phone after 2-3 years.
|
| I'll happily buy a 10 year old SoC with half the clock speed
| but open source drivers over anything from Qualcomm because of
| how awful they are with this.
| pantalaimon wrote:
| There is actually quite some upstream work happening for
| Qualcomm SoCs these days, it's just a lot of effort.
| swiley wrote:
| Last I checked the official work the graphics drivers were
| completely left out.
| pantalaimon wrote:
| That would be freedreno, not sure how complete it is yet.
| swiley wrote:
| Freedreno didn't come from Qualcomm and I've been through
| two Qualcomm based phones since it was started. Last time
| I checked (and I did give up a couple years ago) they
| barely had framebuffer support on a couple SoCs I didn't
| have.
| j16sdiz wrote:
| 1. There are userspace blob too.
|
| 2. Android did change drivers architecture across version in
| the past. We are talking something as old as Android 6
| Decker87 wrote:
| I don't blame Qualcomm one bit. Why would they want to support
| old hardware long after 99% of people aren't using it?
| Naac wrote:
| People aren't using it because it is no longer receiving
| updates. 2-3 year old hardware should not be considered "old",
| or obsolete.
| phh wrote:
| What about Google? The issues fairphone mention are passing
| Google certification suites. They should be relaxed to help those
| cases. As far as I know the major issues are around GLES. It
| passed older CTS, so GLES was good enough back then. Surely it
| could be good enough now.
| flas9sd wrote:
| some Qualcomm SoCs (410c and 845c) are seeing mainline support. I
| booted a 5.11 kernel on an 2015 device yesterday and had
| surprisingly good working handheld with the pmOS/Phosh stack. Of
| course this is still a raw experience for enthusiasts, but one
| can use an AOSP distribution instead.
|
| The Fairphone concept of easily replacing common problems with
| screens and battery complements the longterm chipset support, one
| needs both. It wouldn't help the repair/replace decision if the
| screen needs 2 hours and heatguns to replace. Making it difficult
| to unlock the bootloader is another barrier manufacturers and
| mobile operators are guilty of.
|
| Mainline phones can be used until their counterpart antennas fall
| from the operators towers - and for 4G I think this is well into
| 2030.
| fsflover wrote:
| If you want lifetime updates for your phone, consider Librem 5
| [0] or Pinephone [1] instead. They do no rely on Android but use
| GNU/Linux as OS.
|
| [0] https://en.wikipedia.org/wiki/Librem_5
|
| [1] https://en.wikipedia.org/wiki/PinePhone
| judge2020 wrote:
| IIRC there are still some binary blobs on there which might not
| work after some breaking change down the line, right?
| swiley wrote:
| 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.
| bgorman wrote:
| Why would a company which holds an effective monopoly over
| Android chips in the US do anything in order to discourage the
| sale of new chips? Providing support for older chips would hurt
| sales.
|
| Qualcomm is abusing its monopoly position and the laws/patents
| that allow this need to be changed. Qualcomm is a great example
| of how IP laws can hurt progress and competition.
|
| In the future China and other countries will leapfrog the US in
| areas where competition is banned, because the only possible
| competitors will be in other countries.
| sto_hristo wrote:
| But Qualcomm doesn't have a monopoly on the market. There's
| Apple too. Sure, Android mostly uses Qualcomm in higher end
| models, but that is not the reason why Qualcomm can do anything
| they want.
|
| The reason things are the way they are is simple - users
| doesn't care. Users will happily throw cash the for next
| groundbreaking, awesome possum camera innovation that is just
| so totally worth the $1000 upgrade, because fabulous selfies
| are what people care about.
| kelnos wrote:
| Apple is only another player in "the market" if they start
| selling chips, or licensing their designs, for use in non-
| Apple products.
| angryasian wrote:
| Ok an oligopoly, does that make it better. Apple has a
| monopoly on Apple silicon.
| zepto wrote:
| Apple doesn't have a monopoly on Apple silicon nobody buys
| it.
| _Microft wrote:
| (Controversial?) opinion: patents encourage innovation because
| they force competitors to find new solutions instead of only
| copying existing solutions.
|
| That doesn't mean that it could not go terribly wrong as for
| example when patents blocked progress in 3D printing for
| decades.
| rorykoehler wrote:
| Most innovation comes from building on existing solutions.
| You're advocating reinventing the wheel
| esclerofilo wrote:
| Unfortunately, many patents are intentionally written to make
| them as broad as possible, minimizing the possibility of
| designing alternatives.
| ocdtrekkie wrote:
| Google holds a far stronger monopoly than Qualcomm ever will.
| If Google required the driver support as a condition of
| allowing Android devices to be distributed with their hardware,
| Qualcomm would have to comply overnight.
|
| Every single Android device from every manufacturer that wants
| access to Google apps must be approved by Google, and compliant
| with Google's terms. The "poor Google is at the mercy of other
| companies" narrative about Android's product line just doesn't
| square with the reality.
| [deleted]
| sitkack wrote:
| Time is now for an unencumbered SoC with fully available
| documentation, 1k+ pages downloadable as a complete set of PDFs
| along with a reference design.
___________________________________________________________________
(page generated 2021-03-26 23:00 UTC)