I’ve worked with Qualcomm SoCs a long time ago and, from my experience, the binary blobs ARE the biggest hurdle to the true Foss phone. Google is the most to blame, IMO, but also the rest of traditional OEMS of SoCs. They basically found the way to circumvent the OSS nature of Linux, which is why even though android is based on linux, the actual product and ecosystem looks nothing like regular Linux. What Google allowed with Android architecture, particularly with their HAL subsystem is force a layer in between native Linux device interface and Android system, so OEMs use that to implement whatever proprietary peripheral (device, sensor, etc) purely in userspace, rather that just as a kernel module. The kernel module is then just a userspace/kernelspace adapter, and everything is handled in the user space. This then means you dont have to have an open source driver, as it is not a part of kernel, and you just lock your driver into a binary blob. And in case of Qualcomm and I assume other oems, everything is just a binary blob. All sensors, microphone, GPS, modem, EVERYTHING. Yes, you can boot a basic Linux kernel, but no other functionality will work. If you had access to the blob source, you’d be able to fix, update and use a newer kernel versions eventually. HAL is technically not the cause of the problem, but it’s certainly an inspiration and almost a blueprint for how to lock down your hardware.
I’ve worked with Qualcomm SoCs a long time ago and, from my experience, the binary blobs ARE the biggest hurdle to the true Foss phone. Google is the most to blame, IMO, but also the rest of traditional OEMS of SoCs. They basically found the way to circumvent the OSS nature of Linux, which is why even though android is based on linux, the actual product and ecosystem looks nothing like regular Linux. What Google allowed with Android architecture, particularly with their HAL subsystem is force a layer in between native Linux device interface and Android system, so OEMs use that to implement whatever proprietary peripheral (device, sensor, etc) purely in userspace, rather that just as a kernel module. The kernel module is then just a userspace/kernelspace adapter, and everything is handled in the user space. This then means you dont have to have an open source driver, as it is not a part of kernel, and you just lock your driver into a binary blob. And in case of Qualcomm and I assume other oems, everything is just a binary blob. All sensors, microphone, GPS, modem, EVERYTHING. Yes, you can boot a basic Linux kernel, but no other functionality will work. If you had access to the blob source, you’d be able to fix, update and use a newer kernel versions eventually. HAL is technically not the cause of the problem, but it’s certainly an inspiration and almost a blueprint for how to lock down your hardware.
Interesting, I think I follow all of that. Thank you very much for explaining