CAF/GIT Find7 bringup

Search This thread

n3ocort3x

Senior Member
May 10, 2012
5,859
10,822
Vienna
@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
 
  • Like
Reactions: k5t4j5

kristofpetho

Senior Member
May 27, 2009
5,195
10,033
Zoetermeer
@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

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.
 

n3ocort3x

Senior Member
May 10, 2012
5,859
10,822
Vienna
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.

- 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 ?
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
- 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 ?

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
 
Last edited:

n3ocort3x

Senior Member
May 10, 2012
5,859
10,822
Vienna
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

man i cant thank u enough for this aweseome description :) many many thanks. that helped me a lot :)
 

Top Liked Posts

  • There are no posts matching your filters.
  • 9
    - 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 ?

    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
    1
    @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