Just wondering...
Does this mean we can bake an SGS2 ROM with Android 3.2 now, or are the listed caveats insurmountable?
Android 3.2 source code available
As usual, and just like we had done before for Android 3.0 and 3.1,
the source code for the GPL and LGPL components of Android 3.2 is
available in the Android Open-Source Project, under the tag
android-3.2_r1
The process to build it is the same as what we had for 3.0 and 3.1:
# start from a master client
repo init -m 3.2-base.xml
repo sync
repo forall -c git checkout android-3.2_r1
# build with the regular process
# to come back to a plain master
repo init -m default.xml
repo sync
The caveats are unchanged since 3.1:
-the checkout command will return an error message because the tag
doesn't exist in all projects, ignore it.
-the compiled isn't any more likely to work on actual hardware as 3.1
did, since the same binary incompatibilities are still there.
JBQ
--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.
Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.
Tsais said:
Just wondering...
Does this mean we can bake an SGS2 ROM with Android 3.2 now, or are the listed caveats insurmountable?
Android 3.2 source code available
As usual, and just like we had done before for Android 3.0 and 3.1,
the source code for the GPL and LGPL components of Android 3.2 is
available in the Android Open-Source Project, under the tag
android-3.2_r1
The process to build it is the same as what we had for 3.0 and 3.1:
# start from a master client
repo init -m 3.2-base.xml
repo sync
repo forall -c git checkout android-3.2_r1
# build with the regular process
# to come back to a plain master
repo init -m default.xml
repo sync
The caveats are unchanged since 3.1:
-the checkout command will return an error message because the tag
doesn't exist in all projects, ignore it.
-the compiled isn't any more likely to work on actual hardware as 3.1
did, since the same binary incompatibilities are still there.
JBQ
--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.
Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.
Click to expand...
Click to collapse
honeycomb is just meant for tablets not cellphones..
ditto to the guy above me...
and this belongs in general, read the damn stickies!
We have known for about week now as well... thanks for the old news!
<Ninpo> rofl it's only the GPL and LGPL components
<Ninpo> so not the full thing by a long shot since most of Android is Apache licensed
Also, this is only the LGPL and GPL components, which is a hell of a long shot away from being actual Honeycomb sources, since most of Android is under the Apache license.
I remember reading that Google will release full source code for Honeycomb some time after Ice Cream Sandwich release.
@Entropy512
I hope u dont mind asking me a few questions in here about ur GIT and CAF merges, i follow u daily but i simply lost overview atm as im still not 100% familiar with CAF. Ur descriptions are really nice, but i cant follow them anymore. I dont want to fork ur repo, because the learning curve would drop to zero if i would do.
Ok first of all i look here for the right release. This would be of course in case of FIND 7 -> LNX.LA.3.2.5-02310-8x74.0 all good so far. Then i simply clone me the this tree. I have now correct caf tree for comparing it with the official find 7 Kernel by OPPO. Ok so far no problems... i diff or meld them together.
First thing i dont understand is why u started at 19th_Dec. Is there a sepcific reason why u did this ?? U apply oppo changes on top top of them, ok i get this, but why from 19th ?? I synced the kernel with yesterdays date and would start from here, but im sure u have ur reasons why... im more then interessted
And where i lost overview:
U created a new branch with 3.5 tag, as far as i understand this is because u will bring the changes up to KK because the LNX.LA.3.2.5-02310-8x74.0 is JB. But why then the oppo_kernel branch anyway, why havent u started with AU_LINUX_ANDROID_KK_3.5.04.04.02.003.298.
Dont get me wrong, i dont want to annoy anyone, i just want to understand how this works and why.. i hope u can shed some light in here, I would really highly appreciate it Thanks in advance
n3ocort3x said:
@Entropy512
I hope u dont mind asking me a few questions in here about ur GIT and CAF merges, i follow u daily but i simply lost overview atm as im still not 100% familiar with CAF. Ur descriptions are really nice, but i cant follow them anymore. I dont want to fork ur repo, because the learning curve would drop to zero if i would do.
Ok first of all i look here for the right release. This would be of course in case of FIND 7 -> LNX.LA.3.2.5-02310-8x74.0 all good so far. Then i simply clone me the this tree. I have now correct caf tree for comparing it with the official find 7 Kernel by OPPO. Ok so far no problems... i diff or meld them together.
First thing i dont understand is why u started at 19th_Dec. Is there a sepcific reason why u did this ?? U apply oppo changes on top top of them, ok i get this, but why from 19th ?? I synced the kernel with yesterdays date and would start from here, but im sure u have ur reasons why... im more then interessted
And where i lost overview:
U created a new branch with 3.5 tag, as far as i understand this is because u will bring the changes up to KK because the LNX.LA.3.2.5-02310-8x74.0 is JB. But why then the oppo_kernel branch anyway, why havent u started with AU_LINUX_ANDROID_KK_3.5.04.04.02.003.298.
Dont get me wrong, i dont want to annoy anyone, i just want to understand how this works and why.. i hope u can shed some light in here, I would really highly appreciate it Thanks in advance
Click to expand...
Click to collapse
Let me pitch in here
That specific CAF tag was the starting point for the source that Oppo used for their kernel base. So using that clean source he can compare to Oppo modified source.
kristofpetho said:
Let me pitch in here
That specific CAF tag was the starting point for the source that Oppo used for their kernel base. So using that clean source he can compare to Oppo modified source.
Click to expand...
Click to collapse
- Starting point: LNX.LA.3.2.5-02310-8x74.0 all clear
- but why reseting it to Dec.19th and merge in changes from oppo kernel that was released in april ?
- and why then jumping into KK AU_LINUX_ANDROID_KK_3.5.04.04.02.003.298 ?? and apply changes again ??
thats what i dont get... im sure its a brain bug on my side but whats the benefit of merging first into JB and then jump onto KK ? is it just it merges nicer if u first apply it on JB ?
n3ocort3x said:
- Starting point: LNX.LA.3.2.5-02310-8x74.0 all clear
- but why reseting it to Dec.19th and merge in changes from oppo kernel that was released in april ?
- and why then jumping into KK AU_LINUX_ANDROID_KK_3.5.04.04.02.003.298 ?? and apply changes again ??
thats what i dont get... im sure its a brain bug on my side but whats the benefit of merging first into JB and then jump onto KK ? is it just it merges nicer if u first apply it on JB ?
Click to expand...
Click to collapse
Dec. 19th is the CAF tag Oppo started from.
I set up directories something like this:
gitrepos/f7kernel which had Oppo's original source
gitrepos/msm which had a cloned repo of CAF's kernel/msm
gitrepos/checktag.sh as below:
Code:
#!/bin/bash
git reset --hard HEAD
git clean -f -d
git checkout $1
cp -R ../f7kernel/* .
git diff >../$1.patch
Then I started checking CAF tags from https://www.codeaurora.org/xwiki/bin/QAEP/release that matched msm8974 (the chip in the find7) and 04.03.00 (the Android revision that Oppo's firmware was released with - just as a warning, SOMETIMES an OEM can use a CAF tag from an older Android release. This was common with the Google Play Edition devices - most of them were released with 4.4 but were using 4.3 CAF tags for hardware support)
The smallest diff resulting from above was the tag with the closest match, which is LNX.LA.3.2.5-02310-8x74.0 (Meaning Oppo took a CAF baseline on Dec. 19, and started their work on bringing up the Find 7a from there, finishing in April. It's typical to see CAF tags 3-6 months earlier than a kernel source release.)
If you check out tag LNX.LA.3.2.5-02310-8x74.0, the most recent commit will be Dec. 19
Then I started splitting up the differences between that TAG and Oppo's sources. The process is something along the lines of
Code:
git reset HEAD^ directory/to/split/out
git commit --amend
git add directory/to/split/out
git commit
Then use git rebase -i to put the "big" patch as the most recent one in order to keep carving chunks off of it
That gets you the nice diffchunked oppo_kernel branch - in that phase I'm not merging, I'm splitting
From there, I took each patch, reviewed it, and determined if I even wanted to apply the changes. In most cases I did, but I didn't pull in Oppo's filesystem changes
Then I applied each patch on top of AU_LINUX_ANDROID_KK_3.5.04.04.02.003.298 , which is Qualcomm's latest tag on the kk_3.5 branch, which seems to be their "standard" tree for MSM8974 and MSM8226 devices (Qualcomm branching strategy can sometimes be really confusing...) Some applied cleanly, others needed significant manual effort to merge them properly.
End result: Oppo Find 7a device-specific support applied on top of Qualcomm's latest KitKat CAF tag
Entropy512 said:
Dec. 19th is the CAF tag Oppo started from.
I set up directories something like this:
gitrepos/f7kernel which had Oppo's original source
gitrepos/msm which had a cloned repo of CAF's kernel/msm
gitrepos/checktag.sh as below:
Code:
#!/bin/bash
git reset --hard HEAD
git clean -f -d
git checkout $1
cp -R ../f7kernel/* .
git diff >../$1.patch
Then I started checking CAF tags from https://www.codeaurora.org/xwiki/bin/QAEP/release that matched msm8974 (the chip in the find7) and 04.03.00 (the Android revision that Oppo's firmware was released with - just as a warning, SOMETIMES an OEM can use a CAF tag from an older Android release. This was common with the Google Play Edition devices - most of them were released with 4.4 but were using 4.3 CAF tags for hardware support)
The smallest diff resulting from above was the tag with the closest match, which is LNX.LA.3.2.5-02310-8x74.0 (Meaning Oppo took a CAF baseline on Dec. 19, and started their work on bringing up the Find 7a from there, finishing in April. It's typical to see CAF tags 3-6 months earlier than a kernel source release.)
If you check out tag LNX.LA.3.2.5-02310-8x74.0, the most recent commit will be Dec. 19
Then I started splitting up the differences between that TAG and Oppo's sources. The process is something along the lines of
Code:
git reset HEAD^ directory/to/split/out
git commit --amend
git add directory/to/split/out
git commit
Then use git rebase -i to put the "big" patch as the most recent one in order to keep carving chunks off of it
That gets you the nice diffchunked oppo_kernel branch - in that phase I'm not merging, I'm splitting
From there, I took each patch, reviewed it, and determined if I even wanted to apply the changes. In most cases I did, but I didn't pull in Oppo's filesystem changes
Then I applied each patch on top of AU_LINUX_ANDROID_KK_3.5.04.04.02.003.298 , which is Qualcomm's latest tag on the kk_3.5 branch, which seems to be their "standard" tree for MSM8974 and MSM8226 devices (Qualcomm branching strategy can sometimes be really confusing...) Some applied cleanly, others needed significant manual effort to merge them properly.
End result: Oppo Find 7a device-specific support applied on top of Qualcomm's latest KitKat CAF tag
Click to expand...
Click to collapse
man i cant thank u enough for this aweseome description many many thanks. that helped me a lot
Hi,
I have a problem on building Firefox OS v1.4 for Samsung S2. I followed the guide https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS. In particular, by following the guide https://developer.mozilla.org/en-US/Firefox_OS/Building when I typed ./build.sh -j1 I got the following error
Code:
including device/samsung/galaxys2/vendorsetup.sh
============================================
PLATFORM_VERSION_CODENAME=AOSP
PLATFORM_VERSION=4.0.4.0.4.0.4
TARGET_PRODUCT=full_galaxys2
TARGET_BUILD_VARIANT=eng
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
HOST_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.13.0-34-generic-x86_64-with-Ubuntu-14.04-trusty
HOST_BUILD_TYPE=release
BUILD_ID=OPENMASTER
OUT_DIR=out
============================================
Blob setup script has changed, re-running
Pulling files from device
Your device has unknown firmware JZO54K.I9100XXLSJ
Supported firmware:
UHLPE
XXLPQ
ZSLPF
XWLP7
BGLP8
BGLP9
ZSLPG
XWLPD
XWLPI
> Build failed! <
Build with |./build.sh -j1| for better messages
If all else fails, use |rm -rf objdir-gecko| to clobber gecko and |rm -rf out| to clobber everything else.
How can I change the firmware? Thank you
feherneoh said:
Flash one of those stock firmwares on you phone, pull files, restore current ROM
Click to expand...
Click to collapse
If I'm not wrong the firmware I9100XXLSJ is JB while all the other are ICS. Is it right?
After installing cyanogenmod 11 m9 my current firmware is cm_i9100-userdebug 4.4.4 KTU84Q 3d3708c0fb test-keys
Currently on hold due to working on Nougat first.
I've got a booting or should I say bootlooping build of Lineage 15.0 for I9000. (galaxysmtd)
I've had to use crazy hacks like adb binary from 7.1 in ramdisk.
Just to get `adb logcat` working.
For now it's stuck at bootlogo. I've attached the logcat here.
I'm looking into it to figure out what needs to be done.
Sources:
manifests and patches I've used.
https://github.com/galaxys1-resurrected/local_manifests
https://github.com/galaxys1-resurrected/android_patches
Kernel:
https://github.com/galaxys1-resurrected/android_kernel_samsung_aries
Device Tree:
https://github.com/galaxys1-resurrected/android_device_samsung_aries-common
https://github.com/galaxys1-resurrected/android_device_samsung_galaxysmtd
Thanks:
@rINanDO for backporting kernel side of things to 3.0
@xc-racer99 and @Coldwindofnowhere for getting the device upto android 7.1
And all others who had worked from beginning till now on this device.
Is there anyone still working on this?
I was curious if anyone this was still being developed? I'm totally newbie in the android scene but have some knowledge of operating systems and am interested in resurrecting my i9000.
I went through the logs and a couple of things jumped out:
1) Surface flinger returning non zero exit status because it needs OpenGL ES v2.0 or greater. I believe i9000's GPU PowerVR SGX540 supports OpenGL ES 2.0, so this issue could be solved.
2) Media extractor crash: /system/bin/mediaextractor: libminijail[1291]: prctl(PR_SET_NO_NEW_PRIVS): Invalid argument, whatever the heck it means.
3) activity_recognition HAL is deprecated, so ActivityRecognitionHardware class's init does not do anything.
For 3 , I got to android_hardware_location_ActivityRecognitionHardware.cpp's source where it comments out activity_recognition.h with the following comment:
Code:
// #include <hardware/activity_recognition.h>
// The activity recognition HAL is being deprecated. This means -
// i) Android framework code shall not depend on activity recognition
// being provided through the activity_recognition.h interface.
// ii) activity recognition HAL will not be binderized as the other HALs.
I believe more work has been done since this post based on git commits lasting upto Nov'17. Would be great if someone could post logs for an updated build. I feel that android oreo with go optimizations would be a really good fit for i9000 and uphold this device's legendary support. I mean a device running from eclair all the way to oreo would be amazing.
Even if this might not work out, I would like to thank @(°_o), @xc-racer99 , @Coldwindofnowhere and @rINanDO for bringing i9000 upto nougat. I believe even i9000's nexus sibling nexus s does not have a working nougat rom.
a1shakes said:
I was curious if anyone this was still being developed? I'm totally newbie in the android scene but have some knowledge of operating systems and am interested in resurrecting my i9000.
I went through the logs and a couple of things jumped out:
1) Surface flinger returning non zero exit status because it needs OpenGL ES v2.0 or greater. I believe i9000's GPU PowerVR SGX540 supports OpenGL ES 2.0, so this issue could be solved.
2) Media extractor crash: /system/bin/mediaextractor: libminijail[1291]: prctl(PR_SET_NO_NEW_PRIVS): Invalid argument, whatever the heck it means.
3) activity_recognition HAL is deprecated, so ActivityRecognitionHardware class's init does not do anything.
For 3 , I got to android_hardware_location_ActivityRecognitionHardware.cpp's source where it comments out activity_recognition.h with the following comment:
Code:
// #include <hardware/activity_recognition.h>
// The activity recognition HAL is being deprecated. This means -
// i) Android framework code shall not depend on activity recognition
// being provided through the activity_recognition.h interface.
// ii) activity recognition HAL will not be binderized as the other HALs.
I believe more work has been done since this post based on git commits lasting upto Nov'17. Would be great if someone could post logs for an updated build. I feel that android oreo with go optimizations would be a really good fit for i9000 and uphold this device's legendary support. I mean a device running from eclair all the way to oreo would be amazing.
Even if this might not work out, I would like to thank @(°_o), @xc-racer99 , @Coldwindofnowhere and @rINanDO for bringing i9000 upto nougat. I believe even i9000's nexus sibling nexus s does not have a working nougat rom.
Click to expand...
Click to collapse
Unfortunately, no one is really actively working on Oreo. As you've found out, it's an issue with the graphics drivers that is holding everything back. No device (that I've found) that uses a PowerVR graphics chip (we use the PowerVR SGX 540) has working graphics drivers on Oreo. There were rumours that someone had found newer working blobs, but weren't able to release them publicly due to intellectual property laws that they were trying to figure out (but this was months ago).
Our GPU does support sufficient enough OpenGL, but only using BGRA8888 as opposed to RGBA8888. BGRA hasn't officially been supported in Android since ~4.2, but there's been a hack used to make things work. Come Oreo, things have changed and the hack no longer applies cleanly. However, I think the really issue is that the gralloc blobs was extended by PowerVR (see https://github.com/xc-racer99/andro...6.0/exynos3/s5pc110/include/hal_public.h#L119) but with the binderized HALs/VNDK/other low-level Oreo changes something has broken. I had a go at trying to work around things, but failed too.
There are a few ways I can think of getting working graphics:
1) Someone finds some updated blobs for the PowerVR SGX 540 for ARM (I've found x86 ones, but they don't work for obvious reasons)
2) Someone hacks around the source code so that the blobs work - but I'm not sure if it's PowerVR "extension" of the gralloc interface that is causing issues or not...
3) We simply use software rendering, but this would be so slow with our ancient CPU that I haven't bothered to try
4) We work on porting a newer kernel so we have the Samsung DRM kernel driver, use the Linux PowerVR blobs coupled with drm_gralloc/drm_hwcomposer and maybe a wrapper like https://github.com/TexasInstruments/dri3wsegl and somehow cobble together working support
In terms of the mediaextractor crash, that's due to the kernel missing seccomp support. There's a whole bunch of different backports, some more successful than others. Due to our ancient kernel, backporting is no longer very easy...
If we could somehow get the graphics drivers working, we'd have a pretty good base as there are free implementations of all HALs/drivers except for GPS and TV-Out (and, of course, graphics....).
Are you really working on porting oreo on the i9000?
How do you deal with the small amount of ram?
Are you using the 'low end device' oreo feature?
nailyk said:
Are you really working on porting oreo on the i9000?
How do you deal with the small amount of ram?
Are you using the 'low end device' oreo feature?
Click to expand...
Click to collapse
No, no one (that I know of) is actively working on Oreo for the first-gen Galaxy S devices. There were attempts, the kernel got in good enough shape that everything wasn't immediately crashing, but due to the graphics driver issues described a couple posts ago nobody has managed to get a fully booting build.
xc-racer99 said:
No, no one (that I know of) is actively working on Oreo for the first-gen Galaxy S devices. There were attempts, the kernel got in good enough shape that everything wasn't immediately crashing, but due to the graphics driver issues described a couple posts ago nobody has managed to get a fully booting build.
Click to expand...
Click to collapse
Thanks for fast anwser. Yes, the graphic driver problem exist on another of my exynos device.
Anyway I wasn't able to boot the 7.1 (not able to boot something else than 2.3.6 )
Will attempt to see that post you are talking about but am probably not smart enough to deal with graphics drivers
Thanks for your time.
nailyk said:
Thanks for fast anwser. Yes, the graphic driver problem exist on another of my exynos device.
Anyway I wasn't able to boot the 7.1 (not able to boot something else than 2.3.6 )
Will attempt to see that post you are talking about but am probably not smart enough to deal with graphics drivers
Thanks for your time.
Click to expand...
Click to collapse
If you're serious about trying to mess with graphics drivers, it might be interesting to check out the blobs from https://www.renesas.com/pt-br/produ...ion-boards/renesas-starter-kit-for-rzg1e.html as it's an ARM-based device with the SGX540. It's possible that they're new enough to not run into the same issues as the older blobs (but equally possible that even the kernel part is closed source). The binary blobs are only semi-SoC specific as I've managed to use the OMAP blobs with only having hardware decoding being broken.
Is it for real???
I9000 !!
Apparently, some new SGX540 and SGX544 DDK blobs for OMAP4 have appeared:
https://gerrit.unlegacy-android.org/#/c/Unlegacy-Android/proprietary_vendor_ti/+/10525/
https://gerrit.unlegacy-android.org/#/q/topic:omap-ddk-1.14+(status:open+OR+status:merged
In fact, (Barnes and Noble's) hummingburd and ovation are both based on SGX544 and have gotten an Oreo ROM (using the new blobs).
https://forum.xda-developers.com/showpost.php?p=77526206&postcount=2490
Use android go it will be better.
MYEUHD said:
Apparently, some new SGX540 and SGX544 DDK blobs for OMAP4 have appeared:
https://gerrit.unlegacy-android.org/#/c/Unlegacy-Android/proprietary_vendor_ti/+/10525/
https://gerrit.unlegacy-android.org/#/q/topic:omap-ddk-1.14+(status:open+OR+status:merged
In fact, (Barnes and Noble's) hummingburd and ovation are both based on SGX544 and have gotten an Oreo ROM (using the new blobs).
https://forum.xda-developers.com/showpost.php?p=77526206&postcount=2490
Click to expand...
Click to collapse
Yep, I've seen the blobs, they've been there for awhile now. Just haven't had a chance to run a build with the blobs to see if they work. It's on my to-do list when I find the time
xc-racer99 said:
Yep, I've seen the blobs, they've been there for awhile now. Just haven't had a chance to run a build with the blobs to see if they work. It's on my to-do list when I find the time
Click to expand...
Click to collapse
Alright, I've had a chance to look at the blobs now. I have a build, but unfortunately it looks as if we need to adjust our hwcomposer as well We use a relatively old hwc 1.0 but the new gralloc blob doesn't appear to keep the framebuffer open which is a requirement for a hwcomposer this old. There is a prebuilt blob that is used by omap4 devices but it doesn't work on s5pc110 due to the fact that it uses some DSS stuff which is OMAP-specific. Still plenty of work to do, without even trying to figure out all the Oreo/Pie changes (I'm testing on KitKat as that's the build environment I have setup right now).
xc-racer99 said:
Alright, I've had a chance to look at the blobs now. I have a build, but unfortunately it looks as if we need to adjust our hwcomposer as well We use a relatively old hwc 1.0 but the new gralloc blob doesn't appear to keep the framebuffer open which is a requirement for a hwcomposer this old. There is a prebuilt blob that is used by omap4 devices but it doesn't work on s5pc110 due to the fact that it uses some DSS stuff which is OMAP-specific. Still plenty of work to do, without even trying to figure out all the Oreo/Pie changes (I'm testing on KitKat as that's the build environment I have setup right now).
Click to expand...
Click to collapse
We need a newer hwc anyway, as Pie requires at least hwc 1.3:
ChronoMonochrome said:
In 9.0, to get graphics to work, device is required to support HWC2 (or use either HWC2on1 or HWC2onFb adapters).
Click to expand...
Click to collapse
ChronoMonochrome said:
Yes, HWC has to be at least 1.3, to work with one of aforementioned adapters. With one of those adapters it will work like it was HWC 2 (but actually not exactly same).
Click to expand...
Click to collapse
As a reference, the galaxy S3's hwc was updated from 1.0 to 1.4: Thread
hardware/samsung
MYEUHD said:
We need a newer hwc anyway, as Pie requires at least hwc 1.3:
As a reference, the galaxy S3's hwc was updated from 1.0 to 1.4: Thread
hardware/samsung
Click to expand...
Click to collapse
Was unaware of the fact. Are you volunteering to make the patches?
I've uploaded my changes to https://github.com/xc-racer99/proprietary_vendor_samsung/tree/ddk-1.14 https://github.com/xc-racer99/android_hardware_samsung/tree/ddk-1.14 https://github.com/xc-racer99/android_kernel_samsung_aries/tree/ddk-1.14 https://github.com/xc-racer99/android_device_samsung_telusgalaxys4gmtd/tree/ddk-1.14 https://github.com/xc-racer99/android_device_samsung_aries-common/tree/ddk-1.14 but I think this might be the last I work on this as I don't really have the motivation to work on it anymore. Note the patches are against a custom version of Unlegacy Android 4.4 so you'll need to cherry pick the changes to your ROM of choice if desired.
The changes build, the EGL appears to initialize, but I always get
Code:
E/libEGL ( 471): validate_display:254 error 3008 (EGL_BAD_DISPLAY)
And in dmesg:
Code:
[ 8.509291] init: computing context for service '/system/vendor/bin/pvrsrvinit'
[ 8.509601] init: starting 'pvrsrvinit'
...
[ 8.601890] PVR_K: UM DDK-(4081762) and KM DDK-(4081762) match. [ OK ]
...
[ 8.765955] init: process 'pvrsrvinit', pid 99 exited
...
[ 55.560021] PVR_K:(Error): PVRSyncIOCTLCreate: Failed to find unused fd (-24)
[ 55.563491] PVR_K:(Error): PVRSyncIOCTLCreate: Failed to find unused fd (-24)
[ 55.597577] s3cfb s3cfb: [fb0] video memory released
Whether the issue is in the HWC or the gralloc blob that we've stolen from OMAP, I have no idea.
xc-racer99 said:
Was unaware of the fact. Are you volunteering to make the patches?
Click to expand...
Click to collapse
Will try to do my best!
BTW, do I really need jdk-7 to compile kitkat? or does it simply work with jdk-8??
MYEUHD said:
Will try to do my best!
BTW, do I really need jdk-7 to compile kitkat? or does it simply work with jdk-8??
Click to expand...
Click to collapse
You really do need jdk-7... I used the "reference implementation" available at http://jdk.java.net/java-se-ri/7 and made sure the java executables were in the PATH before the java I actually have installed.
Note that my Unlegacy Android trees will not work for the i9000 (well, they might, but you'd need to install u-boot as well at a bare minimum...)
It's kinda Insane that people are trying to get an 8 year phone to run oreo
@xc-racer99 Do you still have the AOSP 7.1 source code on your computer?
MYEUHD said:
@xc-racer99 Do you still have the AOSP 7.1 source code on your computer?
Click to expand...
Click to collapse
I've got the .repo folder, but don't have the individual files expanded as I don't have the disk space Could run a repo sync and look at things but don't have the disk space for a full build.
The_Pacific_gamer said:
It's kinda Insane that people are trying to get an 8 year phone to run oreo
Click to expand...
Click to collapse
its kinda insane that people are still using this phone.