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...
Conversation
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.
2
1
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
If you want to get rid of blobs you don't want any of the unnecessary non-vendor-image components anyway. AOSP passes CTS with AOSP system image and stock boot/vendor. It's wanting to modify vendor that makes this more complicated than their officially supported approach.
2
I did get a boot using their stock vendor.img.
Sadly takes signing off the table, and it ships with a lot of stuff like OMA-DM toolkits that have crazy privileges that are a non starter for my threat profile.
No luck booting w/ APV yet :/
github.com/hashbang/andro
1
Start by trying to reproduce vendor.img exactly and don't include anything else. Can get rid of all the system and product portions since none of that is required. Build the vendor image, compare to the stock one and keep going until it's identical and it should boot up fine.
Then worry about removing portions of the vendor image afterwards.
1
The way that things work now, using the stock vendor image doesn't matter to verified boot since it just gets the dm-verity tree included via hash in vbmeta anyway. It just has a dm-verity tree, not a signature anymore, since the move to AVB.
2
1
Show replies
If you look in the history, I started very minimal.
At this commit I have added back in the whole overkill kitchen sink just to try to recreate vendor.img to get a boot. Still no love.
Feel free to document your general approach here if time permits. I would love to learn.