Android 4.4/5.0 OOB?

[Asaggynoodle]

Hey all, been a while.

With the Release of the Pyra just around the corner, I want to ask a simple question I have yet to be exactly asked.

Since the Pyra uses the OMAP5 (Basically a Dual core 1.7Ghz A15), would I be able to Run an Android OS right out of the box?

I mean I've got pretty extensive experience with Android, So i'd be curious as to how I would go about actually installing it.

Would the Pyra use its own Compiled Kernel? Or try to hijack another OMAP5 based kernel? You see what I mean?

I think Android Lollipop would be simply amazing on something with a keyboard like this.

Please let me know your thoughts. Thanks.

 

[TrashyMG]

Well I doubt it will be available out of the box, but I'm sure someone skilled enough could get something working if they invest time into it.

Ti does offer a package of Android for use with the OMAP5 development board, not entirely sure of which version.. From what I hear from aTc it's quite unpolished..
 

Would the Pyra use its own Compiled Kernel? Or try to hijack another OMAP5 based kernel? You see what I mean?

There isn't really another OMAP5 based kernel out there that works well to hijack from.. Not much uses that SoC.

 
 

 

[Asaggynoodle]

Well I doubt it will be available out of the box, but I'm sure someone skilled enough could get something working if they invest time into it.

Ti does offer a package of Android for use with the OMAP5 development board, not entirely sure of which version.. From what I hear from aTc it's quite unpolished..

Would the Pyra use its own Compiled Kernel? Or try to hijack another OMAP5 based kernel? You see what I mean?

There isn't really another OMAP5 based kernel out there that works well to hijack from.. Not much uses that SoC.

I found this:

https://android.googlesource.com/kernel/omap/

But i'm not sure which of the code names (Tuna, Minnow, Hammerhead etc.) correlate to teh different SoC's.

TI offers a evaluation build of Android for this very SoC, probably serverely outdated, but if we could update it, we could be in buisness. (Turns out it's 4.2.2 JB)

http://software-dl.ti.com/omap/omap5/omap5_public_sw/OMAP5432-EVM/5AJ_1_5_Release/index_FDS.html

 

[TrashyMG]

A custom kernel would still be needed.. There will be specific kernel modules for handling things such as the LCD display and other hardware.. I also doubt any of those listed on that page have omap5 support as the only thing that uses the omap5 currently are devboards. In the case of the Pandora we're able to run Android on top of our existing kernel, my guess the same thing could be done in theory.

 

[WizardStan]

TI has an official Jellybean release for the EVM which should mostly work provided the kernel can be recompiled with the new display, keyboard, and wifi drivers. "Out of the box" is probably overly simplistic, but with a little bit of work, probably. It's in a much better position than the Pandora, at least.

 

[ekianjo]

A custom kernel would still be needed.. There will be specific kernel modules for handling things such as the LCD display and other hardware.. I also doubt any of those listed on that page have omap5 support as the only thing that uses the omap5 currently are devboards. In the case of the Pandora we're able to run Android on top of our existing kernel, my guess the same thing could be done in theory.

And the rotation chip as well.

 

[EvilDragon]

Using the rotation chip in Android doesn't make any sense since it uses OpenGL all the time which handles the rotation without issues.

 

[notaz]

It's in a much better position than the Pandora, at least.

What makes you think so? TI has official Android for OMAP3 too you know..

 

[fusion_power]

Using the rotation chip in Android doesn't make any sense since it uses OpenGL all the time which handles the rotation without issues.

So we would not need the rotation chip at all if every Pyra-App and every Pyra OS would use OpenGL? ^^

 

[WizardStan]

TI has official Android for OMAP3 too you know

Actually I didn't know that. Interesting. Did it help at all when you did your Android release?

 

[EvilDragon]

Using the rotation chip in Android doesn't make any sense since it uses OpenGL all the time which handles the rotation without issues.

So we would not need the rotation chip at all if every Pyra-App and every Pyra OS would use OpenGL? ^^

Correct. When Wayland is ready, for example, that wouldn't be needed anymore.


However, XOrg and all apps using the framebuffer can't use OpenGLES for that, therefore, we need the rotation chip for maximum performance.

It's in a much better position than the Pandora, at least.

What makes you think so? TI has official Android for OMAP3 too you know..

Well, it should be a BIT better, since Nikolaus keeps the Pyra PCB compatible with the EVM, so any EVM testing image should boot out of the box on the Pyra as well.


That wasn't the case with the BeagleBoard / Pandora, AFAIR (as they were developped at the same time).

 

[Glyph Reader]

Correct. When Wayland is ready, for example, that wouldn't be needed anymore. However, XOrg and all apps using the framebuffer can't use OpenGLES for that, therefore, we need the rotation chip for maximum performance.

 

Does this mean you plan to switch to Wayland once it has become more stable? 

-Glyph Reader

 

[levi]

Everyone plans to switch to Wayland when it's subjectively better than X, except for some weird tech stick-in-the-muds but whether that will happen within the Pyra's lifespan or not is still anybody's guess at present.

 

[rohezal]

Rotation via OpenGL would use the GPU all the time. This could use more power then just rotate it in hardware.

 

[Silent-Hunter]

I think Wayland is a bad idea, using the GPU for everything will drain the batter faster.

 

[WizardStan]

Depends on how much drain it actually is. Remember, Wayland brings a lot of new features that are worth considering.

If it increases the drain by 5% against an idle system that seems like a very fair tradeoff to me, but we can take votes when (or *if*) it becomes an issue.

Note also that Wayland doesn't have to use OpenGL(ES), from what I understand the protocol does support traditional drawing as well. If the power usage is a concern just turn off the OpenGLES path and keep using the rotation chip.

edit:

For rendering, Weston can use OpenGL ES or software (pixman[47])

http://mirror.linux.org.au/linux.conf.au/2013/mp4/The_real_story_behind_Wayland_and_X.mp4

 

[Galaxis]

Note also that Wayland doesn't have to use OpenGL(ES), from what I understand the protocol does support traditional drawing as well. If the power usage is a concern just turn off the OpenGLES path and keep using the rotation chip.

The rotation chip doesn't come for free, either.

 

[ekianjo]

Correct. When Wayland is ready, for example, that wouldn't be needed anymore.

Wouldn't Wayland consume more battery though ? Running on OpenGL hardware constantly is bound to consumer more power, right ?  

 

[txus]

Q:

Wouldn't Wayland consume more battery though ? Running on OpenGL hardware constantly is bound to consumer more power, right ?  

A:

[...]
Note also that Wayland doesn't have to use OpenGL(ES), from what I understand the protocol does support traditional drawing as well.

[...]

And http://www.vivantecorp.com/en/technology/composition.html (the Pyra's is the GC320, as seen in the specs).

 

[Cloudef]

Wayland is just a protocol, however if you don't use OpenGL in the compositor, you have to use the rotation chip again. The compositor can use any technology it wants to draw on the screen, wayland itself is just a abstraction over programs communicating and sharing their buffer (what user should see).

As for power usage, mobile GPUs are designed to use low power, which is also why it is sometimes PITA to program for them. I don't see that as much problem, especially when for example wayland compositor I'm developing has less wakeups than certain X11 terminal (or X11 itself). (most likely because X11 is very roundtrippy)

Not using OpenGL when doing compositor also makes things much more diffcult, especially if you want to support EGL programs.

However that said. The GPU again on pyra will probably have weird issues and DRM probably will be even more pain than it is normally and things don't actually work so well as just with good old framebuffer. Who knows.