In a previous life, I spent a bunch of time within a large semiconductor company pushing for full source releases in the same spirit - it was successful in a single instance, but an uphill battle in most. Cyanogen was an original inspiration.
During the time I looked after Android porting (started in 2008!) one huge issue purveyed - stability of an Android port was incredibly hard to achieve and was hyper focused around a specific release. It wasn't anything in particular - its just that Android was developed by a incredible team of people on one device and that porting to other platforms tended not to behave like the original.
A few colleagues are now working on the VTS at Android as an effort to solve this exact problem. I'm looking forward to seeing big steps to improve this with all the larger vendors very soon.
The fallout from all this however is that a ported platform will still have a ton of bugs and a long tail of issues that impact app behaviour. Sure - Angry Birds will work (I know... flash back to 2013) but the latest VR app that happens to use an obscure EGL extension to get camera data into the GL context might be either super slow or worse, not working.
Its the development of these new APIs in new Android versions that really causes long term issues, as well as ensuring all APIs work correctly over all versions of Android (and Linux kernels). Many to Many is a tough test case when the majority of the testing is manual.
I do some OSS development for UDOO, which sells iMX6 SBC (6Q, 6D, 6SX). We currently offer Android 6, I started to build 7.1 a few days ago.
Intro end, question is, did you compare the performance between Vivante and OSS stuff?
I haven't done any comparisons, but the performance of the OSS graphics stack is currently an area of focus.
Work remains to be done with respect to Android.
For other applications the OSS driver has been found competitive and even faster for some applications.
Unfortunately I have no numbers to back any of the above statements up.
What things remain to be done for an OSS driver of Vivante GPUs (the fact that the support suffices to run Android proably does not mean that it is feature-complete).
What do you think is the best hand-solderable application processor these days? I don't see any non-BGA I.MX6 chips, but I didn't look very hard. Is the hobbyist stuck with an ARM926?
Also, in that vein, is there a similar solution for I.MX23's?
The biggest challenge with BGAs from a hobbyist perspective isn't the soldering. There are lots of hobbyists successfully reflowing BGAs with toaster ovens. The bigger problem is manufacturing the PCBs to break out the BGA balls. TI has some BGAs with a proprietary ball pattern that are designed to be broken out with just 4 layers, but that's the exception, and you generally need very narrow traces and trace clearance to route between balls and vias. I just looked at OSH Park's current capabilities and they only do up to 4 layers and their DRC specifies 6 mm minimum trace width and 6 mm minimum spacing. I've heard of people using OSH Park and similar lower-end prototyping services to manufacture one-off PCBs for fine-pitch BGAs, but you'll be failing DRC by a massive margin, so expect terrible yield on the PCBs, assuming any of them work at all.
Unfortunately I think DRC will be similarly challenging for most SoM connectors since their pin spacing has a similar pitch to BGAs, so you'll probably need an off-the-shelf break-out board to work around that. Honestly, at some point you should consider whether a vanilla dev board with low-speed GPIO headers could meet your requirements.
Those OSHPark rules are 6mil, not mm - that's a little over 0.15mm. But it's still not really suitable for BGP modules. You can probably do 60-ball RAM modules, but a medium-sized processor seems like it would be off the table.
I think that dirtyPCBs does 6-layer boards, but they're comparatively pricey for small runs or prototypes.
Thanks for the correction; I thought 6 mm sounded way too high. Gotta love American measurement units!
There are Internet accessible Chinese PCB manufacturers that will do short runs for designs of almost any complexity, but they aren't really targeting hobbyists, though that seems to be changing.
I think it harks back to older manufacturing processes, via plastics (where mils are used) back to metalworking. Machinists will usually talk about small distances in "thou", as in thousandths of an inch.
Always cracks me up when AvE mentally converts 2.5/64" or some crazy shit into thou while thinking out loud, and then goes "metric fanboys be like whaaat?"
The AllWinner A13 (Cortex A8) is available in a LQFP176 package. That includes a MALI400 GPU. That is still fairly old, but more up to date than ARM926.
I'm hardly an electronics designer (although I do it for fun), so I don't have much of an opinion.
However, I don't think there are any SOCs with Adreno or Vivante GPUs that are also hand solderable.
A quick Octopart search[1] turned up nothing.
About iMX23, a quick look seems to suggest that it has no 2D/3D capable IP on the SOC. So it likely just has a display controller of some sort. Unfortunately I don't know what that display controller is. It may be encompassed by the imx driver depending on that the hardware actually is.
In Android O Google plans to separate HAL, OS and customizations.
This is a move from the "move fast and break things", which has allowed Google to make huge changes to Android but at the same time caused all kinds of problems for vendors, to a more "have a stable base" mentality.
Do you think we will see more fully open platforms due to this change?
How big a job is customizing all this to work on a different board? At work we use iMX6-based SoM's on custom baseboards, and so far have stuck to Linux. But we'd like to experiment with Android, just to see if that is a viable/interesting option for embedded systems.
Is there official documentation available that you used for writing the Vivante driver or did you do it by reverse engineering? Or was it some of both?
