It doesn't particularly matter whether this code is open or closed source. Either way, people are not working on it much. Most effort goes into the device independent code. AOSP doesn't have blobs. Devices have blobs, whether or not you run AOSP using those or something else.
Conversation
Qualcomm has invested effort into the open source driver stack but it's never ready in time for it to be what vendors choose to ship. Look at linaro.org/blog/dragonboa as an example. This is the same SoC as the Pixel 3. It has open drivers for mainline kernels. It comes too late.
1
That is the first credible evidence I have seen that there are people at Qualcomm that care about these classes of problems.
This is going to end with someone trying to get VC funding to pay for an actually open driver hardware target isn't it...
1
Qualcomm cares about selling hardware. They've been trying to get a mainline kernel driver stack up and going for years. It's incredibly difficult to land everything upstream. The upstream kernel doesn't accept kernel drivers only used with closed source userspace libs, etc.
1
1
There aren't kernel drivers to build userspace support because the userspace support hasn't been written for non-existent kernel drivers. It all has to be cleaned up, overhauled, ported over to upstream frameworks which are often totally inadequate and have to be improved, etc.
1
1
The open source driver stack for Snapdragon exists and is usable. However, it doesn't match the performance/functionality for devices it supports and it's ready a year or two after the hardware is launched rather than way before that which is what would have to happen...
1
1
So, since it's not what gets shipped, it obviously doesn't get the same resources applied to it. Over time, it's getting better and getting more resources applied but it's unclear if there will EVER be a point that devices can ship with upstream kernel unless they use an old SoC.
2
I would happily use a crippled 5 year old SoC if it was going to continue to be sustainably manufactured.
I would even settle for wifi-only if I could have my 4 apps, open drivers, and decent secure boot.
2
That's essentially what you're able to get with a development board like 96boards.org/product/rb3-pl with AOSP support. Same SoC as the Pixel 3, but in the smartphone world this is already a past generation SoC and it'll be at Pixel 5 / 6 before the open driver stack could be ready.
2
If all the past efforts / partnerships hadn't been blown up by greed, GrapheneOS would likely already be using custom hardware based on a Qualcomm reference design. Could build with the actual vendor SDK / sources in our official builds and publish output in a usable format.
1
1
It was all massively set back. Still dealing with all of that stuff far more than focusing on the actual project. Pixels are the best currently available option and will probably remain as such, until we can get reference hardware produced for us and start customizing that.
Thanks for the insight as always. Lot to mull over but overall your arguments are sound.
I think I'll bang my head at coral/flame support in APV again in a couple months if no one beats me to it.
1
Everything that matters should work simply using the stock vendor image. Unpacking it and reassembling it is needed to start replacing the components with our own builds including our own SELinux policy, building as much as possible from source and omitting what isn't required.
1
Show replies
Google has chosen not to invest resources in having proper Pixel support available. I think they could be convinced to do it. In the long term, we don't want to be using Pixels though. We just want to start from an SoC reference design and make that more privacy/security focused.
1