Are SoCs implemented in source-available manner in downstream kernels? Or is there a potential for closed-source parts (binary blobs)? I’m not talking about the devices that SoC talks to (if that makes sense), such as Wi-Fi, BT, Camera, etc., the question relates only to SoC itself.
SOC == System On Chip. There are lot of subsystems (Modem, WFi, Bluetooth, slpi, adsp, cdsp, gpu, etc…) that require userspace daemons/firmware blobs. If under SOC you mean CPU cores, than yes. Downstream have all initialisation stuff
I’m not talking about the devices that SoC talks to (if that makes sense), such as Wi-Fi, BT, Camera, etc.
Just want to re-state what @NekoCWD said and emphasize the fact that the SoC often isn’t really “talking” to WiFi/BT/GPU/etc, because those things physically reside inside the SoC itself.
These peripherals are often referred to as “IP” because of the fact that it’s a whole silicon design that may have been licensed from another firm. Think of it like including a library into your software project. Except in this case you’re “compiling” it into actual transistors etched into some silicon.
Beyond just the obvious peripherals though, it’s worth noting that many parts of modern SoCs aren’t under the control of the kernel at all. For example the Venus (VENCDEC) video encoder/decoder block has its own ARM7 CPU, which is running proprietary and signed code that the kernel uploads. The kernel is merely communicating with this IP over a channel of some sort (it’s telling VENCDEC what to do, not how to do it).
If under SOC you mean CPU cores, than yes. Downstream have all initialisation stuff
Typically arm64 CPU cores are booted using PSCI. So the kernel is saying “please boot CPU3 and start executing code at this address”, but that request is being dispatched into a secure mode call up to the trusted firmware which is performing the actual operation.
Even on older SoCs like MSM8916 where there’s no PSCI implementation, more of the CPU core booting process is being done directly (i.e writing into specific registers to modify the core’s power state), but the act of jumping the core into a specific address to begin executing code is happens via direct SMC calls to TZ.
So like the NVENCDEC example from earlier, the kernel is communicating with a (proprietary, closed source) system and telling it what to do, not how to do it.
So, to address the original question as posed in the title:
Do downstream kernels have full SoC implementation?
I would conclude that no, most SoCs do not provide a “full” SoC implementation. With each new generation of SoCs, it seems to me that the kernel is being treated like a slightly-more-privileged userland, with an increasing amount of the h/w control being pulled up into the EL2 firmware which is almost always proprietary and closed-source.
1 Like