Sound Open Firmware 2.4.1 Continues The Transition To Zephyr RTOS

[phoronix]

Phoronix: Sound Open Firmware 2.4.1 Continues The Transition To Zephyr RTOS

Sound Open Firmware 2.4.1 is out today as the first stable v2.4 release for this open-source audio / DSP firmware stack for not only modern Intel platforms but AMD, Mediatek, and other increasing industry use as well. With Sound Open Firmware 2.4 they have continued the transition in making use of Zephyr RTOS...

https://www.phoronix.com/news/Sound-Open-Firmware-2.4.1

[ehansin]

If anyone can verify (or correct me where I am wrong!), is this the gist of things (I am not an expert here)? I assume this is about creating a firmware that runs on top of Zyphyr OS (RTOS) on embedded audio chips (or on an audio card with said chips), maybe no different in concept than various micro-controllers that might exist in a larger X86-64 ecosystem, that also may have their own embedded/lightweight OS. This then has some sort of way to communicate with the main OS/CPU architecture this is tied to. Does this sound good enough, for government work at least, as they say? If not, let me know what I am missing, just trying to learn. Thanks!

[uid313]

SOF seems great, but why is there no Network Open Firmware, Graphics Open Firmware, and Storage Open Firmware, etc?

[mangeek]

Just last week I manually updated SOF 2.2.x into my Ubuntu 22.04 laptop hoping to get the speakers working. Hopefully 2.4.1 does the trick. Like a bozo, I bought a premium laptop without fully checking if fwupd BIOS updates or audio would work on Linux.

Still better than my last laptop, which was bought, used for years, and then retired all without being able to fully utilize the NVIDIA GPU (Pascal-based, no reclocking without NVIDIA drivers and forcing X11).

[ayumu]

I am not sure why they are selecting a RTOS that can't guarantee meeting timing deadlines, when seL4 exists, has formal proofs and is free and open source.

It is almost as if they didn't look at the state of the art, but instead went with what some developer involved in the project was already familiar with.

So irresponsible.

[ll1025]

but instead went with what some developer involved in the project was already familiar with.

You just described why most things in FOSS are what they are. You're welcome to contribute better solutions, but if you won't / don't then you need to make do with the choices made by those who will contribute. And as a rule, they're going to contribute solutions they are familiar with.

[mangeek]

I am not sure why they are selecting a RTOS that can't guarantee meeting timing deadlines, when seL4 exists, has formal proofs and is free and open source.

The short answer is that seL4 is bigger than some of the targets (audio DSPs with as little as 64KB available), and that seL4 hasn't been ported to the architectures of the DSPs (mostly Xtensa).

https://thesofproject.github.io/latest/platforms/index.html

Zephyr is open source, administered by the Linux Foundation, is an order of magnitude lower footprint than seL4, has uses in other places besides SOF, has the backing of a bunch of commercial vendors, and has some similarities to the Linux build system that can make onboarding developers easier.

As far as timing and security, this is running on audio DSPs, so the timing issues should be part of the 'KPI budget' of the hardware/software for each implementation, and the security stakes seem pretty low (getting to the audio DSP means you're in my kernel, I somehow doubt my sound chip is your next destination, it offers nearly nothing of value).

https://thesofproject.github.io/late..._overview.html