5 ms·

Author here, feel free to ask me things.

Sir_Substance 9y ago
This is super-basic, but given pretty much the only words I recognize on that page are "android" and "mesa", what does this /mean/?
- robert_foss 9y ago
  It means that the iMX6 platform now can run Android using an entirely open source software stack. It also paves the way for other platforms, and in general is another win for open source.
- zengid 9y ago
  The original article is better at explaining things: https://www.collabora.com/news-and-blog/blog/2017/06/05/android-nxp-imx6-buffer-modifier-support/ https://www.collabora.com/news-and-blog/blog/2017/06/05/andr...
  - robert_foss 9y ago
    Thanks ;)
endgame 9y ago
Do you believe in nominative determinism?
- robert_foss 9y ago
  No. Good question though.
  - pdog 9y ago
    To paraphrase Trotsky, you may not believe in nominative determinism, but nominative determinism believes in you.
  - deleted 9y ago
    [deleted]
  - jeroen94704 9y ago
    There is a fairly well known Dutch pilot whose last name literally translates to "brick". I'll leave it as an exercise to the reader to decide whether that is an example of nominative determinism or not.
wolfgke 9y ago
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).
- robert_foss 9y ago
  Overall the etnaviv driver is young, both in mesa and in the linux kernel, so there are lots of nice-to-have features missing and fine-tuning. Christian Gmeiner, Lucas Stach and Wladimir Van Der Laan would all be able to provide you with a more detailed answer.
leggomylibro 9y ago
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?
- planteen 9y ago
  You can get a i.MX6 SoM (system-on-module) to take care of nasty things like external memory. https://www.solid-run.com/freescale-imx6-family/imx6-som/ https://www.solid-run.com/freescale-imx6-family/imx6-som/
  - psykotic 9y ago
    I was about to suggest SoMs as well. 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.
    - leggomylibro 9y ago
      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.
fmntf 9y ago
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?
- robert_foss 9y ago
  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.
gcb0 9y ago
Do you think google failing to provide a single nexus phone that doesn't require binary blobs is Incompetence or Malice?
- chx 9y ago
  What about indifference?
gcb0 9y ago
care to point to the moneyshot diff? i trusted commit message and got here https://customer-git.collabora.com/cgit/android-etnaviv/gbm_gralloc.git/commit/?h=android-etnaviv https://customer-git.collabora.com/cgit/android-etnaviv/gbm_...
mrlambchop 9y ago
Hey Robert - this is awesome! 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.
jeroen94704 9y ago
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.
pawadu 9y ago
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?
wolfgke 9y ago
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?

This is super-basic, but given pretty much the only words I recognize on that page are "android" and "mesa", what does this /mean/?

robert_foss 9y ago
It means that the iMX6 platform now can run Android using an entirely open source software stack. It also paves the way for other platforms, and in general is another win for open source.
zengid 9y ago
The original article is better at explaining things: https://www.collabora.com/news-and-blog/blog/2017/06/05/android-nxp-imx6-buffer-modifier-support/ https://www.collabora.com/news-and-blog/blog/2017/06/05/andr...
- robert_foss 9y ago
  Thanks ;)

endgame 9y ago

Do you believe in nominative determinism?

robert_foss 9y ago
No. Good question though.
- pdog 9y ago
  To paraphrase Trotsky, you may not believe in nominative determinism, but nominative determinism believes in you.
- deleted 9y ago
  [deleted]
- jeroen94704 9y ago
  There is a fairly well known Dutch pilot whose last name literally translates to "brick". I'll leave it as an exercise to the reader to decide whether that is an example of nominative determinism or not.

wolfgke 9y ago

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).

robert_foss 9y ago
Overall the etnaviv driver is young, both in mesa and in the linux kernel, so there are lots of nice-to-have features missing and fine-tuning. Christian Gmeiner, Lucas Stach and Wladimir Van Der Laan would all be able to provide you with a more detailed answer.

leggomylibro 9y ago

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?

planteen 9y ago
You can get a i.MX6 SoM (system-on-module) to take care of nasty things like external memory. https://www.solid-run.com/freescale-imx6-family/imx6-som/ https://www.solid-run.com/freescale-imx6-family/imx6-som/
- psykotic 9y ago
  I was about to suggest SoMs as well. 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.
  - leggomylibro 9y ago
    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.

fmntf 9y ago

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?

robert_foss 9y ago
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.

gcb0 9y ago

Do you think google failing to provide a single nexus phone that doesn't require binary blobs is Incompetence or Malice?

chx 9y ago
What about indifference?

gcb0 9y ago

care to point to the moneyshot diff? i trusted commit message and got here https://customer-git.collabora.com/cgit/android-etnaviv/gbm_gralloc.git/commit/?h=android-etnaviv https://customer-git.collabora.com/cgit/android-etnaviv/gbm_...

mrlambchop 9y ago

Hey Robert - this is awesome! 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.

jeroen94704 9y ago

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.

pawadu 9y ago

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?

wolfgke 9y ago

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?