[DDK 1.9] OmniROM DDK 1.9 Test Version

Search This thread

Ziyan

Recognized Developer
Jun 6, 2010
875
9,127
30
Introduction
This is a test version of OmniROM with SGX DDK 1.9 graphics drivers, as well as many OMAP-related kernel updates. No, this isn't 3.4, but a LOT of TI updates were packed into the kernel. Currently, this is only for maguro, but anyone can build it for toro/toroplus with the sources.

Features
The ROM and the kernel has a stock feeling - no mods were added.
Most notable new features:
- SGX DDK 1.9@2291151
- GPU governor
- Enabled 384 MHz GPU frequency (as a part of the OMAP updates)
- Tons of background changes for the kernel

Important notes
Camera and OMX is not working yet! This turned out to be a harder task for me to fix than implementing the new GPU drivers...
Other bugs are not known yet, but there may be some! Bug reports are welcome.

Thanks to everyone who helped me, especially Hashcode, as I used his repos as an example on how to set up things properly.

FAQ
How can I install this?
Just flash the ROM zip (and optionally GAPPS), and you're done.

Can I install this on top of Omni roms?
Yes, you should be able to do so without data loss.

Can I revert to non-1.9 Omni after this without data loss?
Yes.

Is this faster than the current ROMs/kernels?
As this is a stock-like ROM and kernel, not necessarily - there are no optimizations, etc added.
However, if one adds the optimizations used on current custom roms and kernels, this should be faster than them.

Can I install another kernel?
No, the new drivers require the ROM and the kernel side to match each other. Only this combination will work.

When will you fix camera?
I'm trying, but I don't have much success...

Can I help?
Sure, I appreciate any help, as I'm running out of ideas on how to fix camera and OMX.

Can I build this stuff myself?
Of course - everything needed is on my github. You'll need the following repos added to your Omni sources:
omni_android_device_samsung_tuna
omap (newpvr2 branch)
proprietary_vendor_samsung_tuna

XDA:DevDB Information
OmniROM DDK 1.9 Test, ROM for the Samsung Galaxy Nexus

Contributors
Ziyan
ROM OS Version: 4.4.x KitKat
ROM Kernel: Linux 3.0.x
Based On: OmniROM

Version Information
Status: Testing

Created 2014-07-13
Last Updated 2014-07-13
 

matoushybl

Senior Member
Aug 23, 2012
54
21
I've installed it and it feels smooth, I've not encountered any bugs yet. Have you tried removing "kitkat workarounds" from frameworks/native?

Thanks for your awesome work
 

musical_chairs

Senior Member
Mar 6, 2012
1,072
1,226
Thanks for posting this, I'm going to try building for toroplus, since we seem to get left out of the excitement so often. My internet connection is slow and so is my computer, so you will probably have everything fixed before I get a chance to even look for bugs. :)
 

Ashtrix

Senior Member
Dec 21, 2010
1,635
591
Amazing work bro, wishing u best of luck !!
I'm on F2Fs otherwise would have tested this asap...
 

apollo07

Senior Member
May 25, 2013
56
36
Santiago
Thanks for the amazing work you've brought to the gnex, but since i'm on F2FS i was wondering if you could make a F2FS compatible version of this rom?
 

Ziyan

Recognized Developer
Jun 6, 2010
875
9,127
30
I've installed it and it feels smooth, I've not encountered any bugs yet. Have you tried removing "kitkat workarounds" from frameworks/native?

Thanks for your awesome work
Yeah, but the glitches are still there. Actually, that may be a bug in android itself (it affects a lot of devices), they may have fixed it on L... and those workarounds are really not important, as the problem only comes when taking screenshots. And since android takes screenshots for the rotation animation, etc, those glitches appear there as well. The workarounds just force it to take screenshots on CPU-path, they don't change anything else.
I think they fixed it in DDK 1.12 (which is the next version after 1.9), but that's another story, as I think it does not support our GPU (but it may in the future).

Thanks for the amazing work you've brought to the gnex, but since i'm on F2FS i was wondering if you could make a F2FS compatible version of this rom?
Not yet, I'm focusing on camera for now :)
 

Ashutos1997

Senior Member
May 19, 2012
534
693
Chicago, Illinois
www.facebook.com
Yeah, but the glitches are still there. Actually, that may be a bug in android itself (it affects a lot of devices), they may have fixed it on L... and those workarounds are really not important, as the problem only comes when taking screenshots. And since android takes screenshots for the rotation animation, etc, those glitches appear there as well. The workarounds just force it to take screenshots on CPU-path, they don't change anything else.
I think they fixed it in DDK 1.12 (which is the next version after 1.9), but that's another story, as I think it does not support our GPU (but it may in the future).


Not yet, I'm focusing on camera for now :)
Ziyan, thanks for the awesome work ;)
 

Top Liked Posts

  • There are no posts matching your filters.
  • 35
    Introduction
    This is a test version of OmniROM with SGX DDK 1.9 graphics drivers, as well as many OMAP-related kernel updates. No, this isn't 3.4, but a LOT of TI updates were packed into the kernel. Currently, this is only for maguro, but anyone can build it for toro/toroplus with the sources.

    Features
    The ROM and the kernel has a stock feeling - no mods were added.
    Most notable new features:
    - SGX DDK 1.9@2291151
    - GPU governor
    - Enabled 384 MHz GPU frequency (as a part of the OMAP updates)
    - Tons of background changes for the kernel

    Important notes
    Camera and OMX is not working yet! This turned out to be a harder task for me to fix than implementing the new GPU drivers...
    Other bugs are not known yet, but there may be some! Bug reports are welcome.

    Thanks to everyone who helped me, especially Hashcode, as I used his repos as an example on how to set up things properly.

    FAQ
    How can I install this?
    Just flash the ROM zip (and optionally GAPPS), and you're done.

    Can I install this on top of Omni roms?
    Yes, you should be able to do so without data loss.

    Can I revert to non-1.9 Omni after this without data loss?
    Yes.

    Is this faster than the current ROMs/kernels?
    As this is a stock-like ROM and kernel, not necessarily - there are no optimizations, etc added.
    However, if one adds the optimizations used on current custom roms and kernels, this should be faster than them.

    Can I install another kernel?
    No, the new drivers require the ROM and the kernel side to match each other. Only this combination will work.

    When will you fix camera?
    I'm trying, but I don't have much success...

    Can I help?
    Sure, I appreciate any help, as I'm running out of ideas on how to fix camera and OMX.

    Can I build this stuff myself?
    Of course - everything needed is on my github. You'll need the following repos added to your Omni sources:
    omni_android_device_samsung_tuna
    omap (newpvr2 branch)
    proprietary_vendor_samsung_tuna

    XDA:DevDB Information
    OmniROM DDK 1.9 Test, ROM for the Samsung Galaxy Nexus

    Contributors
    Ziyan
    ROM OS Version: 4.4.x KitKat
    ROM Kernel: Linux 3.0.x
    Based On: OmniROM

    Version Information
    Status: Testing

    Created 2014-07-13
    Last Updated 2014-07-13
    23
    I'm sad to say this, but I have to give up. Generally, I say "never give up", that's what I did with DDK 1.9 & OMX as well, but I'm afraid there's only one solution to our problem: an updated ducati.
    Here's what I know about it (with the help of the tuna dev team, especially Hashcode who kindly helped me understanding this mess), though I may be wrong, as this is one of the most complex element of the OMAP architecture:
    Generally, ducati is a separate proprietary binary that contains code to the device-specific camera sensors. It controls the M3 processors, which are used for video acceleration. The kernel itself doesn't know about the camera sensors and the M3 processors, it just loads the ducati binary, then userspace can instruct it to send over the camera properties, and begin transmitting the already decoded (accelerated) video. Though video acceleration itself isn't device specific, ducati have to have access to the M3 processors that do the job - while it could communicate with them through the kernel, it would be way slower than having a more direct access to them, so there's very minimal OMX/Camera code in the kernel, most of it is in the ducati binary. Obviously, there's a 3rd layer in the kernel which provides access to the ducati itself for userspace - that's the remoteproc portion of the kernel. It also manages the ION memory allocations, as the accelerated video buffers will be stored in the memory, that's what userspace reads. (There's a high chance this part is wrong, but hopefully you get the idea).
    This is where the problem begins. The ducati binary itself is very strict about that memory, it uses ram addresses and stuff like that to allocate it. Obviously, this content has to go through the PVR/DDK driver to get it "displayed" on the screen... however, PVR itself uses ION allocations too. PVR 1.9 needs updated ION allocation methods, it shares some buffers with ducati, etc... so the remoteproc module needs to be updated too, to manage the enhanced allocations with ducati.
    The problem is that tuna uses a ducati from late 2011! With it, tuna wins the most outdated ducati binary award, as every OMAP device I found has way more up-to-date ducati that already supports those enhanced ION allocations. Yes, that includes LG omap devices, Samsung omap devices, Amazon omap devices...

    Again, this is more complex than this, I tried to write an understandable novel about how it works basically. Don't take it serious, as it may be wrong in some aspects, but it works like that.

    tl;dr
    ducati has proprietary camera sensor codes
    sgx ddk 1.9 requires updated ION buffer allocations
    tuna's very very VERY old ducati can't allocate the ION buffers required for camera, as it can't communicate with the updated allocator
    Solution: an updated ducati binary. All this would be very easy with it - as you may have understood, the idea itself is pretty nice. Basically, everything related to camera is inside the ducati, userspace/kernel receives the camera output in a generalized format. Imagine that you want to add an extra camera to tuna. All you have to do is add it's sensor code to the ducati, and you're all set, no need for rom/kernel-side changes.

    Now getting that updated ducati binary... is a big problem. I'm afraid only Google or Samsung could provide it. If they would at least publish it's sources, that would be already progress.

    However, don't worry, I won't retire from tuna. I continue working on the kernel and rom side. With the dev team, we're already testing the updated OMAP kernel (without ddk 1.9), which already a HUGE update over our stock kernel. My first "public" work on tuna is already pushed :victory: https://github.com/omnirom/android_device_samsung_tuna/commits/android-4.4

    Edit: wow, this post became a mess too, hope it's understandable :D
    9
    How is development going on? It would be a great benefit for the Galaxy Nexus community. Thanks for the awesome work!

    Sent from my Galaxy Nexus with Tapatalk

    I have a side project going on, so I probably won't do much for a few days about this. But don't worry, I didn't give up yet :good:
    7
    I'm sad to say this, but I have to give up. Generally, I say "never give up", that's what I did with DDK 1.9 & OMX as well, but I'm afraid there's only one solution to our problem: an updated ducati.
    Here's what I know about it (with the help of the tuna dev team, especially Hashcode who kindly helped me understanding this mess), though I may be wrong, as this is one of the most complex element of the OMAP architecture:
    Generally, ducati is a separate proprietary binary that contains code to the device-specific camera sensors. It controls the M3 processors, which are used for video acceleration. The kernel itself doesn't know about the camera sensors and the M3 processors, it just loads the ducati binary, then userspace can instruct it to send over the camera properties, and begin transmitting the already decoded (accelerated) video. Though video acceleration itself isn't device specific, ducati have to have access to the M3 processors that do the job - while it could communicate with them through the kernel, it would be way slower than having a more direct access to them, so there's very minimal OMX/Camera code in the kernel, most of it is in the ducati binary. Obviously, there's a 3rd layer in the kernel which provides access to the ducati itself for userspace - that's the remoteproc portion of the kernel. It also manages the ION memory allocations, as the accelerated video buffers will be stored in the memory, that's what userspace reads. (There's a high chance this part is wrong, but hopefully you get the idea).
    This is where the problem begins. The ducati binary itself is very strict about that memory, it uses ram addresses and stuff like that to allocate it. Obviously, this content has to go through the PVR/DDK driver to get it "displayed" on the screen... however, PVR itself uses ION allocations too. PVR 1.9 needs updated ION allocation methods, it shares some buffers with ducati, etc... so the remoteproc module needs to be updated too, to manage the enhanced allocations with ducati.
    The problem is that tuna uses a ducati from late 2011! With it, tuna wins the most outdated ducati binary award, as every OMAP device I found has way more up-to-date ducati that already supports those enhanced ION allocations. Yes, that includes LG omap devices, Samsung omap devices, Amazon omap devices...

    Again, this is more complex than this, I tried to write an understandable novel about how it works basically. Don't take it serious, as it may be wrong in some aspects, but it works like that.

    tl;dr
    ducati has proprietary camera sensor codes
    sgx ddk 1.9 requires updated ION buffer allocations
    tuna's very very VERY old ducati can't allocate the ION buffers required for camera, as it can't communicate with the updated allocator
    Solution: an updated ducati binary. All this would be very easy with it - as you may have understood, the idea itself is pretty nice. Basically, everything related to camera is inside the ducati, userspace/kernel receives the camera output in a generalized format. Imagine that you want to add an extra camera to tuna. All you have to do is add it's sensor code to the ducati, and you're all set, no need for rom/kernel-side changes.

    Now getting that updated ducati binary... is a big problem. I'm afraid only Google or Samsung could provide it. If they would at least publish it's sources, that would be already progress.

    However, don't worry, I won't retire from tuna. I continue working on the kernel and rom side. With the dev team, we're already testing the updated OMAP kernel (without ddk 1.9), which already a HUGE update over our stock kernel. My first "public" work on tuna is already pushed :victory: https://github.com/omnirom/android_device_samsung_tuna/commits/android-4.4

    Edit: wow, this post became a mess too, hope it's understandable :D
    Sad to hear but this don't need to be the end. Over at galaxy young I saw broadcom releasing GPU binary source after community requests so it may be worth a try... Maybe a petition or sth like that could succeed in the end there are a lot of gnex user out there :)
    6
    I've installed it and it feels smooth, I've not encountered any bugs yet. Have you tried removing "kitkat workarounds" from frameworks/native?

    Thanks for your awesome work
    Yeah, but the glitches are still there. Actually, that may be a bug in android itself (it affects a lot of devices), they may have fixed it on L... and those workarounds are really not important, as the problem only comes when taking screenshots. And since android takes screenshots for the rotation animation, etc, those glitches appear there as well. The workarounds just force it to take screenshots on CPU-path, they don't change anything else.
    I think they fixed it in DDK 1.12 (which is the next version after 1.9), but that's another story, as I think it does not support our GPU (but it may in the future).

    Thanks for the amazing work you've brought to the gnex, but since i'm on F2FS i was wondering if you could make a F2FS compatible version of this rom?
    Not yet, I'm focusing on camera for now :)