Related
@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
Okay Guys,
I am working hard to bring up Cyanogenmod to our beloved moto g.
But i am a bit Noobish in this field.
I have been reading guides and following the process.
So far I have setup the build environment and synced the latest repo from CM sources.
Now, further most imp step is Vendor, Kernal and Device tree.
I have found this so far, by searching this forum only,
https://github.com/MotorolaMobilityLLC/kernel-msm/tree/kitkat-4.4.4-release-titan
Now, reading further some guides, they say kernel and device tree will require some modification to work with CM12, but i couldnt find about this modification.
so I request all developers to guide me on this.
We can surely do this together. :fingers-crossed:
N.K.V. said:
Okay Guys,
I am working hard to bring up Cyanogenmod to our beloved moto g.
But i am a bit Noobish in this field.
I have been reading guides and following the process.
So far I have setup the build environment and synced the latest repo from CM sources.
Now, further most imp step is Vendor, Kernal and Device tree.
I have found this so far, by searching this forum only,
https://github.com/MotorolaMobilityLLC/kernel-msm/tree/kitkat-4.4.4-release-titan
Now, reading further some guides, they say kernel and device tree will require some modification to work with CM12, but i couldnt find about this modification.
so I request all developers to guide me on this.
We can surely do this together. :fingers-crossed:
Click to expand...
Click to collapse
I love your initiative! Unfortunately I'm not a developer...
Send from my XT1068 using Tapatalk.
nice work mate.... developers are needed urgently....
Why do you think developers will find you and this thread? It works the other way. You need to find developers and ask for help. I suggest you start here and here
I keep my fingers crossed for the success of the project :highfive:
Yes, I am reading all possible guides given by the developers.
By that only i have reach this far.
But for device tree and kernel, device specific modifications are necessary, and I really need help of some one who has actually done this before.
If this is successful , we can have an alpha build of CM 12 , in 3-4 days.
@ N.K.V.
ok i will help you with this..
first we need to set up device tree and vendor trees....
there is 2 ways to do this
first:- get a official motorola stock lollipop update for your phone.
(unfortunately it not yet released for all variants)
examine the similar device trees like falcon or htc a5 (desire 816) of lg l90 or sony m2 or sony e3
compare the kernel sources of falcon and titan (these are kitkat sources so may be in future motorola will release updated lollipop kernel source)
there are various major differences.
set up a basic device tree from falcon with msm8226 common of cm repos.
take vendor blob list from falcon
adapt it for titan
extract vendor blob from phone.
compile the rom
second:- from existing 4.4.4 rom
repo sync kernel from github
make changes to falcon and msm8226 device tree to adapt titan
extract vendor blobs with falcon list
compile
problem with second approach is that you have to make many changes to kernel and other things
but if we get official moto update of lollipop with kernel source then it will be little easier...
still if you are going to compile and want to make a cm12 from 4.4.4 i am with you ...i will set up device trees and other trees to set up things in motion.....
and then we can change vendor blobs and kernel to lollipop when it get released...
k2wl said:
@ N.K.V.
ok i will help you with this..
first we need to set up device tree and vendor trees....
there is 2 ways to do this
first:- get a official motorola stock lollipop update for your phone.
(unfortunately it not yet released for all variants)
examine the similar device trees like falcon or htc a5 (desire 816) of lg l90 or sony m2 or sony e3
compare the kernel sources of falcon and titan (these are kitkat sources so may be in future motorola will release updated lollipop kernel source)
there are various major differences.
set up a basic device tree from falcon with msm8226 common of cm repos.
take vendor blob list from falcon
adapt it for titan
extract vendor blob from phone.
compile the rom
second:- from existing 4.4.4 rom
repo sync kernel from github
make changes to falcon and msm8226 device tree to adapt titan
extract vendor blobs with falcon list
compile
problem with second approach is that you have to make many changes to kernel and other things
but if we get official moto update of lollipop with kernel source then it will be little easier...
still if you are going to compile and want to make a cm12 from 4.4.4 i am with you ...i will set up device trees and other trees to set up things in motion.....
and then we can change vendor blobs and kernel to lollipop when it get released...
Click to expand...
Click to collapse
This is great news. A team effort can do anything.:good:
Thanks to NKV and Kewl. Great initiative. God Bless You.
Sent from my Nexus 7 using XDA Free mobile app
okay guys,
let's keep this thread clean for developers.
you can always hit like to appreciate
UPDATE: @k2wl is working on kernel and device tree, it will take him some days.
@k2wl and N.K.V.
Thx for your time and work :good:
I wait for the right Software on xt1068!
I have a little bit of knowledge and i can learn really fast, if you guys need help, you can count on me
which model will this be for? (please say xt1064)
Bobboman said:
which model will this be for? (please say xt1064)
Click to expand...
Click to collapse
Doesn't matter. It will be for all variants!
absolutely brilliant, i wish i knew a lick of programming so that i could help get this done faster (i'm tired of seeing a SU update in play store and not being able to use it because it sends my G into a bootloop)
Thanks man, lollipop official update have a bug while playing music via bluetooth when screen is lock, can you fix it on this rom?
Ha ha...Let's make the ROM first..
Bug fixing in Second task.
Now that lollipop soak has started in India....i think Work should go fast. :beer:
Waiting for it. Please keep updated though!
I'm interested in helping with this.
Sent from my A0001 using XDA Free mobile app
Hope to See this soon! Thanks guys!!
Nice intitiative...but i think making device tree and vendor for this device will not be tht easy....still hope for best
Source: https://blogs.sonymobile.com/2017/08/31/xperia-android-8-0-oreo/
Got nearly 2 years of updates, but not quite.
On a related note, official XZ1 Compact website is up. I'm thinking about getting one for my wife to replace her Z5C, UFS sounds delicious.
The list of devices in the blog is not final and it is possible that we will see Oreo on our device.
Even though stock will not support Oreo, Custom firmwares will usually always outlast stock
(Lineage and Carbon are using stock blobs on the Z5 Lineup so custom roms are nearly the same quality, if not better, then stock anyway)
nzzane said:
Even though stock will not support Oreo, Custom firmwares will usually always outlast stock
(Lineage and Carbon are using stock blobs on the Z5 Lineup so custom roms are nearly the same quality, if not better, then stock anyway)
Click to expand...
Click to collapse
I was wondering about this myself. Are the stock blobs sdk version specific, so in order to make a custom Oreo rom a stock Oreo ftf is needed first? Or should the nougat blobs potentially be used in an Oreo firmware? Same with hardware drivers that are unique to our device, like WiFi?
cyberwytch said:
I was wondering about this myself. Are the stock blobs sdk version specific, so in order to make a custom Oreo rom a stock Oreo ftf is needed first? Or should the nougat blobs potentially be used in an Oreo firmware? Same with hardware drivers that are unique to our device, like WiFi?
Click to expand...
Click to collapse
From memory, as long as the source is configured right it should be fine (Wifi drivers shouldn't be changing as its still the same hardware, same for screen and all) - Carbonrom and Lineage source are currently being updated to Oreo, along with some of the sony files being configured for it so hopes are high.
nzzane said:
From memory, as long as the source is configured right it should be fine - Carbonrom and Lineage source are currently being updated to Oreo, along with some of the sony files being configured for it so hopes are high.
Click to expand...
Click to collapse
Awesome sauce! I love your Lineage 14, can't wait to see what's next!
nzzane said:
Even though stock will not support Oreo, Custom firmwares will usually always outlast stock
(Lineage and Carbon are using stock blobs on the Z5 Lineup so custom roms are nearly the same quality, if not better, then stock anyway)
Click to expand...
Click to collapse
That's awesome news, I'll add "official" to the thread title for clarification.
They said it was because Qualcomm aren't great at after market support.
so we couldn't get 3.18, but, what would be interesting to do would be to make some interface to act like a middle man.
I'm currently doing something similar for my laptop running Server 2016, and am slowly making it run like a Desktop OS, by enabling all the other stuff left out that I can find
---------- Post added at 16:25 ---------- Previous post was at 16:21 ----------
nzzane said:
...
Click to expand...
Click to collapse
which linux kernel is LOS running?
NeoBeum said:
They said it was because Qualcomm aren't great at after market support.
so we couldn't get 3.18,
Click to expand...
Click to collapse
Where was this said, and why would we need 3.18 for the Z5 family?
A lot of the reporting being done on this has been bad (whatever happened to reading comprehension, especially in reporters??). According to the source being cited, only SoCs produced prior to 2017 (which the Snapdragon 810 is) AND that are being launched in new devices (which the Z5 series is NOT) are required to run on 3.18. Existing devices already designed and sold before the launch of Oreo (which, having launched in 2015, I think the Z5 family would qualify as) "can continue to use their original base kernel version if desired."
-- Nathan
nlra said:
Where was this said, and why would we need 3.18 for the Z5 family?
A lot of the reporting being done on this has been bad (whatever happened to reading comprehension, especially in reporters??). According to the source being cited, only SoCs produced prior to 2017 (which the Snapdragon 810 is) AND that are being launched in new devices (which the Z5 series is NOT) are required to run on 3.18. Existing devices already designed and sold before the launch of Oreo (which, having launched in 2015, I think the Z5 family would qualify as) "can continue to use their original base kernel version if desired."
-- Nathan
Click to expand...
Click to collapse
on github somewhere,
actually, ask and tag greyleshy, he was the one that asked about final kernel for us, and I found the convo somewhere trying to get Bluetooth junk sorted
there might be some msm8994 thing that sony needs but cant use for oreo or something. I dont know
NeoBeum said:
on github somewhere,
actually, ask and tag greyleshy, he was the one that asked about final kernel for us, and I found the convo somewhere trying to get Bluetooth junk sorted
there might be some msm8994 thing that sony needs but cant use for oreo or something. I dont know
Click to expand...
Click to collapse
Hmm, 'k; thanks. I'll do some more digging. But if true this would flatly contradict Google's own public statements (though I realize it's not like this would be a first for that kind of thing).
-- Nathan
NeoBeum said:
They said it was because Qualcomm aren't great at after market support.
so we couldn't get 3.18, but, what would be interesting to do would be to make some interface to act like a middle man.
Click to expand...
Click to collapse
Android Oreo supports Kernel 3.10, but need to patch the kernel (example: patch 1, patch 2).
It would be nice if msm8994 supported kernel 3.18 or 4.4, but it is not.
Apparently QCOM has not provided drivers for 3.18+ and therefore CodeAurora kernel was not released because of compatibility issues.
NeoBeum said:
which linux kernel is LOS running?
Click to expand...
Click to collapse
3.10, CAF kernel
nlra said:
Where was this said, and why would we need 3.18 for the Z5 family?
A lot of the reporting being done on this has been bad (whatever happened to reading comprehension, especially in reporters??). According to the source being cited, only SoCs produced prior to 2017 (which the Snapdragon 810 is) AND that are being launched in new devices (which the Z5 series is NOT) are required to run on 3.18. Existing devices already designed and sold before the launch of Oreo (which, having launched in 2015, I think the Z5 family would qualify as) "can continue to use their original base kernel version if desired."
-- Nathan
Click to expand...
Click to collapse
correct,
actually 4.4 kernel, it's only needed for newer SoCs
so we can go on with 3.10 kernel for now but we need to wait for (potential) CAF changes
GreyLeshy said:
Android Oreo supports Kernel 3.10, but need to patch the kernel (example: patch 1, patch 2).
It would be nice if msm8994 supported kernel 3.18 or 4.4, but it is not.
Apparently QCOM has not provided drivers for 3.18+ and therefore CodeAurora kernel was not released because of compatibility issues.
Click to expand...
Click to collapse
well, there's still Linux mainline / vanilla upstream support for msm8994 since 4.10 kernel in a very rough state with terminal only (AOSP)
and there's the (close to complete) bringup of msm8994 on 3.18 kernel sauce: https://github.com/sonyxperiadev/kernel/pull/972 (for AOSP)
yeah I basically read it as qualcomm have bad after market support
zacharias.maladroit said:
and there's the (close to complete) bringup of msm8994 on 3.18 kernel sauce: https://github.com/sonyxperiadev/kernel/pull/972 (for AOSP)
Click to expand...
Click to collapse
I might have something interesting to build then and I can stop lounging around
any news for official aosp 8.0 release for z5?
Enviado desde mi SGP712 mediante Tapatalk
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.
Hello
For the past couple (weeks) I've been trying to compile Android 10 for tenderloin using the Android 9 sources but it's not going so well. First thing I ran into multiple sepolicy errors and I feel as if I fixed them in inappropriate ways but the errors went away. Other errors regarding camera and audio and such, that are regarding that tenderloin no longer uses the legacy audio format. Made me confused because I used the device sources form Evervolv and DIrty unicorns and if i'm correct they built it exactly the same way they uploaded it. After these errors were wrapped up, I got a error at zipping the rom that it could not zip due to failure of being able to read build.prop. This made me believe that the sources are not correctly formatted. If anyone can help me find a manifest, I can build for all you guys. Please keep tenderloin alive!
Now, I did something and I'm getting plenty of perl errors. Maybe I'm just very unlucky. I'm gonna attempt to reinstall on a fresh drive on my server.
If its anyone's concern, I was building lineage 17.1. I noticed for example, Lineage's "qcom-device" repo was shaped completely differently than Evervolvs qcom-device repo.
This led me to thought that Android 10 is going to be extremely difficult because of all the upstream dev changes that was pushed to Q. If any of you would like, I could probably push out March patches Pie rom because over there I'm mostly safe of complying with the source.
My manifest shape
DirtyUnicorn's device-tree
DirtyUnicorn's device-tree-common
DirtyUnicorn's htc-msm8960-kernel
Evervolv's vendor
And dirty unicorn's atheros wlan driver
I have been changing up the device tree so much, it almost looks ridiculous . From what I heard lots of properties on the device tree haven't been touched for years. Maybe tomorrow I can try Evervolv's Q rom. If you guys can help me build up my manifest, we can push out a fully working Q rom for tenderloin. And it would be just in time when Android 11 comes out. Thank you everyone!
I wish that I could offer any help, but I never tried to compile any Android ROM or for the HP_TP.
To my knowledge the only users that I know that could offer some insight on the process would be:
@flintman
@elginsk8r
Also the LuneOS project could offer some help:
https://pivotce.com/tag/luneos/
If Android Q(10) can not be ported to the HP_TP, then at least P(9) is a good ROM to keep updating that could provide many years of App support.
Theres no reason why exactly it cant,, because lots of roms I hear were built off the original TP sources (From 2011!). It was only around 2016 when guys around here had to change it up so much that they should've been so surprised that it worked. I can try and temporarily maintain P roms until the boys around here push out sources for Q!
djared704 said:
Theres no reason why exactly it cant,, because lots of roms I hear were built off the original TP sources (From 2011!). It was only around 2016 when guys around here had to change it up so much that they should've been so surprised that it worked. I can try and temporarily maintain P roms until the boys around here push out sources for Q!
Click to expand...
Click to collapse
To my limited knowledge is all about Hardware -->> Drivers -->> ( Kernel ).
The reason that Bluetooth and camera does not work on newer Android version is due to the old (proprietary drivers) and the Kernel. That takes more dedication and work than the ROM. The same rules applies to the desktop, older processors does not support certain features and the Operating System will not run. It is possible to disable the features in the kernel so that it does not check the hardware and make it run, but it will be unstable.
Everything could be possible with plenty of time, knowledge and dedication.
HP_TOUCHPAD said:
To my limited knowledge is all about Hardware -->> Drivers -->> ( Kernel ).
The reason that Bluetooth and camera does not work on newer Android version is due to the old (proprietary drivers) and the Kernel. That takes more dedication and work than the ROM. The same rules applies to the desktop, older processors does not support certain features and the Operating System will not run. It is possible to disable the features in the kernel so that it does not check the hardware and make it run, but it will be unstable.
Everything could be possible with plenty of time, knowledge and dedication.
Click to expand...
Click to collapse
When I look at the tenderloin source, the script to gather the camera driver is disabled. Camera isnt a huge deal though because its only 1.3 MP. However we use the MSM 8960 kernel from HTC and that is the one m7,, but the one m7 is a SD 600 device so it loses sense. I was gonna get some help with one of my kernel developer buddies to dev a kernel for android 10 for tenderloin. If you see the one m7 has Lineage 17.1 available and even though it doesnt have same chipset, if im correct both chipsets went off of the same assembly line process. Lineage 17.1 for the one m7 also packages it as a "uimage" which is what we use. I believe this was only a very small select of devices. Yeah about that ive been getting so many complaints during build about "mkimage" which should've been a prebuilt tool in the lineage source. Don't know why they removed it, or if our developers added it in by their selves, etc. Anyways I fixed that error by just "allowing" mkimage in one of the permission files in my environment. But yeah i went as far as the build packaging the ROM and it complaining it cannot read build.prop. Note the build.props are generated by the environment , not the source (even though the device data is gathered by the source, its not what im talking about). I even go to the directory it was complaining about and it was all there. One of my friends suggested a permission error. I changed permissions to 777 (rw to all users) and it would still output that error. By that point I trashed my build meaning I may of done something wrong early on. I will let someone else continue building 10 but I will continue building 9 with latest patches.
It will be extremely impressive if any kernel developer will update the HP Touchpad Kernel or tweak it for future release, well everything will stop once Android becomes 64 only.
I am sure you are very well aware, but I will suggest using this built:
https://forum.xda-developers.com/hp-touchpad/development/rom-evervolv-hp-touchpad-t3923512
I was able to do the following playing around recompiling the Kernel. I recompile almost all the ROM and incorporated the same kernel changes.
https://forum.xda-developers.com/hp-touchpad/general/hp-touchpad-optimize-android-swap-t3901773
The Ramdisk is also very easy to unpack and repack:
https://forum.xda-developers.com/hp-touchpad/general/hp-touchpad-novacom-repair-android-t3960435
There is no need to get the original Camera or Bluetooth working, only sound and WiFi.
HP_TOUCHPAD said:
It will be extremely impressive if any kernel developer will update the HP Touchpad Kernel or tweak it for future release, well everything will stop once Android becomes 64 only.
I am sure you are very well aware, but I will suggest using this built:
https://forum.xda-developers.com/hp-touchpad/development/rom-evervolv-hp-touchpad-t3923512
I was able to do the following playing around recompiling the Kernel. I recompile almost all the ROM and incorporated the same kernel changes.
https://forum.xda-developers.com/hp-touchpad/general/hp-touchpad-optimize-android-swap-t3901773
The Ramdisk is also very easy to unpack and repack:
https://forum.xda-developers.com/hp-touchpad/general/hp-touchpad-novacom-repair-android-t3960435
There is no need to get the original Camera or Bluetooth working, only sound and WiFi.
Click to expand...
Click to collapse
I think I probably stated somewhere, but Evervolvs "device" tree would just spit out hundreds of errors, and I fixed this by switching to Dirty Unicorns device tree. I also tried flintman's device tree and it didn't spit out many errors. Thanks for this though.
djared704 said:
I think I probably stated somewhere, but Evervolvs "device" tree would just spit out hundreds of errors, and I fixed this by switching to Dirty Unicorns device tree. I also tried flintman's device tree and it didn't spit out many errors. Thanks for this though.
Click to expand...
Click to collapse
I have only recompile the Kernel and all of them work, but the correct branch must be use. I can not say about building a ROM, never done it.
But Evervovs Pie by elginsk8r works very well and stable as it uses the same kernel, but the framework is different. I guess elginsk8r will be the only that can guide you on the right direction or flintman.
Have fun learning, it takes a lot of TIME!