4 ms·

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 p

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/151942/31 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 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-snapdragon-7-gen-2-premium-segment-gets-a-cortexx-core 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 3y ago
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 3y ago
  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 Extinguishes 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 3y ago
    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.

charcircuit 3y ago

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 3y ago
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 Extinguishes 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 3y ago
  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.