Lumia 1520 Linux update: the audio hardware is finally talking!
Hey everyone,
It's been a minute since I posted an update on the Lumia 1520 mainline Linux project ....and this one ended up being a pretty big step forward.
Last time I posted, the phone was already at a pretty solid baseline... Linux was cold booting reliably, display/touch/buttons were working, USB networking + SSH were stable, suspend/resume was working, battery telemetry and backlight control were in place, etc.
Since then I've been digging into one of the bigger missing pieces: audio....a fucking nightmare lol
At first, I thought it might hit the same wall as WiFi. The Lumia's audio stack uses Qualcomm's ADSP co-processor, and I wasn't sure whether the Windows Phone TrustZone would even allow it to boot.
Turns out it does....
The ADSP now boots successfully, APR communication with it works, and I was able to bring up MSM8974's ADSP managed SLIMbus transport. That led to the actual codec on the phone. And at this point I've confirmed from the hardware itself that the Lumia 1520 uses a Qualcomm WCD9320 / Taiko codec.
Not just inferred from old Qualcomm sources either...Linux is physically enumerating it over SLIMbus and reading its own identification registers back as major ID "0x0102".
The codec actually exposes two separate SLIMbus functions:
PGD - control/register access
IFD - the audio port/channel interface
Both now enumerate independently and get their own logical addresses. From there I built out proper regmap access, power/reset handling, fresh bring-up, non-destructive late adoption, and the beginnings of the codec interrupt support.
The interesting part was the digital core. A large section of the codec's register map kept returning zero, which initially sent me down a rabbit hole looking for the external 9.6 MHz MCLK. I dumped the Lumia's ACPI tables, RPM clocks, all 36 PM8941 GPIOs and all 8 MPPs trying to find where Nokia routed it. That investigation was...."useful", but the clock wasn't actually the blocker.
The real issue was that Linux had never executed Qualcomm's original "wcd9xxx_bring_up()" sequence. Every audio milestone before this had been read only, so the missing initialization stayed hidden.
Once I implemented the downstream bring-up sequence and switched the codec onto its internal RC oscillator, the result was immediate:
87/87 previously inaccessible sentinel registers became readable.
71 matched Qualcomm's documented defaults exactly, and the remaining 16 fall into three consistent register families that appear to be revision-specific differences.
So the chain now looks like:
Linux → ADSP → QRTR/QMI → BAM → SLIMbus NGD → WCD9320 PGD/IFD → regmap → codec core release → internal RCO → digital core accessible
I also mapped the codec's interrupt parent to Lumia TLMM GPIO 72 and validated it electrically idle across direct sampling and suspend/resume testing. I haven't claimed full IRQ support yet because I haven't deliberately generated and cleared a real codec interrupt source.
And just to be clear: there is still no audible sound output yet. I'm not calling audio "working" until PCM data actually reaches an output.
What this does mean is that most of the unknown hardware/transport side of Lumia audio is now gone. What's left is the actual codec/ASoC implementation work: permanent automatic core initialization, nested IRQ handling, DAIs and SLIMbus port configuration, the MSM8974/Lumia machine driver, and then finally a fixed playback route to get the first test tone out of the phone.
I'm deliberately finishing the Lumia's hardware enablement before I start layering my RegenX OS work onto it. I'd rather have a known-good hardware platform first than end up debugging kernel/driver problems and OS layer problems at the same time.
Wi-Fi/BT is still the major documented blocker, charging still needs more work, and modem/camera remain further out.... but audio has gone from "this may require an entirely missing upstream stack" to actual driver development on hardware that is responding exactly where it
Hey everyone,
It's been a minute since I posted an update on the Lumia 1520 mainline Linux project ....and this one ended up being a pretty big step forward.
Last time I posted, the phone was already at a pretty solid baseline... Linux was cold booting reliably, display/touch/buttons were working, USB networking + SSH were stable, suspend/resume was working, battery telemetry and backlight control were in place, etc.
Since then I've been digging into one of the bigger missing pieces: audio....a fucking nightmare lol
At first, I thought it might hit the same wall as WiFi. The Lumia's audio stack uses Qualcomm's ADSP co-processor, and I wasn't sure whether the Windows Phone TrustZone would even allow it to boot.
Turns out it does....
The ADSP now boots successfully, APR communication with it works, and I was able to bring up MSM8974's ADSP managed SLIMbus transport. That led to the actual codec on the phone. And at this point I've confirmed from the hardware itself that the Lumia 1520 uses a Qualcomm WCD9320 / Taiko codec.
Not just inferred from old Qualcomm sources either...Linux is physically enumerating it over SLIMbus and reading its own identification registers back as major ID "0x0102".
The codec actually exposes two separate SLIMbus functions:
PGD - control/register access
IFD - the audio port/channel interface
Both now enumerate independently and get their own logical addresses. From there I built out proper regmap access, power/reset handling, fresh bring-up, non-destructive late adoption, and the beginnings of the codec interrupt support.
The interesting part was the digital core. A large section of the codec's register map kept returning zero, which initially sent me down a rabbit hole looking for the external 9.6 MHz MCLK. I dumped the Lumia's ACPI tables, RPM clocks, all 36 PM8941 GPIOs and all 8 MPPs trying to find where Nokia routed it. That investigation was...."useful", but the clock wasn't actually the blocker.
The real issue was that Linux had never executed Qualcomm's original "wcd9xxx_bring_up()" sequence. Every audio milestone before this had been read only, so the missing initialization stayed hidden.
Once I implemented the downstream bring-up sequence and switched the codec onto its internal RC oscillator, the result was immediate:
87/87 previously inaccessible sentinel registers became readable.
71 matched Qualcomm's documented defaults exactly, and the remaining 16 fall into three consistent register families that appear to be revision-specific differences.
So the chain now looks like:
Linux → ADSP → QRTR/QMI → BAM → SLIMbus NGD → WCD9320 PGD/IFD → regmap → codec core release → internal RCO → digital core accessible
I also mapped the codec's interrupt parent to Lumia TLMM GPIO 72 and validated it electrically idle across direct sampling and suspend/resume testing. I haven't claimed full IRQ support yet because I haven't deliberately generated and cleared a real codec interrupt source.
And just to be clear: there is still no audible sound output yet. I'm not calling audio "working" until PCM data actually reaches an output.
What this does mean is that most of the unknown hardware/transport side of Lumia audio is now gone. What's left is the actual codec/ASoC implementation work: permanent automatic core initialization, nested IRQ handling, DAIs and SLIMbus port configuration, the MSM8974/Lumia machine driver, and then finally a fixed playback route to get the first test tone out of the phone.
I'm deliberately finishing the Lumia's hardware enablement before I start layering my RegenX OS work onto it. I'd rather have a known-good hardware platform first than end up debugging kernel/driver problems and OS layer problems at the same time.
Wi-Fi/BT is still the major documented blocker, charging still needs more work, and modem/camera remain further out.... but audio has gone from "this may require an entirely missing upstream stack" to actual driver development on hardware that is responding exactly where it
should.
Repo is still public for anyone who wants to follow the work:
github.com/KorelisLabs/lumia-1520-mainline
https://redd.it/1vnmmki
@r_linux
Repo is still public for anyone who wants to follow the work:
github.com/KorelisLabs/lumia-1520-mainline
https://redd.it/1vnmmki
@r_linux
GitHub
GitHub - KorelisLabs/lumia-1520-mainline: Mainline Linux / postmarketOS for the Nokia Lumia 1520 (bandit) - display, touch, USB…
Mainline Linux / postmarketOS for the Nokia Lumia 1520 (bandit) - display, touch, USB, SSH working - KorelisLabs/lumia-1520-mainline
Epic Games Store Will Support Linux "Soon"
https://steamdeckhq.com/news/epic-games-store-will-support-linux-soon/
https://redd.it/1vo190f
@r_linux
https://steamdeckhq.com/news/epic-games-store-will-support-linux-soon/
https://redd.it/1vo190f
@r_linux
Steam Deck HQ
Epic Games Store Will Support Linux "Soon" - Steam Deck HQ
The Epic Games Store will be coming to Linux soon, which should make accessing our free weekly games significantly easier on Steam Deck.
RustDesk now supports unattended remote access on Wayland, including the login screen and multi-monitor setups
https://rustdesk.com/blog/unattended-remote-access-wayland/
https://redd.it/1voba2b
@r_linux
https://rustdesk.com/blog/unattended-remote-access-wayland/
https://redd.it/1voba2b
@r_linux
RustDesk
Unattended Remote Access on Wayland with RustDesk
RustDesk brings true unattended remote access to Wayland, with multi-monitor support. A preview build for x86_64 Debian/Ubuntu-based systems is available now.
Alternatives to VS Code that aren't slop factories?
Admittedly might say a lot about my knowledge, or lack thereof, but I just can't seem to click with VS Code or Codium, for whatever reason. It just fundamentally feels too… Corporate? Not to mention how absolutely nothing works right, at least for me.
I've looked into other recommendations, like the many options that Jetbrains offers, and Zed, but both have become some AI infested cesspools (much like regular VS Code), so they're dead in the water now too.
Emacs is a nightmare, since I don't feel like spending 3 weeks to get a grip on a single program. Vim is basically just a text editor, so it feels lacking. What other options are there, at this point? At this point just a Notepad++ clone would do. And I know, "just don't use the AI"; that's not the point. Any company that willingly shoves cancer into their program, is one that I want nothing to do with.
https://redd.it/1voe9ti
@r_linux
Admittedly might say a lot about my knowledge, or lack thereof, but I just can't seem to click with VS Code or Codium, for whatever reason. It just fundamentally feels too… Corporate? Not to mention how absolutely nothing works right, at least for me.
I've looked into other recommendations, like the many options that Jetbrains offers, and Zed, but both have become some AI infested cesspools (much like regular VS Code), so they're dead in the water now too.
Emacs is a nightmare, since I don't feel like spending 3 weeks to get a grip on a single program. Vim is basically just a text editor, so it feels lacking. What other options are there, at this point? At this point just a Notepad++ clone would do. And I know, "just don't use the AI"; that's not the point. Any company that willingly shoves cancer into their program, is one that I want nothing to do with.
https://redd.it/1voe9ti
@r_linux
Reddit
From the linux community on Reddit
Explore this post and more from the linux community
Unlocking Encrypted Linux With a YubiKey
https://mhdez.com/posts/unlocking-encrypted-linux-with-a-yubikey/
https://redd.it/1vo3t0o
@r_linux
https://mhdez.com/posts/unlocking-encrypted-linux-with-a-yubikey/
https://redd.it/1vo3t0o
@r_linux
Miguel Hernández
Unlocking Encrypted Linux with a YubiKey
A step-by-step guide to upgrading a LUKS-encrypted Linux system to use a YubiKey for FIDO2-based unlocking, moving beyond traditional passphrases.
Number of Linux Distributions Actively Under Development: 474
Number of Linux distributions actively under development: 474
Number of Linux distributions whose development has been discontinued: 657
Number of Dormant Linux distributions: 39
Source: distrowatch.com
https://redd.it/1voipy0
@r_linux
Number of Linux distributions actively under development: 474
Number of Linux distributions whose development has been discontinued: 657
Number of Dormant Linux distributions: 39
Source: distrowatch.com
https://redd.it/1voipy0
@r_linux
Distrowatch
DistroWatch.com: Put the fun back into computing. Use Linux, BSD.
News and feature lists of Linux and BSD distributions.
Why and how the Austrian Military moved to LibreOffice (Part 2)
https://blog.documentfoundation.org/blog/2026/08/14/why-and-how-the-austrian-military-moved-to-libreoffice-part-2/
https://redd.it/1vnz8vg
@r_linux
https://blog.documentfoundation.org/blog/2026/08/14/why-and-how-the-austrian-military-moved-to-libreoffice-part-2/
https://redd.it/1vnz8vg
@r_linux
TDF Community Blog
Why and how the Austrian Military moved to LibreOffice (Part 2) - TDF Community Blog
This is the second part of our interview with the Bundesheer (see here for the first). At the LibreOffice Conference 2025, you showcased the new LibreOffice features sponsored by the Austrian Armed Forces. How did that come about? From the very beginning…
Debian has begun voting on the future of AI/LLM contributions.
https://lists.debian.org/debian-devel-announce/2026/08/msg00002.html
https://redd.it/1vooifz
@r_linux
https://lists.debian.org/debian-devel-announce/2026/08/msg00002.html
https://redd.it/1vooifz
@r_linux
Reddit
From the linux community on Reddit: Debian has begun voting on the future of AI/LLM contributions.
Posted by Two-Of-Nine - 23 votes and 1 comment
Possible Linux logo submissions from 1996 competition
Just found this site, and I can't verify the authenticity of the submissions but it looks very 1996-y to me.
https://www.cs.earlham.edu/\~jeremiah/linux-pix/linux-logo.html
I thought it was pretty cool so I wanted to share it here!
https://redd.it/1vovk4y
@r_linux
Just found this site, and I can't verify the authenticity of the submissions but it looks very 1996-y to me.
https://www.cs.earlham.edu/\~jeremiah/linux-pix/linux-logo.html
I thought it was pretty cool so I wanted to share it here!
https://redd.it/1vovk4y
@r_linux
Terminal file manager nnn v5.3 released
https://github.com/jarun/nnn/releases/tag/v5.3
https://redd.it/1vp4est
@r_linux
https://github.com/jarun/nnn/releases/tag/v5.3
https://redd.it/1vp4est
@r_linux
GitHub
Release nnn v5.3 Mai Tai · jarun/nnn
nnn v5.3 Mai Tai release notes.
add native preview pane (P) with automatic .npreview support
fuzzy filtering improvements:
scoring, ranking, character arbitration
dimmed matches (works with str...
add native preview pane (P) with automatic .npreview support
fuzzy filtering improvements:
scoring, ranking, character arbitration
dimmed matches (works with str...
#40262 Excessive IO caused by systemd-journald
https://github.com/systemd/systemd/issues/40262
https://redd.it/1vpg1q2
@r_linux
https://github.com/systemd/systemd/issues/40262
https://redd.it/1vpg1q2
@r_linux
GitHub
Excessive IO caused by systemd-journald · Issue #40262 · systemd/systemd
systemd version the issue has been seen with 257.9 Used distribution Debian 13 Linux kernel version used 6.12.57+deb13-amd64 Component systemd-journald Expected behaviour you didn't see Log wri...