yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Nexus] aosp:
[MENTION=4112553]dhacker29[/MENTION] [MENTION=1664077]kenshin33[/MENTION] [MENTION=4443334]Grarak[/MENTION] [MENTION=4682097]tobiascuypers[/MENTION] [MENTION=4610477]Mevordel[/MENTION]

After some reading I started hunting ;)

http://omapedia.org/wiki/4AJ.2.5_OMAP4-Panda_Jelly_Bean_Release_Notes#Patching_KERNEL

Panda4: Bringup on K3.4

Add back /sys/board_properties.

Add information about all GPIO's used by HDMI.

Configure VRAM and FBs in new way.

Separate registration of EDID eeprom.

http://goo.gl/XqAAor

ARM: OMAP4: SAR: Fix initialization sequence

Currently we cannot boot GP devices because of using not initialized

sar_ram_base at omap_wakeupgen_init(). The sar_ram_base is mapped at

early_initcall only.

This patch correct initialization sequence by dividing wakeupgen

initialization in two stages. Now the SAR dependent part is

initialized right after SAR has been initialized.

http://goo.gl/cf7wFw

panda: create board props in sysfs during init

Create board props sysfs entries during initialization.

It is required for proper chip detection by SGX driver.

http://goo.gl/2Wv7iI

omaplfb: add support for blitter for second fb

enable blitting for second fb for multi display

in presentation mode

http://goo.gl/SnhLh9

panda: Enable TI features

http://goo.gl/K1fGTS

Panda4: device specific configuration to run on K3.4

http://goo.gl/FOCJpI
[Samsung Galaxy Nexus] aosp:
[MENTION=4608636]bsmitty83[/MENTION]

I answered a few folk on g+ about the panda tuna connection and the board-tuna.c has the answer ;)

ARM: tuna: add tuna board file and config

http://goo.gl/f7hLzB

/* Board support file for Samsung Tuna Board.

*

* Copyright (C) 2011 Google, Inc.

* Copyright (C) 2010 Texas Instruments

*

* Based on mach-omap2/board-omap4panda.c
[Samsung Galaxy Nexus] kenshin33:
one major problem though ... ducati-m3 blob. 3.4 changed the format.

I tried these : http://omappedia.org/wiki/Android:_Working_with_pre-built_binaries

(4Aj.2.2 and below -made for 3.0.x) and the camera stopped working (note : may be they needed updated omx/domx sources, that I didn;t check !!!)
[Samsung Galaxy Nexus] Quallenauge:
I can imagine, that the camera isn't supported by the newer ducati blob. This was the case with our Archos G9 devices. So we have to use this blob (in combination with our 3.0.X) kernel. I tried to get the 3.0 based remoteproc working on the 3.4 kernel series but stuck at the standby. That means it works( camera and HD video !) but after the device entered the standby, the ducati subsystem doesn't seems to work. If you are interested, please have a look at -starting- this commit Remote Proc 3.0 in 3.4. (The pm-framework has refactored between the both 3.0 3.4 kernel versions). Another way to get the camera running is to get an v4l driver, but this is another story ;)
[Samsung Galaxy Nexus] kenshin33:
well the tools to build a new/custom one are there ... what's missing is the source (or the know how to build new free ones)

http://omappedia.org/wiki/RPMsg_BIOS_Sources

"file" seems to reconize the new ones as ELF files. the old ones are just data (to "file").
[Samsung Galaxy Nexus] aosp:
Panda: Updates for ducati and display · d1c8a0d · icepeda/omap · GitHub - http://goo.gl/T2aVhC

Forgot these

OMAP4: Panda: Adding board version and ID

Adding support for board version and ID for Panda

at omap_init_board_version.

http://goo.gl/W4unGc

Panda: Updating board and clean up

Updating board Panda to use new power structures

for twl6030, regulators, etc.

Also doing some clean up for unused structures.

http://goo.gl/NROgED

Device: Panda: Updating file system with 4AI stuff

Updating the file system to include the latest enhancements in

4AI release like in DOMX, ducati, wallpapers, etc.

http://goo.gl/0tcwgc

Fixing some compilation and running issues

http://goo.gl/PjqU5o

[MENTION=4608636]bsmitty83[/MENTION] [MENTION=4112553]dhacker29[/MENTION] ;)

We missing lots of awesome from ti omapzoom the GNeX OMAP4460 chipset is capable of so much more
[Samsung Galaxy Nexus] bsmitty83:
I wish I wasn't so scatterbrained because ive been skimming through these commits and I see a lot of stuff I saw in files I added at one point or time. I still need to learn the inner most workings of all the drivers but it all helps me . that and my meds lol

I built a 4.3 ROM from vanirs git , it runs nice , but now I'll start throwing some commits at it and see where I can take it .

I'm using 4.3 just because I feel comfortable with it , I haven't been on 4.4 but for a few days
[Samsung Galaxy Nexus] gautam_nexus:
I am not sure If this is going to help or not..but I think this has something to do with power vr graphics issue. [MENTION=4608636]bsmitty83[/MENTION]

http://review.cyanogenmod.org/#/c/54797/
[Samsung Galaxy Nexus] aosp:
Those are for the i9100g and we have those in CM11 already ;)
[Samsung Galaxy Nexus] aosp:
[MENTION=4608636]bsmitty83[/MENTION] [MENTION=4112553]dhacker29[/MENTION] Too get the tuna inline and using all the OMAP enhancements from omapzoom shouldn't we get it building in the omapzoom repos first?

Add TI device trees

http://goo.gl/2YHleS
[Samsung Galaxy Nexus] BestBrd:
Sorry,i don't want to disturb the developement of the kernel(probably i already did with this post) but i didn't undersand so much(i'm not english and you are using words that i don't know)..are you building a 3.4 kernel or a 3.0 kernel with the updated drivers?

If you are building a 3.4 kernel,how much it takes to have a flashable zip?(i know that we don't have to ask for eta's,but all gnex users are following you guys,and we are impatient :) )

Thanks if you will reply and...Keep up guys,we love you! ;) :thumbup::thumbup::thumbup:
[Samsung Galaxy Nexus] aosp:
[MENTION=4636351]Quallenauge[/MENTION]

Not sure but did you see the below commit?

ARM: OMAP2+: add remoteproc devices for OMAP4

OMAP4 has two remote processor subsystems - a dual ARM Cortex-M3 IPU

and a TI C6400-based DSP subsystem. This patch adds the support for

creating remoteproc platform devices, and other necessary platform

specific hooks needed for enabling and booting the remote processors.

A OMAP_REMOTEPROC dependent config option is defined for each rproc

device that provides the choice to enable/disable creating the

corresponding rproc device. The clock and reset management for these

devices is provided by the omap_device/omap_hwmod layer and hence

has to be implemented through platform data functions ops. The

omap_device layer does not program the resets when enabling a device

and is handled by the remoteproc platform hooks. The hooks perform

the reset management based on the remoteproc subsystem type. An IPU

subsystem has two resets, and the remoteproc device management code

asserts/deasserts these together because of the intrinsic device

management dependencies such as a shared MMU and shared cache between

the two Cortex-M3 processors. This allows the OMAP IPU to be run in

either a SMP-mode or a non-SMP mode (using a post-processed combined

image), and is transparent to the remoteproc core driver code.

Each of the devices is bound to its dedicated IOMMU device, used for

managing the MMU; and a dedicated mailbox instance for signalling

message availability and inter processor communication. These slave

devices are used by the remoteproc driver core through the respective

API provided by the iommu and mailbox drivers. A dedicated CMA pool,

tied with each remoteproc device, is used for managing the various

memory needs of the remote processors.

The current CMA pools and sizes are defined statically for each

device. The starting addresses are fixed to meet current dependencies

on the remote processor side, and will go away when the remote-side

code has been improved to gather this information runtime during its

initialization. There are no Kconfig symbols associated with the CMA

bases and sizes, since it would not scale well for remoteproc devices

on multiple SoCs without making the configuration code cumbersome.

The remoteproc CMA pools are also defined to be within the first 512MB

of RAM and end exactly at 0xA000000. The CMA base addresses are

computed by subtracting the required size from 0xA0000000. This allows

a vmalloc size of upto 496MB [__pa(VMALLOC_START) value of 0xA0800000],

without eliciting invalid pfn warnings when the cma regions are

activated.

Based on patches developed previously for TI product kernels, and

includes contributions from:

Fernando Guzman Lugo <fernando.lugo@ti.com>

Ohad Ben-Cohen <ohad@wizery.com>

Juan Gutierrez <jgutierrez@ti.com>

http://goo.gl/WlAoPH
[Samsung Galaxy Nexus] aosp:
[MENTION=4636351]Quallenauge[/MENTION]

Forgot another one lol ;)

Merge git://git.ti.com/rpmsg/remoteproc into ti2013.04.02-rpmsg-3.8.y

Merge remoteproc tree with support for OMAP4, OMAP5 and DRA7xx remote

processors. The mailbox and iommu trees are also pulled in indirectly

through the remoteproc tree. This should enable loading base-images

on each of the remote processors on any of the above SoCs.

* git://git.ti.com/rpmsg/remoteproc: (66 commits)

ARM: OMAP: remoteproc: assign timers for DRA7xx IPU processors

ARM: dts: DRA7: Add IPU timer capabilities

ARM: OMAP2+: add support for DRA7xx processors

ARM: OMAP2+: define a common reserve function for DRA7xx

ARM: OMAP2+: control: add dsp boot programming support for DRA7xx

ARM: DRA7: hwmod_data: add data for ipu & dsp processors

ARM: OMAP: remoteproc: use separate CMA pool data for OMAP5

ARM: OMAP: remoteproc: separate out omap_rproc_pdev_data for OMAP5

ARM: OMAP2+: add support for OMAP5 remote processors

ARM: OMAP2+: pass a SoC identifier to omap_rproc_reserve_cma

remoteproc/omap: request a timer(s) for remoteproc usage

ARM: OMAP2+: add remoteproc devices for OMAP4

remoteproc/omap: remove the oh_name_opt field from platform data

remoteproc/omap: check for undefined mailbox messages

remoteproc: add debugfs entry to print the firmware version info

remoteproc: add an api to do pa to da conversion

remoteproc: add safe version of vdev_to_rproc

remoteproc/omap: set dependency on CONFIG_CMA

ARM: OMAP4+: Add a timer attribute for timers that can interrupt IPU

remoteproc: fix 80-char checkpatch errors in remoteproc code

...

http://goo.gl/USV5O7
[Samsung Galaxy Nexus] IT_Blackbelt:
Yes they are attempting to get a 3.4 kernel working for our Galaxy Nexus, but there is a lot of work that goes into it. Once it is working, im sure there will be a zip to flash it and ROM developers will include it in their ROM's (atleast I will)
[Samsung Galaxy Nexus] aosp:
Below repo seems to bring the omap4 panda4 inline for all the new 3.0.x awesome have to start at the bottom first ;)

Revert "configs: blaze/panda: zero out remoteproc dynamic carveout (dsp)... · 1e0b123 · icepeda/omap · GitHub - http://goo.gl/dGdFIi
[Samsung Galaxy Nexus] nixholas:
Looking at all these commits, OMAP gave what tuna needs to build. All we have to do is just to recreate the tuna-specific files in the 3.4 format with the inclusion of the new variables and arrays.
[Samsung Galaxy Nexus] aosp:
Get it booting on omapzoom 3.0.X branch first then bring it up to 3.4.X you got it lots of goodies on omapzoom we can use once kernel is inline ;)
[Samsung Galaxy Nexus] nixholas:
Ohh. That method. I'll be rooting for you guys! :D In the meantime, I'll be using the conventional dev's way by purely patching up to 3.13.
[Samsung Galaxy Nexus] aosp:
[MENTION=4608636]bsmitty83[/MENTION] Found another omapzoom graphic enhancement the GNeX can utilize today ;)

blaze_defconfig: Update kernel version (blitsville and HWC header changes)

A change in the blitsville and hwc header files have been done in the

following patches.

http://review.omapzoom.org/#/c/21203/

http://review.omapzoom.org/#/c/21118/

http://review.omapzoom.org/#/c/21145/

This requires to update the kernel version to 3.0.21-00003-OMAP-Android

http://goo.gl/g2ydhc

gcx: vivante gcx update

this is the 1/20 update from vivante, which separates

ioctl, gcbv, and gccore.

http://goo.gl/0YqGRL

Initial BLTsville API definition.

BLTsville is the open 2-D API designed to provide an abstract

interface for both hardware and software 2-D implementations.

BLTs (BLock Transfers) involve the moving around of blocks

(rectangles) of pixels.

http://goo.gl/YJXjBo

Add Open Color format Definitions (OCD).

http://goo.gl/UkAU7R

Add BLTsville public API.

http://goo.gl/zbbdc1

Add TI optimized CPU BLTsville implementation binaries.

http://goo.gl/xNM7y1

Add initial gc2d bltsville files.

Initial bltsville files to enable Vivante Corp 2d gcxxx hardware.

Only basic 2D operations have been tested.

http://goo.gl/MgsAjG

2D acceleration libraries and supporting headers

http://goo.gl/HS6RW0

BLTSVILLE_ENHANCEMENT :=true
[Samsung Galaxy Nexus] Quallenauge:
I may be wrong but isn't bltsville only available at 4470 and later?

---------- Post added at 09:35 AM ---------- Previous post was at 09:28 AM ----------

But this commit relies also on the new ducati format. Either we create a legacy loader which provides mostly the same result for the caller or we have to use the 3.0 implementation as base. Or it is possible to create a converter, but I don't have any knowledge in writing ELF files. The file format of the 3.0 series is well documented! Firmware_Image_Format.

But even we have an loader or an converted binary, I doubt that this will work, because of possible code changes in the ducati firmware. In the best case (ELF is supported) it should possible to use also newer kernel side implementations of the remoteproc / rpmsg framework.
[Samsung Galaxy Nexus] aosp:
[MENTION=4636351]Quallenauge[/MENTION] [MENTION=4112553]dhacker29[/MENTION] [MENTION=4608636]bsmitty83[/MENTION]

OMAP4/OMAP5: OMAP GCXX: Check for GC320 across OMAP versions

This patch removes the 4470 specific check and instead

uses the generic omap_has_gc320() check which works

for both omap4 and omap5

http://goo.gl/5Aj9pp

[Android] Restrict this component only for TI platforms

This project if present, gets built for non TI targets also.

Restrict this project to be built only for TI platforms (omap4, omap5, jacinto6).

http://goo.gl/OuF1wd

gcx: preparation for userspace bltsville support.

Merged differences between bltsville userspace and proxy.

Added support for callback in user bltsville.

http://goo.gl/8MkVkn

BV: Update headers to 2.2

Add bvbltparams.src2auxdstrect,

bvbltparams.maskauxdstrect,

BVFLAG_SRC2_AUXDSTRECT and BVFLAG_MASK_AUXDSTRECT;

Add BVAT_reserved2 bvauxtype;

http://goo.gl/Zd0LLA

Optimized Skia DrawBitmap function by calling into BLTsville

Introduced BLTsville 2D library which increases the speed of Skia in the fol

color space conversion

copy

non-filtered scale

blend

blend with non-filtered scale

BLTsville will fall back to Skia if the operation is not supported.

Fixed incorrect format mapping and checking unsupported paint

Require BLTSVILLE_ENHANCEMENT flag to enable code

http://goo.gl/lXZFcL

Enabled solid fill paths to BLTsville to increase performance

Correct color calculation SkBlitter_RGB16

Different color is caused by the incorrect usage of the premultiplied source color which makes the resulting color to be a different shade.

http://goo.gl/DPe6DW
[Samsung Galaxy Nexus] Quallenauge:
BLTsville

But the feature isn't activated for <OMAP4470_REV_ES1_0 revisions at kernel side: Please have a look:

arch/arm/mach-omap2/id.c;#l321

So makes it sense to add these commits? (Is there a fast software layer for that?)
[Samsung Galaxy Nexus] aosp:
Yes we missing the commits I linked and the libs ;)

[Android] Restrict this component only for TI platforms

This project if present, gets built for non TI targets also.

Restrict this project to be built only for TI platforms (omap4, omap5, jacinto6).

http://goo.gl/okqDJ5

[TICPU] Updated CPU based library

This patch updates the existing ticpu library.

The earlier library was not getting loaded on OMAP5 or J6

for linux. Installation procedure is accordingly updated.

http://goo.gl/99Tszc

http://omapzoom.org/?p=platform/ext...droid-Release-Notes.html;hb=refs/heads/master

http://omapzoom.org/?p=platform/ext...Linux-Release-Notes.html;hb=refs/heads/master

http://omapzoom.org/?p=platform/ext...tree;h=refs/heads/master;hb=refs/heads/master

platform/external/bltsville

[MENTION=4608636]bsmitty83[/MENTION] [MENTION=4112553]dhacker29[/MENTION]
[Samsung Galaxy Nexus] Link_of_Hyrule:
Have you guys been able to get the 3.4 kernel to compile and boot and actually display anything or are we still at the blind adb state?
[Samsung Galaxy Nexus] Vekhez:
There was a 3.4 AK Kernel floating around in this thread somewhere. Booted, worked and everything. For about 30 seconds.
[Samsung Galaxy Nexus] :
Kernelpanic ;)

Bad thing was there werent any sources.
[Samsung Galaxy Nexus] Vekhez:
Yeah, too bad that there weren't any sources.. since that would have been a awesome head start. But people were also saying that it was the same 4.3 AK kernel, just with a number change.
[Samsung Galaxy Nexus] randommmm:
I am not sure do you acknowledge of this issue since Android 4.3

https://code.google.com/p/android/issues/detail?id=59020

Is it technically possible to revert some kernel commit (as I heard that is a kernel problem ) from 4.2.2 to 4.3 to fix it?
[Samsung Galaxy Nexus] Vekhez:
The page I asked for does not exist.
[Samsung Galaxy Nexus] randommmm:
Sorry, stupid copy paste mistake, I've fixed the link....

https://code.google.com/p/android/issues/detail?id=59020
[Samsung Galaxy Nexus] piterdemon:
One noob question, how near we are to get working 3.4 ?

Wytapatano z Ainol Novo 7 Fire CM 10.2
[Samsung Galaxy Nexus] pattyboi:):
we arent near,its extremelly far off from what ive read so far.

BACK TO THE TOPIC;)
[Samsung Galaxy Nexus] aosp:
[MENTION=4636351]Quallenauge[/MENTION]

Thought you might like these ;)

https://gitorious.org/omap4-v4l2-camera/pages/Home

https://github.com/jmondi/omap4_V4L2_AndroidJB

[MENTION=4608636]bsmitty83[/MENTION]

http://redmine.replicant.us/projects/replicant/wiki/GalaxyNexusSerialConsole

http://redmine.replicant.us/projects/replicant/wiki/Omap4-tiler-Camera

rpmsg: omx: Try(and fail) to make it works without the powervr driver.

http://goo.gl/9HDYWK
[Samsung Galaxy Nexus] metalspring:
Anarkia is still active, just not on the gnex I think

Anyone try messaging him and asking what he used as source or anything that might help get a 3.4 kernel working better?
[Samsung Galaxy Nexus] Vekhez:
I did with no reply. Maybe someone like [MENTION=2838735]aosp[/MENTION] could..?
[Samsung Galaxy Nexus] Hetalk:
[MENTION=4519152]Khizar[/MENTION] can help here. [MENTION=1106390]anarkia[/MENTION]1976

Please help.
[Samsung Galaxy Nexus] Nephilim:
Ill message Stefano as soon as I get to my PC. ;)

Sent from my Android 4.4.1 Galaxy Nexus
[Samsung Galaxy Nexus] andQlimax:
R: [WIP/DEV] I've got a "booting" 3.4 kernel, looking to get a dev team started

What advantages it will have aside from be an higher number and never be stable at 100%? Why 3.4 and not 3.7 or 3.8?

Inviato dal mio Galaxy Nexus con Tapatalk 2
[Samsung Galaxy Nexus] DanielSanchez:
Re: [WIP/DEV] I've got a "booting" 3.4 kernel, looking to get a dev team started

You could read the thread and find out.
[Samsung Galaxy Nexus] andQlimax:
R: [WIP/DEV] I've got a "booting" 3.4 kernel, looking to get a dev team started

Ok my thoughts was right then, no advantages at all.

Inviato dal mio Galaxy Nexus con Tapatalk 2
[Samsung Galaxy Nexus] renaud:
Re: [WIP/DEV] I've got a "booting" 3.4 kernel, looking to get a dev team started

From 2.6.35 to 3.0, there were obvious performance advantages. From 3.0 to 3.4, I am not sure it matters that much.
[Samsung Galaxy Nexus] josip-k:
Re: [WIP/DEV] I've got a "booting" 3.4 kernel, looking to get a dev team started

So we wont see 3.4 kernel..
[Samsung Galaxy Nexus] Smallsmx3:
Re: [WIP/DEV] I've got a "booting" 3.4 kernel, looking to get a dev team started

Who cares
[Samsung Galaxy Nexus] Sylde:
3.4 was a huge improvement in battery consumption ... but probably linked with acpi and x86 architecture. Possibly not relevant for android phones, but it worth the try.

For me, succeeding in using 3.4, will allways be useful to push the kernel to 3.6 and 3.7 (knowing a much better support is done with the latest versions).
[Samsung Galaxy Nexus] gnustomp:
Re: [WIP/DEV] I've got a "booting" 3.4 kernel, looking to get a dev team started

By the time we get 3.4 working fully, 3.9 will be out.
[Samsung Galaxy Nexus] nicholaschan24:
Re: [WIP/DEV] I've got a "booting" 3.4 kernel, looking to get a dev team started

Now google are working on 3.8 for android, will this be any easier?
[Samsung Galaxy Nexus] akira02rex:
No, because TI has to release drivers made for it. Unless these guys know how to write their own device drivers I wouldn't ever count on it.

It would take someone with the know-how from TI to do this sort of work. TI does release their stuff open source so there's a tiny chance.
[Samsung Galaxy Nexus] awandroid89:
Maybe this thread should be in Original Development so more developer could discuss about this..
[Samsung Galaxy Nexus] akash3656:
Re: [WIP/DEV] I've got a "booting" 3.4 kernel, looking to get a dev team started

For the NP (Nexus Prime) there isn't a original development section.
[Samsung Galaxy Nexus] nicholaschan24:
Re: [WIP/DEV] I've got a "booting" 3.4 kernel, looking to get a dev team started

Exciting news here :)

http://xdaforums.com/showthread.php?p=38819834
[Samsung Galaxy Nexus] deepayanneogi:
Yes indeed. :good:
[Samsung Galaxy Nexus] JackpotClavin:
I just took a look at that. I looked around the directories and it appears to be like a mix of 3.0 and 3.4 together. I tried merging that guy's 3.4 git branch with the Vanilla 3.4 Linux kernel's source and even the Android-Common 3.4 kernel's source and I got thousands of merge conflicts between the two repositories so idk which 3.4 kernel source he used to merge because it's not that close to the normal regular 3.4 kernel but if it works, it works :)
[Samsung Galaxy Nexus] ak:
I my friend .... if you want i'm tring to merge 3.8 exp kernel with tuna branch:

git@github.com:anarkia1976/AK-cylon-3.8.git

Tuna source:

3.0

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

Common source:

3.8

https://android.googlesource.com/kernel/common.git

I have merged linux 3.8.2:

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?h=linux-3.8.y

What is your opinion?

Do you think possible a merge like this?
[Samsung Galaxy Nexus] JackpotClavin:
It's tough for sure. Google's 3.0.y for the Tuna is kinda weird. There are still parts in their 3.0.31 that were rendered obsolete in like 3.0-rc3, so there's stuff that we need in 3.0 that aren't gonna be in 3.4. Unless somebody can get our display working with 3.4, it probably isn't gonna happen. My 3.4 github is the first post, and unless somebody can get our display working, it's not looking good. One thing to mention is that our device relies on the ducati binary in /system/vendor/firmware, and IIRC, another dev for the Kindle Fire (which is omap4430) named Hashcode said that a lot memory-related stuff for codecs and the camera and whatnot is missing in 3.4, and is a real headache to take everything that works in 3.0 and bring up to 3.4 so we won't have sound or display codecs or a camera or anything. Also, we will need a 3.4-compatible ducati binary, which is proprietary. In my 3.4 try, I used vanilla Linux from kernel.org + adb drivers. Hashcode told me that the 3.4 repository from omapzoom would probably be a better alternative to try to get the display working, but when I tried to use the omapzoom repository, I couldn't get my USB to initialize, but was only able to get to work when I tried 3.4 on the vanilla Linux source. If somebody out there wants to try to merge the omapzoom 3.4 with my 3.4-Tuna in the OP and see where that gets you, give it a shot! You'll probably need UART access though... and I didn't feel like opening my phone up

Best of luck on your 3.8!
[Samsung Galaxy Nexus] awandroid89:
any good news or this development just stop?
[Samsung Galaxy Nexus] shriom_manerker:
so [MENTION=3685904]anarkia1976[/MENTION] [MENTION=3332811]faux123[/MENTION] [MENTION=3292224]franciscofranco[/MENTION] what say ? work together to make this happen ? :)