[HN Gopher] Qualcomm hardware support increasingly in good shape...
___________________________________________________________________
Qualcomm hardware support increasingly in good shape with Linux
kernel
Author : quic_bcain
Score : 40 points
Date : 2024-02-19 20:29 UTC (2 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| jauntywundrkind wrote:
| There really has been a huge shift for Qualcomm, and it's great
| to see.
|
| It's so interesting to me to guess how and where this is
| happening, what the pressure points are driving this. It feels
| like there's two areas that have been highly motivated to make
| Qualcomm more than good for limited-lifetime appliances running
| unmaintained kernel.
|
| First around were the motivated hobbyists, namely, OpenWRT.
| OpenWRT already had a close relationship with part of Qualcomm:
| the Atheros (acquired by Qualcomm in 2011 for $3.1B) wifi
| chipsets were the linux wifi chips to have. But as MIPS faded and
| ARM rose, Qualcomm become more and more dominant in OpenWRT
| space. Trying to port vendor SDKs and drivers in, and then work
| on more upstream support, has been a long running OpenWRT
| project. I myself own a number of Nighthawk X4S/R7800 (IPQ4019
| chipset, 802.11ac wave-2) routers (Maybe soon time to move on, if
| only there were good options!).
|
| Those efforts to upstream are really getting to a good spot these
| past couple years. ipq40xx was ok but rough. After some kind of
| iffy early chip releases that seem destined to never be
| supported, most recent ipq80xx chipsets with 802.11ax/wifi6 seem
| well supported on mainline. But it's still not ideal: Qualcomm
| has a bunch of iptables-bypassing network-processing offloading
| support for the +2 of it's 4+2 cores, that is unlikely for
| OpenWRT to ever support (https://forum.openwrt.org/t/xiaomi-
| ax3600-performance-thread...). Especially as wifi speeds tick
| higher it's unlikely new routers will be able to go fast enough
| unless there's some breakthrough in network-offload, and with
| great solutions like VPP about it's not impossible, but it seems
| unlikely & requiring quite a heroic feat to even get started
| reverse engineering & beginning the process. (Personally it makes
| me just want to use x86 based routers with m.2 cards for APs &
| skip Qualcomm cpus.)
|
| The other prong of upstreaming comes from a very different place:
| Google. Specifically Chromebooks, which have really pushed hard
| for support to get upstreamed on supported platforms. I think it
| might now be an out and out requirement to have upstream support!
| This added real weight to the drive to upstream. We also see
| MediaTek having done amazing things with getting their stuff
| upstreamed, often seeing chips consumers wont see for _years_
| getting kernel support, with many of the target boards becoming
| future Chromebooks. Chips like the 8cx were pretty early onboard
| here.
|
| The chip here is more phone oriented, a Snapdragon Gen 3. Things
| seemed to really start going much faster a year or two back.
| Looking at PostmarketOS, the support matrix really isn't bad for
| mainline kernels and top-tier chips
| (https://wiki.postmarketos.org/wiki/Qualcomm_mainline_porting)!
| I'd love to see support expanded for lower-market chips (such as
| the 7+ Gen 2, https://www.anandtech.com/show/18775/qualcomm-
| announces-snap...), which looks like it'd be a great mid-range
| tablet/small desktop core, if supported.
|
| It's still quite hazy to me how much Qualcomm is actually
| supporting/helping these efforts, versus how much is paid or free
| open source work. But, _the future is exciting._ Being able to
| run non-Android OSes really starts here. I don 't know what
| specifically the changes will be, but able to have devices evolve
| & change beyond just being consumer appliances opens the doors of
| possibility, to new forms of computing. Letting folks adapt &
| change systems around them keeps giving rise to exciting new
| things, and I'm for it!
| charcircuit wrote:
| Don't forget about Android where Qualcomm is popular too.
| Having upstream support is important for GKI since not
| everything can just be a kernel module.
| jauntywundrkind wrote:
| I'm having a heckuva time reading the tea leaves on GKI.
|
| On the one hand, we might actually be able to upgrade
| kernels! Neat, overdue, necessary. S24 has 7 years of
| updates! Why & what changed? Well, there's decent upstream
| support. Ok, so they can keep the computer running. But the
| phone is basically a whole second system, and GKI promise to
| let them keep the phone parts running along as is, while the
| computer part changes. This is cool.
|
| I'm a bit scared though too. We're opening a pandora's box
| where a good portion of the computer's drivers are no longer
| running on Linux. How many of the upstreaming efforts that
| are now underway will be undermined by folks running vendor
| blobs against the stable & closed Google Kernel Interface,
| instead of the changing & GPL Linux Kernel Interface? GKI
| seems like an insane threat to mainstream winning; it's a
| totally parallel constructed world designed to avoid the need
| to mainstream, and that's basically a horror.
|
| I'd love to see a Google Kernel Interface run on a non-
| Android device. If I can run a Debian phone & have all the
| fancy bits and bobs work, I won't feel so bad about GKI. But
| it feels like GKI is custom-bred for Android specifically,
| and that Google is pulling off the mother of all _Embrace,
| Extend, and Extinguish_ es against Linux, is finally going to
| subvert & dethrone the Linux kernel by wrapping it & making
| everyone target that (& have the wrapper be ultra-coupled to
| Android).
| zozbot234 wrote:
| GKI is short for Generic Kernel Images. Android kernels
| have always been heavily forked compared to mainline, this
| is not a new feature of GKI's. And if anything, the
| distance is shrinking over time, not getting larger. It's
| not Google's fault that manufacturers' BSP's tend to rely
| on proprietary blobs, that's always been common throughout
| the embedded ecosystem.
|
| > If I can run a Debian phone & have all the fancy bits and
| bobs work, I won't feel so bad about GKI.
|
| You can try Droidian, it's a Mobian fork configured to run
| as a GSI. You'll be running proprietary kernel modules and
| relying on Android's low-level layers (which is a somewhat
| unstable arrangement, since we don't know how these may
| change in future devices) but at least the system level and
| UX will be a plain Linux userspace.
| mschuster91 wrote:
| > It's not Google's fault that manufacturers' BSP's tend
| to rely on proprietary blobs, that's always been common
| throughout the embedded ecosystem.
|
| If there is one entity that could have changed this years
| ago, it was Google, especially after Microsoft ditched
| Windows Phone.
|
| Look, I'm no friend of big corporations strong-arming
| their will around, but in this case it might have been
| good for once. Instead, you get a hellscape of Samsung
| messing around deep in Android Core (as everyone who
| wants to develop a long-running background app is likely
| to hit), and rooting being an extremely painful process
| that will brick about half the apps on your phone.
| stefan_ wrote:
| I guess the good news is that if I remember correctly, the NSS
| stuff was already dropped again for the next generation...
|
| There is also the whole interesting disconnect where they
| employ one or two cranky old timers to maintain the upstream
| ath drivers, then have the usual Indian teams write untested
| rushed upstream "support" patch series for the routing WiFi
| chips. The old timers don't want to test them because they
| believe their job is in the tiny and shrinking Qualcomm laptop
| WiFi market and the Indian teams don't test by doctrine and
| superior orders. And this is for the Qualcomm-on-Qualcomm case;
| they fare much worse trying to submit patch series for all the
| other bits and pieces you need to make the Qualcomm SOC work
| that invariably comes with the routing WiFi chips.
| jacooper wrote:
| I was excited for the upcoming snapdragon X elite till I saw this
|
| > But still a work-in-progress is audio support, DP Alt-Mode,
| enabling the DSPs, USB-C power delivery, and _GPU acceleration_
|
| No GPU acceleration? And somehow this is seen as good support?!
| The reverse engineered Asahi Linux driver has better support than
| whatever this is.
| protastus wrote:
| 100% agree with you.
|
| Qualcomm historically wrote awful OSS code that couldn't be
| upstreamed because it barely worked on a subset of their own
| SoCs, and broke basic function for everything else. Typically
| featuring incredibly invasive architectural changes that
| patched far too many layers of the OS with unmaintainable code.
|
| QC then converted bad code into a business model, nickel and
| diming OEMs who needed bugs fixed to ship their products.
|
| The idea that QC SoCs now have good upstream support is bizarre
| to me. At best, it means a few high volume SoCs can boot to
| console on reference designs. Forget about peripheral support
| for things anyone would take for granted, like audio and GPU.
| zozbot234 wrote:
| Every mainline-supported device starts out as "booting to
| console". GPU support on ARM SoC's is currently achieved
| through a variety of community-developed drivers, such as
| lima and panfrost. That part at least is comparatively well-
| understood. The manufacturer does not directly support these
| community drivers, so it's not very clear how much Qualcomm
| could help there.
| protastus wrote:
| There are so many ways they could help. For GPU, they could
| support freedreno (both the kernel and Mesa parts) instead
| of KGSL and the closed source Adreno libraries.
|
| A great start would be to make the user space Adreno GLES
| libraries talk to the freedreno DRM backend. So one could
| use the QC proprietary GLES libs with a mainline kernel
| without rebuilding with KGSL.
|
| There's a similar story here for every subsystem driver,
| where they insist on a brittle proprietary solutions (one
| branch for every chip!) that can't be upstreamed.
| dirkf wrote:
| On a related note: I have the impression Broadcom is more and
| more losing terrain to the likes of Qualcomm and Mediatek. A
| couple of years ago nearly everybody was using Broadcom chips in
| their products (or at least in the consumer-grade telecom devices
| I'm familiar with as part of my job). Now I'm seeing a shift away
| from them.
|
| I can't really say if it's due to better features, price, vendor
| support, open source support, documentation, or perhaps all of
| the above. In any case, some competition is certainly welcome.
| stragies wrote:
| If you check out the forum.openwrt.org, you'll see, that
| broadcom support is mostly limited to Raspberry PI devices, and
| some 400Mhz museum pieces.
|
| 9/10 times the turned-down requests for OpenWrt support of
| Device XY are because of Broadcom SOCs/Wireless_chips in the
| device.
| seba_dos1 wrote:
| One thing I noted from the FOSDEM talk is that even though
| Qualcomm supports mainlining through Linaro, it's done based on
| existing code (both NDAed and public) and there's close to no
| documentation provided neither publicly nor privately to the
| devs. When you'll happen to work on that code in the future in
| mainline Linux trying to catch some bug, all you'll have to
| cross-check things with may be the same buggy code you try to fix
| - so in the end it's just like it would be reverse engineered,
| but without all the notes that community may have produced while
| trying to understand the thing.
___________________________________________________________________
(page generated 2024-02-19 23:01 UTC)