Or Continue to Thread: [WIP/DEV] I've got a "boo…
Find Your Device:
5th November 2013, 10:50 PM   |  #309  
Hashcode's Avatar
Recognized Developer
Thanks Meter: 22,688
 
3,243 posts
Join Date:Joined: Sep 2011
Donate to Me
More
Hi Guys,

Someone asked if I might weigh in on some of the current questions about GNex 3.4 development.

So let's see..

Q: WHY WORRY ABOUT UPGRADING TO KERNEL 3.4? WHAT DOES IT GET YOU?

A: In general, I wouldn't worry about upgrading to the 3.4 kernel on a production device like the Galaxy Nexus. And here's why:

1. The ducati-m3 binary format for kernel 3.4 was changed (from the 3.0 format). This binary loads a real-time OS onto the dual m3 chips. They handle HD codecs, camera processing and other things. Due to the format change, you won't have a ducati binary built for the new kernel which can use the GNex camera sensors. Best you could do, is use a stock TI board's ducati binary (maybe Blaze / Blase Tablet) which will provide for only HD codecs, etc. I seriously doubt the majority of GNex owners will want to trash the camera in favor of a 3.4 kernel.

NOTE: In theory someone with a proprietary license to TI's ducati MM software and the proprietary camera sensors data sheets could build a 3.4 kernel compatible ducati binary. This may however be the equivalent of "when cows fly over the moon."

2. The TI 3.4 kernel changed how HDMI / Wifi Direct was handled by adding a new dual framebuffer system. To-date, no device other than the new KFire HD 7" (2013) uses this kernel and conspicuously, HDMI was left out on that device. To utilize this new framebuffer system, there are a series of patches for the framework, libhardware and system. (These patches are on omapzoom for the jb-release-mr2.0 branch).

3. The GNex build has consistently been full of blobs (thanks Samsung). And you can expect that many of those blobs may break during the upgrade to the new kernel. So many of them will need to be reverse engineered.

4. All of the device specific drivers will need to be forward ported to the 3.4 kernel.

5. IMHO, the p-android-omap-3.4 kernel isn't really a "tried and true" finished product. Yes, it works on some of the TI dev boards. But, in general there are quite a few patches and bits that are needed for the majority of other boards out there. Some of the code that is standard in the 3.0 kernel just isn't there in the 3.4 kernel. Etc.


Q: THESE PVR BINARIES LOOK AMAZING! WON'T THEY HELP WITH 4.4 DEVELOPMENT?

A: Maybe.. Maybe not. In reality these binaries posted by @aosp are a bit "odd" when it comes to the build. The newest OMAP4 PVR binaries from TI are DDK 1.9 @ 2291151. They were found on the review website and never actually posted into the proprietary git. The actual "standard" JellyBean TI PVR binaries are around DDK 1.9 @ 2166536. You can see from the image that the binaries posted above are DDK 1.8(?).

In the end, the main goal is to be compatible w/ the current surfaceflinger/hwcomposer implementations so that no major hacks are needed to get the GPU functioning. EGL support for GL_OES_EGL_image was key for ICS when it first came out. In JellyBean you needed hwcomposer API 1.0 with a 3.0.31+ omap kernel. For hwcomposer 1.1 API (as implemented by TI) you would need a 3.4 kernel complete with android platform framebuffer patches / extended hwcomposer API.

GNex *could* use the newer TI PVR binaries. But might need to have it's 3.0 kernel's dss/dsscomp/gralloc files edited to be closer to the end of the p-android-omap-3.0-dev kernel's sources. And of course the pvr kernel modules need to match as well.


Q: WHAT ABOUT THE GRAPHIC ISSUES?

A: There could be a variety of reasons why the graphics suffer on the latest builds for the GNex. I don't know all of the details why as I have never dev'd on the GNex, but I'm sure more knowledgable devs have more info. New PVR bins would certainly help with compatibility, but not necessarily solve performance issues.


I applaud JackpotKlavin for getting this booting. I spoke with him early on when he wanted to do this project, and I explained the concerns about compatibility and driver issues. And he took the time to do it ANYWAY -- now that's gutsy. Perhaps someone else (or a team) will pick this up where he left off, but keep in mind some of the challenges that I've mentioned.
The Following 98 Users Say Thank You to Hashcode For This Useful Post: [ View ]