SoC: Back and forth!

[fusion_power]

As far as I know, libhybris depends on the correct kernel / driver versions. It could mean we'd be stuck with an old kernel in the future.

 Please not again, Pandora still suffers from the "old OS" problems, even with new kernels and stuff. For the Pyra I wish we get a system that can be easily updated regulary without taking years and years to develop new Firmware (unlike ".next")

 

[Askarus]

As far as I know, libhybris depends on the correct kernel / driver versions. It could mean we'd be stuck with an old kernel in the future.

 
Please not again, Pandora still suffers from the "old OS" problems, even with new kernels and stuff. For the Pyra I wish we get a system that can be easily updated regulary without taking years and years to develop new Firmware (unlike ".next")

For m that isn't a big problem if the SoC we get is better.

 

[Natsu]

For m that isn't a big problem if the SoC we get is better.

I feel the same way.

 

[Askarus]

libHybris doesn't sound that bad for me.

As it's a layer that translates calls I don't see why we will be stuck to an older kernel at some point.

libHybris is open source and the Kernel is.

Isn't that enough to make a recent Kernel usable with an outdated Android Driver.

And as long as developers can use native calls and the libHybris does translate them for the system I don't see a big downside here as well.

For me it seems to work like Pandora's libGL.

Am I wrong with that?

 

[Exophase]

Also I think power consumption and heat are very important. We are not making a 10" tablet or a smart-TV here, we don't have room for a large heatsink and battery. It would be silly to get the A80 and then have to switch off some of those cores, or downclock that GPU, just to keep battery life and heat acceptable. I don't know if that would be the case, maybe the A80 is cheaper and more efficient in terms of perf/W than OMAP5 so it still makes sense to do that. It would be nice to see some decent benchmarks about that.

Lots of phones have quad cores and some even have the same 4+4 arrangement as A80. There are phones with faster GPUs too. If you had the option to use a GPU that was twice as big/fast per clock but ran at half the clock that's what you'd want because it'd be more efficient.

It's very likely A80 will be more efficient at higher power levels, because it's using TSMC's 28HPM process while TI is almost surely using 28LP. Qualcomm improved power efficiency a lot going from S600 to S800 for this reason (this improvement is reflected in the voltage tables in the kernel). They also may be using a newer revision of the Cortex-A15s which has power optimizations. And it has the Cortex-A7 cores.

In any case, I think the wisest thing for ED to do is to stick to OMAP5 for now, without making too many hard commitments -- don't let things depend crucially on OMAP5-only features, don't sign deals that require you to buy 50K OMAP5 SoCs, etc. If at some point the A80 has proved itself (in other products like that Cubieboard) and if it still looks good, you can still switch to it then. No need to take risks now.

That seems like the best approach. Replacing the OMAP5 SoC with something else some months after release is still going to be kind of weird though. It'd be crucial that old buyers could upgrade for a cheap price, the SoC board by itself could perhaps be sold for ~$100 or something like that.

 

[God Ginrai]

As far as I know, libhybris depends on the correct kernel / driver versions. It could mean we'd be stuck with an old kernel in the future.

I haven't heard of that. As far as I know, Hybris works kind of like WINE or GINGE, translating Bionic calls into glibc calls. Also, due to Canonical supporting it for Ubuntu Touch, I doubt that it would ever get us stuck with an old kernel.

-God Ginrai

 

[Askarus]

As far as I know, libhybris depends on the correct kernel / driver versions. It could mean we'd be stuck with an old kernel in the future.

I haven't heard of that. As far as I know, Hybris works kind of like WINE or GINGE, translating Bionic calls into glibc calls. Also, due to Canonical supporting it for Ubuntu Touch, I doubt that it would ever get us stuck with an old kernel.

-God Ginrai

Also if this is the case we won't be stuck with an old Kernel NOW.

Maybe in some years but as we have the daughter board solution we might not use the same processor for 5-6 years as we did now.

 

[EvilDragon]

The Cubieboard is still at 3.4 afaik, but I don't remember the reason.

Remember: There are two parts of the SGX driver: One that needs to be compiled with the kernel and one that works with any kernel.

At least, that's the case in the TI environment.

Do we know that it's the same with AllWinnertech?

It could also be that there's no free part and we need to use the kernel that is bound to the driver version.

What I also don't know: Does powersaving in Android work in the sme way than Linux powersaving? Because if it doesn't, we would have a battery sucker.

I'll contact the Cubieboard team how they plan to solve all this, but a board connected to an AC adaptor is not focussed on powersaving...

 

[Askarus]

Remember: There are two parts of the SGX driver: One that needs to be compiled with the kernel and one that works with any kernel. At least, that's the case in the TI environment. Do we know that it's the same with AllWinnertech? It could also be that there's no free part and we need to use the kernel that is bound to the driver version.

I did suppose it's the same.

If not -> OMAP5.

What I also don't know: Does powersaving in Android work in the sme way than Linux powersaving? Because if it doesn't, we would have a battery sucker.

Most important.

Same as above.

I'll contact the Cubieboard team how they plan to solve all this, but a board connected to an AC adaptor is not focussed on powersaving...

Doesn't the Jolla Phone use Android drivers as well with libhybris?

They need to save power.

Maybe they would have some advice as well.

 

[EvilDragon]

You don't know what parts of the Jolla Phone use libhybris.. If it's only the 3D driver and the powersaving stuff is included in the standard kernel, they're fine.

I also don't know all this, but it needs to be found out before we can make a hardware decision.

(and btw: as far as I heard, the driver system of the Jolla phone is a total mess...)

 

[Askarus]

Ah ok.

Maybe it's worth an E-Mail, maybe not.

Making a Linux Handheld would be so nice if those companies would support what they advertise.

 

[CrazyIvan]

What I also don't know: Does powersaving in Android work in the sme way than Linux powersaving? Because if it doesn't, we would have a battery sucker.

 
Basically yes but android provides additional measures known as 'wake locks'. It was a primary powersaving method in old androids but nowadays traditional linux methods (governors) are used heavily.

The problem is do we have an open-source governor suited for a80? Even on modern desktops powersaving is not about frequency anymore and works better with a chip-specific governor

 

[God Ginrai]

The Cubieboard is still at 3.4 afaik, but I don't remember the reason.

Remember: There are two parts of the SGX driver: One that needs to be compiled with the kernel and one that works with any kernel.

At least, that's the case in the TI environment.

Do we know that it's the same with AllWinnertech?

It could also be that there's no free part and we need to use the kernel that is bound to the driver version.

 That's why I pointed out that Canonical was supporting libhybris. I don't think they would let ubuntu fall far behind in kernel versions, so they would make sure that (assuming this kernel dependency even exists for libhybris) that libhybris works with a recent kernel.

You don't know what parts of the Jolla Phone use libhybris.. If it's only the 3D driver and the powersaving stuff is included in the standard kernel, they're fine.

OpenWebOS uses libhybris, too. You can chat with the team members over in #webos-ports on freenode to see what their solution for the powersaving stuff is.

-God Ginrai

 

[EvilDragon]

It's not libhybris that is a problem. The problem is the Android driver. If an Android driver is fixed on kernel 3.4, for example, you can't use kernel 3.6, even with libhybris.

Libhybris is just a bridge, the kernel and driver versions still need to fit.

 

[God Ginrai]

It's not libhybris that is a problem. The problem is the Android driver. If an Android driver is fixed on kernel 3.4, for example, you can't use kernel 3.6, even with libhybris.

Libhybris is just a bridge, the kernel and driver versions still need to fit.

Yea, but I'm pretty sure that libhybris is a bridge between the kernel and the driver as well.

-God Ginrai

 

[Exophase]

I think most if not all GPU vendors have open sourced the kernel side of their driver (which does little more than providing hardware access for the user space binary), to prevent people from being locked into kernel versions. Even if Allwinner does nothing to facilitate this the source should be up somewhere, and if they're not loading kernel modules in Android it should be required.

 

[WizardStan]

I'm pretty sure libhybris is just a 1:1 mapping, if the kernel changes but the driver doesn't then it is no longer a direct mapping. It might still be possible to implement whatever changes but it's no longer just a bridge, you're now adding device specific implementations that need to be maintained. It doesn't matter whether Canonical is keeping libhybris up to date if certain features have changed and are no longer compatible with the new kernel.

This is slightly different from the PowerVR situation which doesn't pretend to be a 1:1 mapping, the open source kernel driver is already doing device specific things and just makes binary calls for the end hardware features; it's more likely to get support for that than a device specific branch of libhybris.

 

[God Ginrai]

As I mentioned before, Hybris just converts Bionic calls into glibc calls. That's not device-specific.

-God Ginrai

 

[WizardStan]

As I mentioned before, Hybris just converts Bionic calls into glibc calls. That's not device-specific.

Exactly my point.

 

[DeeGee]

I guess best would be to ask straight from Carsten Munk (Stskeeps @ freenode), the original developer of hybris. Or I might aswell ask myself:

22:36 < DeeGee> So how locked in is device using libhybris to certain driver/kernel version combination? Pandora's sucessor is probably going to be OMAP5 based, because all other chipset would require
                libhybris + android drivers.
22:36 < DeeGee> http://boards.openpandora.org/topic/15560-soc-back-and-forth/page-45
22:37 < Stskeeps> basically: if you have a working android hw adaptation for it, which is typically a driver+kernel combo, then libhybris practically just uses hwcomposer and EGL/GLESv2
22:38 < Stskeeps> because that's what a given ODM delivers with it and is stable
22:38 < Stskeeps> this may not necessarily apply to custom hw, though
22:39 < Stskeeps> remember that libhybris just is a way to leverage an android hardware adaptation
22:40 < Stskeeps> libhybris doesn't particularly care about kernel version
22:41 < Stskeeps> and X11 based BSPs with working GLESv2 is getting more and more rare

22:42 < Stskeeps> if i was to make a pandora device; i'd simply make a device that focuses on the good gaming experience, forget about the kernel version..
22:43 < Stskeeps> because with sufficiently mobile like devices, you're simply stuck with a certain kernel and the manpower needed to really upgrade is obscene
22:43 < Stskeeps> which you could better use to make new product; or better experience on what you hav
22:43 < Stskeeps> e