[HN Gopher] Upstream Linux support available for Qualcomm Snapdr...
___________________________________________________________________
Upstream Linux support available for Qualcomm Snapdragon 8 Gen 3
Mobile Platform
Author : fsflover
Score : 86 points
Date : 2023-10-31 18:01 UTC (4 hours ago)
(HTM) web link (www.linaro.org)
(TXT) w3m dump (www.linaro.org)
| fsflover wrote:
| I wonder if one can run GNU/Linux like PureOS on the respective
| devices.
| neilalexander wrote:
| Perhaps with this, the Microsoft Dev Kit 2023 will turn out to be
| a decent option for Linux on ARM.
| entropicdrifter wrote:
| Meh, still worse than a 2020 M1 Mac Mini
| neilalexander wrote:
| Unless you like RAM. The Dev Kit comes with 32GB as standard.
| entropicdrifter wrote:
| Fair point. For my workloads compute matters a lot more
| than RAM, but it's not as straightforward a trade-off as I
| was initially thinking
| tjoff wrote:
| If you want to support an ecosystem that goes against your
| own interest. Sure, but what would cause you to be that
| shortsighted?
| entropicdrifter wrote:
| I run my M1 Mac Mini with Asahi Linux?
|
| I'm not a big fan of _any_ SoCs which have soldered-on RAM
| or storage, but I find it an odd point to argue that I 'm
| supporting Apple's ecosystem overall when all I did was buy
| their hardware on sale. Their App Store is by far their
| biggest money-maker.
| tjoff wrote:
| You are supporting the biggest threat to the open
| platforms we have. And you are actively not supporting
| the ones that keep it alive.
|
| How is that an odd argument? Voting with your wallet
| suddenly doesn't count because shiny?
| wmf wrote:
| I would say it doesn't count because they're all "evil".
| Apple, Intel, AMD, Qualcomm, Microsoft... The only stuff
| that's close to being truly open like Freescale and Talos
| is completely obsolete and overpriced.
| fsflover wrote:
| Purism, System76, Framework etc. are not evil.
| pjmlp wrote:
| If only the hardware on their laptops would be 100%
| functional.
| fsflover wrote:
| Works quite well for me.
| tjoff wrote:
| Yeah, no, that is delusional.
|
| Sure, you can go the purist route if you want. But it is
| not either or, few things in life are.
| bfrog wrote:
| With or without binary blobs and undocumented registers/IPs?
| nomel wrote:
| Naive question. What's the practical impact for not having
| these? It seems that AMD and Intel are also guilty.
| lrvick wrote:
| Those blobs, if backdoored, could have massive security
| implications.
|
| Also those blobs are often targeted at specific kernel
| versions, so in 2 years when the upstream vendors stop
| releasing updated blobs, then it no longer becomes possible
| to upgrade the kernel, making it very very hard to keep last
| gen devices secure.
|
| This exact problem is why I was forced to admit there is no
| secure path to use Android today, and a big reason why I gave
| up on smartphones entirely.
| fsflover wrote:
| > and a big reason why I gave up on smartphones entirely
|
| This is not necessary: my Librem 5 doesn't rely on blobs in
| kernel and runs FSF-endorsed GNU/Linux, PureOS.
| fifteen1506 wrote:
| Pixels may also be an option -- though Librem 5 is, in
| this context, better.
|
| Pixels Pro have now... 7 or 8 years support.
| dawidpotocki wrote:
| Because Purism cheated and just moved the blobs into a
| chip that you can't update and made it go through a
| separate processor[1]. FSF-endorsement is meaningless.
| This is worse than having a loadable blob from a kernel.
|
| [1]: https://puri.sm/posts/librem5-solving-the-first-fsf-
| ryf-hurd...
| nomel wrote:
| AMD and Intel both have their share of proprietary blobs,
| in their "open source" packages, including microcode. Where
| do you see a secure path, for any computing, especially
| high performance?
| yjftsjthsd-h wrote:
| > Where do you see a secure path, for any computing,
| especially high performance?
|
| I believe POWER9 is the only modern option that doesn't
| use blobs? Of course that doesn't remove the possibility
| of hardware backdoors (nothing does, except maybe an
| electron microscope and a lot of free time), but that's a
| higher bar.
| AnthonyMouse wrote:
| People rightly disapprove of the AMD and Intel blobs and
| do what they can to disable or remove them, but at least
| those have stable interfaces that don't decay when there
| is a new kernel version. Basically every x86_64 processor
| ever made can run the latest version of the Linux kernel.
| Would that it were for Qualcomm.
| nomel wrote:
| > do what they can to disable or remove them
|
| Is there open source microcode, at this point? I can't
| find anything that suggests there is.
| fsflover wrote:
| The parent probably speaks of Intel ME
| neutralizing/disablement.
| fsflover wrote:
| https://www.gnu.org/philosophy/free-software-even-more-
| impor...
| foobiekr wrote:
| Someone knows Qualcomm.
| wyldfire wrote:
| As a practical matter, I think the article happens to describe
| the steps to test it out yourself. I suppose the absence of a
| mention of binary blobs doesn't necessarily mean that they're
| not being used, I think it's plausible that there aren't
| (m)any.
|
| > How do I run AOSP using Mainline?
|
| > One might think it is quite hard to run AOSP with mainline on
| such a new platform, but in reality, not at all! Thanks to the
| long term effort of Linaro and Google engineers making it
| possible to run AOSP with vanilla Linux releases. Thanks to
| Amit Pundir for providing a helping hand to get AOSP on this
| platform.
|
| > To generate an AOSP image for the Snapdragon 8 Gen 3 Qualcomm
| Reference Device using the current set of patches available on
| the mailing list, use the following instructions, which are
| derived from here
| https://source.android.com/docs/setup/build/devices with some
| small changes.
| spookie wrote:
| This is quite refreshing! Thanks for the details
| almatabata wrote:
| At minimum i expect QSEE and all their TAs to remain binary
| blobs, like the keymaster for example.
| aseipp wrote:
| The kernel will work fine, but at minimum EL2 runs the Qualcomm
| Hypervisor (Gunyah) which prevents native KVM virtualization
| from taking place. This is true of all Snapdragon platforms.
|
| Windows supports virtualization on the 8 Gen 3 only because
| they use a custom setup to load a signed binary blob ("applet")
| into the EL2 hypervisor, whose signature it is is hardcoded to
| accept, and that blob/applet then can be used by Windows as a
| kind of shim into EL2-land to spawn VMs, etc. But Qualcomm's
| hypervisor is always present and enforcing its security policy.
|
| In practice every single modern system is running tons of
| binary firmware blobs, it's mostly where you draw the line on
| functionality and isolation of components (security, integrity,
| availability.) Here, Qualcomm does intentionally reduce some
| functionality, which is pretty bad when you consider that the
| UEFI spec for ARM mandates EL2 handover, I think, and they just
| ignore it.
| asddubs wrote:
| What's EL2 exactly?
| baby_souffle wrote:
| > What's EL2 exactly?
|
| Probably execution level 2.
| Avery3R wrote:
| Exception Level 2 [1] They're analogous to "protection
| rings" on x86. Generally, EL0 is usermode, EL1 is kernel
| mode, EL2 is hypervisor, and EL3 is the "secure
| monitor"/firmware code, closest analogy I think would be
| SMM on x86. On top of all of that there's also trustzone
| with its own EL0 and EL1.
|
| 1: https://developer.arm.com/documentation/102412/0103/Priv
| ileg...
| thomastjeffery wrote:
| > In practice every single modern system is running tons of
| binary firmware blobs
|
| This is a problem we should be loud critics of. Proprietary
| firmware hurts us all, and practically benefits no one.
| fsflover wrote:
| It's a bit better in Pinephone:
| https://news.ycombinator.com/item?id=36659544
| dmitrygr wrote:
| > In practice every single modern system is running tons of
| binary firmware blobs
|
| This one does not: https://www.amazon.com/ASUS-C100PA-
| DB02-10-1-inch-Chromebook...
|
| The SoC's boot ROM is 32K, fully inspectable, does not linger
| once the OS is booted. Every other software component is
| built from source and you can replicate it
| fragmede wrote:
| Even the broadcom-based wifi card? my read of
| https://wireless.wiki.kernel.org/en/users/drivers/brcm80211
| says for the 4354 in the c100, you need firmware, for
| brcmfmac.
| dmitrygr wrote:
| You are right.
|
| (I use a usb-to-ethernet dongle and the wifi card is
| disabled, but you are right in theory)
| robert_foss wrote:
| The GPU probably runs a firmware blob. Other than that Linaro
| is serious about upstream support.
| flakiness wrote:
| It doesn't cover either GPU or ISP (image processing unit). Not
| sure about NPU. Does Hexagon support cover that?
|
| It's still a nice progress though.
| robert_foss wrote:
| ISP won't happen. GPU is just a matter of time, and has been
| enabled for previous platforms.
| apatheticonion wrote:
| Will this help bring Linux to the upcoming Qualcomm Elite X
| laptop SoC?
|
| A viable Linux ARM laptop would be cool, especially if it
| promised high performance and long battery life!
___________________________________________________________________
(page generated 2023-10-31 23:00 UTC)