Difference between revisions of "RZ-G/BSP upgrade"

From eLinux.org
Jump to: navigation, search
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
To migrate from one VLP version to the following, the best would be to rebase.
+
To migrate from one VLP version to a newer one, the best method would be to rebase your custom patches on top of the latest VLP verison.
  
For example Renesas VLP includes the CIP kernel. However CIP and our kernel follow different paths and when a new version of the VLP is released, a set of patches are then applied to the version chosen:
+
For example, let's refer to the CIP kernel included in the Renesas VLP BSP.  
 +
While the Renesas BSP is based off the CIP kernel, additional patches are added for each VLP release. This causes the update path to be a little complex.
  
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
Line 7: Line 8:
 
           o--o--o '''vlp64_v104'''          o--o--o--o '''vlp64_v105'''      o--o--o--o--o '''vlp64_v106'''         
 
           o--o--o '''vlp64_v104'''          o--o--o--o '''vlp64_v105'''      o--o--o--o--o '''vlp64_v106'''         
  
But customers have probably started working on one version, created their own branch and applied their own modifications:  
+
We will assume that users have probably started working on one version, and have created their own branch to applied their own modifications:  
  
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
Line 13: Line 14:
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v106
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v106
 
                 '''\'''                                                           
 
                 '''\'''                                                           
                   '''A--B--C customer_v1'''                     
+
                   '''A--B--C release_v1'''                     
 
                         '''\'''                                   
 
                         '''\'''                                   
                           '''D customer_v2'''                       
+
                           '''D release_v2'''                       
  
Now, at certain point in time, if the customer wants to move to a new VLP version, for example 1.0.5, then the solution for them is to rebase, basically a sort of "move" of their modifications to the newer VLP:
+
Now, at certain point in time, if the user wants to move to a new VLP version, for example 1.0.5, then the solution for them is to do a "rebase" which is basically a sort of "move" of their modifications to the newer VLP. When the move, the can also combine old branches into a single branch.
  
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
Line 23: Line 24:
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v106
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v106
 
                 \                              '''\'''                             
 
                 \                              '''\'''                             
                   A--B--C customer_v1            '''A--B--C--D customer_v3'''         
+
                   A--B--C release_v1              '''A--B--C--D release_v3'''         
 
                         \                                  '''\'''                                 
 
                         \                                  '''\'''                                 
                           D customer_v2                      '''E customer_v4'''                     
+
                           D release_v2                      '''E release_v4'''                     
  
 
And so on, for the following versions:
 
And so on, for the following versions:
Line 33: Line 34:
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v10n
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v10n
 
                 \                              \                            '''\'''
 
                 \                              \                            '''\'''
                   A--B--C customer_v1            A--B--C--D customer_v3        '''A--B--C--D--E customer_v5'''
+
                   A--B--C release_v1              A--B--C--D release_v3        '''A--B--C--D--E release_v5'''
 
                         \                                  \                                '''\'''
 
                         \                                  \                                '''\'''
                           D customer_v2                      E customer_v4                   '''F customer_v6'''
+
                           D release_v2                      E releaser_v4                   '''F release_v6'''
  
 
Once rebased, the old branches can sweetly die and new development shall continue on the new branch only.
 
Once rebased, the old branches can sweetly die and new development shall continue on the new branch only.
  
 +
== How to Rebase your changes to a new BSP version ==
 +
 +
=== Create a local git repository of the kernel ===
 
Let us go thru an example using [https://github.com/seebe/rzg_stuff/tree/master/build_scripts Chris' script] that is meant to assist in checking out the relevant CIP kernel code from the repository and apply VLP patches on top.  
 
Let us go thru an example using [https://github.com/seebe/rzg_stuff/tree/master/build_scripts Chris' script] that is meant to assist in checking out the relevant CIP kernel code from the repository and apply VLP patches on top.  
Obviously the script is not strictly required but if not used the user should identify the right CIP kernel version to checkout:
+
Obviously the script is not strictly required but if not used the user should identify the right mainline CIP kernel version to checkout, and then collect all the patches from the VLP version, and then apply those patches. This all needs to be done before the kernel can be build in the exact same way Yocto does in the VLP release.
  
  o--o-'''-o-'''-o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
+
To do that we just have to run the vlp64_util script:
        \                           
+
  ./vlp64_util.sh create k . my_vlp_kernel_repo
          o--o--o vlp64_v104             
+
What VLP64 BSP version do you want?
 
+
0. BSP-1.0.4
And then collect all the patches from the VLP version:
+
1. BSP-1.0.5
 +
2. BSP-1.0.5-RT
 +
3. BSP-1.0.5-RT-update1
 +
4. BSP-1.0.6-update1
 +
choice: 0
 +
The script will then clone the CIP Linux repository and apply the correct Renesas BSP patches, also creating a branch called vlp64_v104.
  
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
         \                             
 
         \                             
           '''o--o--o''' vlp64_v104  
+
           o--o--o vlp64_v104
 +
 
 +
In your git repository, you should already be on branch "vlp64_v104"
  
And apply them before the kernel can be build in the exact same way Yocto does in the VLP release.
+
  git branch
 +
  master
 +
* vlp64_v104
  
To do that we just have to run the vlp64_util script:
+
=== Make some change ===
./vlp64_util.sh create k . my_vlp_kernel_repo
 
What VLP64 BSP version do you want?
 
0. BSP-1.0.4
 
1. BSP-1.0.5
 
2. BSP-1.0.5-RT
 
3. BSP-1.0.5-RT-update1
 
4. BSP-1.0.6-update1
 
choice: 0
 
The script will then clone the repository and apply the correct patches, also creating a branch called vlp64_v104.
 
  
Let us implement some changes to the VLP 1.0.4 release. For example we modift the init/calibrate.c:
+
Let us implement some changes to the VLP 1.0.4 release. For example we modify the init/calibrate.c:
  
 
  void calibrate_delay(void)
 
  void calibrate_delay(void)
Line 82: Line 86:
 
  [...]
 
  [...]
  
Then stage and commit changes:
+
Then we will stage our changes and commit them to the repository.
 +
'''But first''', you should really make a '''new branch''' for your development work, and change to it ("checkout").
 +
Note that your edited source file "calibrate.c" will not be touched.
 +
 
 +
git status
 +
git branch vlp64_v104_dev
 +
git checkout vlp64_v104_dev
 +
git status
 +
 
 +
'''HINT''': You can combine the steps "git branch vlp64_v104_dev" and "git checkout vlp64_v104_dev" to a single step "git checkout -b vlp64_v104_dev"
 +
 
 +
Now our repository looks like this:
 +
 
 +
o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 +
        \                           
 +
          o--o--o vlp64_v104, '''vlp64_v104_dev'''
 +
 
 +
'''HINT''': Use the command "gitk --all " to view this graphically.
 +
 
 +
Now we will add in our change to the repository.
  
 
  git add calibrate.c
 
  git add calibrate.c
 
  git commit -m "calibrate.c - Added some printk statements"
 
  git commit -m "calibrate.c - Added some printk statements"
  
Now we update the repository with a newer VLP:
+
Now our repository will look like this (where "A" is the commit we just added)
 +
o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 +
        \                           
 +
          o--o--o  vlp64_v104
 +
                \
 +
                  A  vlp64_v104_dev
 +
 
 +
 
 +
=== Update the repository with a new BSP release ===
 +
Now we will update the repository with a newer VLP.
  
  ./vlp64_util.sh update my_vlp_kernel_repo
+
  $ ./vlp64_util.sh update my_vlp_kernel_repo
 
  Detected kernel
 
  Detected kernel
 
   
 
   
Line 104: Line 136:
  
 
The script detects that "my_vlp_kernel_repo" already contains a VLP kernel. We select VLP 1.0.5. Then the script will fetch/checkout the appropriate CIP kernel version and apply the patches on top of it:
 
The script detects that "my_vlp_kernel_repo" already contains a VLP kernel. We select VLP 1.0.5. Then the script will fetch/checkout the appropriate CIP kernel version and apply the patches on top of it:
  git branch
+
 
  master
+
  $ git branch
  vlp64_v104
+
  master
 +
  vlp64_v104
 
  * vlp64_v105
 
  * vlp64_v105
 +
 +
o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 +
        \                            \
 +
          o--o--o vlp64_v104          o--o--o--o '''vlp64_v105'''   
 +
                \
 +
                  A  vlp64_v104_dev
  
 
Let's have a look at the tags:
 
Let's have a look at the tags:
Line 119: Line 158:
 
  ..
 
  ..
 
  ..
 
  ..
 +
 +
=== Move your changes to the new BSP release using git rebase ===
  
 
Now let the magic begin.  
 
Now let the magic begin.  
First we may want to create a copy of the old development branch:
+
First we want to create a copy of the current (old) development branch. The 'checkout -b vlp_v105_dev' option will create a new branch for us with the name "vlp_v105_dev".
git checkout vlp64_v104
+
This new branch will be at the same location as the "vlp64_v104" branch. We give this new branch a "v105" name is because we plan to '''move it''' on top of the BSP v1.0.5 release.
git checkout -b vlp_v105_dev
 
  
Then we can move our patch (A = Added some printk statements) to the latest version:
+
git checkout vlp64_v104_dev          <<< change to the branch we added our change in
  '''git rebase --onto BSP-1.0.5 BSP-1.0.4 vlp_105_dev'''
+
  git checkout -b vlp64_v105_dev        <<< make a new branch at the same location
  
This powerful git command needs a bit of explanation: it allows us to transplant the vlp_105_dev branch based on the vlp64_v104 (= BSP-1.0.4) branch, to pretend that we forked the vlp_105_dev branch from the vlp64_v105 (=BSP-1.0.5) branch. Please also have a look at the official git documentation [https://git-scm.com/docs/git-rebase here]. In other words from this:
+
Now we should have this.
 +
You can view with "gitk vlp64_v105_dev".
  
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
         \                            \
 
         \                            \
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105     
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105     
                 \ '''vlp64_v105_dev'''
+
                 \  
                  A            
+
                  A  vlp64_v104_dev, '''vlp64_v105_dev'''
To this:
+
 
 +
 
 +
Then we can move our patch (A = "Added some printk statements") to the latest version:
 +
'''git rebase --onto BSP-1.0.5 BSP-1.0.4 vlp64_105_dev'''
 +
 
 +
This powerful git command needs a bit of explanation: it allows us to transplant the vlp64_105_dev branch based on the vlp64_v104 (= BSP-1.0.4) branch, to pretend that we forked the vlp64_105_dev branch from the vlp64_v105 (=BSP-1.0.5) branch. Please also have a look at the official git documentation [https://git-scm.com/docs/git-rebase here].
 +
 
 +
The result should look like this:
  
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
         \                            \
 
         \                            \
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105     
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105     
                 \                              '''\ vlp64_v105_dev'''
+
                 \                              \
                  A                             '''A
+
                  A vlp64_v104_dev              A vlp64_v105_dev
There is also another possibility: instead of using git rebase we can use [https://git-scm.com/docs/git-cherry-pick git cherry-pick]. This command allows up to copy a single commit or a range of commit from one branch to another.
+
 
 +
Now you are working on the BSP v1.0.5 kernel and you were able to keep your changes that you made in v1.0.4
 +
 
 +
 
 +
== Use Cherry Pick Instead of Rebase ==
 +
 
 +
There is also another possibility: instead of using git rebase we can use [https://git-scm.com/docs/git-cherry-pick git cherry-pick]. This command allows up to copy a single commit or a range of commits from one branch to another.
 
In our example we have to first check the hash of the commit we want to cherry pick:
 
In our example we have to first check the hash of the commit we want to cherry pick:
  
Line 151: Line 205:
  
 
Then checkout the destination branch:
 
Then checkout the destination branch:
git checkout vlp_v105
 
  
And then:
+
  git checkout vlp64_v105
  git cherry-pick f4d5d8172b76
+
 
''[1]''
+
Then make a new branch
  
We can also cherry pick a range of commits:
+
  git checkout -b vlp64_v105_dev
  git cherry-pick git cherry-pick BSP-1.0.4..vlp64_v104
 
  
In our example this is exactly the same as [1] because we have only one commit between vlp64_v104 and BSP-1.0.4. So again, graphically, from this:
+
which will give you this:
  
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
         \                            \
 
         \                            \
           o--o--o vlp64_v104          o--o--o--o vlp64_v105    
+
           o--o--o vlp64_v104          o--o--o--o vlp64_v105, '''vlp64_v105_dev'''
 
                 \  
 
                 \  
                  A            
+
                  A vlp64_v104_dev
To this:
+
 
 +
 
 +
And then ''[1]'':
 +
git cherry-pick f4d5d8172b76
 +
 
 +
We can also cherry pick a range of commits.
 +
In the example below, "BSP-1.0.4" is a tag that shows the end of the Renesas BSP, and "vlp64_v104_dev" is the branch that has has our changes. So basically we are asking it to copy all the changes we made on top of the Renesas BSP.
 +
 
 +
git cherry-pick BSP-1.0.4..vlp64_v104_dev
 +
 
 +
You could also use this command (using branch name instead of tag name)
 +
 
 +
git cherry-pick vlp64_v104..vlp64_v104_dev
 +
 
 +
In our example this is exactly the same as ''[1]'' because we have only one commit between vlp64_v104 and BSP-1.0.4.
 +
So again, graphically, it will end up like this
  
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
  o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
 
         \                            \
 
         \                            \
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105     
 
           o--o--o vlp64_v104          o--o--o--o vlp64_v105     
                 \                              \  
+
                 \                              \
                   A                              A
+
                   A vlp64_v104_dev              A  vlp64_v105_dev
 +
 
 +
'''Note''': When selecting a range of patches, both cherry-pick and rebase "skip" the first patch. If you want to include it, you have to explicitly specify it by adding a ''^''.
 +
For example, let's assume:
 +
 
 +
          o--o--o vlp64_v104          o--o--o--o vlp64_v105   
 +
                \                             
 +
                  A-B-C-D-E                     
 +
 
 +
Now if we want to cherry pick the patches A-B-C-D-E and apply them to vlp64_v105, we can use the command:
 +
 
 +
git cherry-pick A^..E
 +
 
 +
          o--o--o vlp64_v104          o--o--o--o vlp64_v105   
 +
                \                              \
 +
                  A-B-C-D-E                      A-B-C-D-E
 +
 
 +
If instead we do not use "^":
 +
 
 +
git cherry-pick A..E
 +
 
 +
we will end up in having:
 +
 
 +
          o--o--o vlp64_v104          o--o--o--o vlp64_v105   
 +
                \                               \
 +
                  A-B-C-D-E                      B-C-D-E

Revision as of 09:52, 26 February 2021

To migrate from one VLP version to a newer one, the best method would be to rebase your custom patches on top of the latest VLP verison.

For example, let's refer to the CIP kernel included in the Renesas VLP BSP. While the Renesas BSP is based off the CIP kernel, additional patches are added for each VLP release. This causes the update path to be a little complex.

o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                             \                          \
         o--o--o vlp64_v104           o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v106         

We will assume that users have probably started working on one version, and have created their own branch to applied their own modifications:

o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                             \                          \ 
         o--o--o vlp64_v104           o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v106
                \                                                          
                 A--B--C release_v1                    
                        \                                  
                         D release_v2                      

Now, at certain point in time, if the user wants to move to a new VLP version, for example 1.0.5, then the solution for them is to do a "rebase" which is basically a sort of "move" of their modifications to the newer VLP. When the move, the can also combine old branches into a single branch.

o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                             \                          \
         o--o--o vlp64_v104           o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v106
                \                               \                             
                 A--B--C release_v1              A--B--C--D release_v3        
                        \                                  \                                
                         D release_v2                       E release_v4                    

And so on, for the following versions:

o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                             \                          \
         o--o--o vlp64_v104           o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v10n
                \                               \                             \
                 A--B--C release_v1              A--B--C--D release_v3         A--B--C--D--E release_v5
                        \                                  \                                \
                         D release_v2                       E releaser_v4                    F release_v6

Once rebased, the old branches can sweetly die and new development shall continue on the new branch only.

How to Rebase your changes to a new BSP version

Create a local git repository of the kernel

Let us go thru an example using Chris' script that is meant to assist in checking out the relevant CIP kernel code from the repository and apply VLP patches on top. Obviously the script is not strictly required but if not used the user should identify the right mainline CIP kernel version to checkout, and then collect all the patches from the VLP version, and then apply those patches. This all needs to be done before the kernel can be build in the exact same way Yocto does in the VLP release.

To do that we just have to run the vlp64_util script:

./vlp64_util.sh create k . my_vlp_kernel_repo
What VLP64 BSP version do you want?
0. BSP-1.0.4
1. BSP-1.0.5
2. BSP-1.0.5-RT
3. BSP-1.0.5-RT-update1
4. BSP-1.0.6-update1
choice: 0

The script will then clone the CIP Linux repository and apply the correct Renesas BSP patches, also creating a branch called vlp64_v104.

o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                            
         o--o--o vlp64_v104

In your git repository, you should already be on branch "vlp64_v104"

  git branch
  master
* vlp64_v104

Make some change

Let us implement some changes to the VLP 1.0.4 release. For example we modify the init/calibrate.c:

void calibrate_delay(void)
{
       unsigned long lpj;
       static bool printed;
       int this_cpu = smp_processor_id();
       printk("*************************************\n");
       printk("*                                   *\n");
       printk("*        HELLO WORLD KERNEL         *\n");
       printk("*                                   *\n");
       printk("*************************************\n");
       if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
               lpj = per_cpu(cpu_loops_per_jiffy, this_cpu);
               if (!printed)
[...]

Then we will stage our changes and commit them to the repository. But first, you should really make a new branch for your development work, and change to it ("checkout"). Note that your edited source file "calibrate.c" will not be touched.

git status
git branch vlp64_v104_dev
git checkout vlp64_v104_dev
git status

HINT: You can combine the steps "git branch vlp64_v104_dev" and "git checkout vlp64_v104_dev" to a single step "git checkout -b vlp64_v104_dev"

Now our repository looks like this:

o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                            
         o--o--o vlp64_v104, vlp64_v104_dev

HINT: Use the command "gitk --all " to view this graphically.

Now we will add in our change to the repository.

git add calibrate.c
git commit -m "calibrate.c - Added some printk statements"

Now our repository will look like this (where "A" is the commit we just added)

o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                            
         o--o--o  vlp64_v104
                \
                 A  vlp64_v104_dev


Update the repository with a new BSP release

Now we will update the repository with a newer VLP.

$ ./vlp64_util.sh update my_vlp_kernel_repo
Detected kernel

These branches already exits in your repo:
- vlp64_v104

What VLP64 BSP version do you want?
0. BSP-1.0.4
1. BSP-1.0.5
2. BSP-1.0.5-RT
3. BSP-1.0.5-RT-update1
4. BSP-1.0.6-update1
choice: 1

The script detects that "my_vlp_kernel_repo" already contains a VLP kernel. We select VLP 1.0.5. Then the script will fetch/checkout the appropriate CIP kernel version and apply the patches on top of it:

$ git branch
  master
  vlp64_v104
* vlp64_v105
o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                             \
         o--o--o vlp64_v104           o--o--o--o vlp64_v105     
                \ 
                 A  vlp64_v104_dev

Let's have a look at the tags:

git tag
4.4.201-cip39-rt26
4.4.201-cip39-rt26-rebase
BSP-1.0.4
BSP-1.0.5
u2.6.24
..
..

Move your changes to the new BSP release using git rebase

Now let the magic begin. First we want to create a copy of the current (old) development branch. The 'checkout -b vlp_v105_dev' option will create a new branch for us with the name "vlp_v105_dev". This new branch will be at the same location as the "vlp64_v104" branch. We give this new branch a "v105" name is because we plan to move it on top of the BSP v1.0.5 release.

git checkout vlp64_v104_dev           <<< change to the branch we added our change in
git checkout -b vlp64_v105_dev        <<< make a new branch at the same location

Now we should have this. You can view with "gitk vlp64_v105_dev".

o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                             \
         o--o--o vlp64_v104           o--o--o--o vlp64_v105     
                \ 
                 A  vlp64_v104_dev, vlp64_v105_dev


Then we can move our patch (A = "Added some printk statements") to the latest version:

git rebase --onto BSP-1.0.5 BSP-1.0.4 vlp64_105_dev

This powerful git command needs a bit of explanation: it allows us to transplant the vlp64_105_dev branch based on the vlp64_v104 (= BSP-1.0.4) branch, to pretend that we forked the vlp64_105_dev branch from the vlp64_v105 (=BSP-1.0.5) branch. Please also have a look at the official git documentation here.

The result should look like this:

o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                             \
         o--o--o vlp64_v104           o--o--o--o vlp64_v105     
                \                               \
                 A  vlp64_v104_dev               A  vlp64_v105_dev

Now you are working on the BSP v1.0.5 kernel and you were able to keep your changes that you made in v1.0.4


Use Cherry Pick Instead of Rebase

There is also another possibility: instead of using git rebase we can use git cherry-pick. This command allows up to copy a single commit or a range of commits from one branch to another. In our example we have to first check the hash of the commit we want to cherry pick:

git checkout vlp64_v104
git log --oneline
f4d5d8172b76 (HEAD -> vlp64_v104) Added some printk message
[..]

Then checkout the destination branch:

git checkout vlp64_v105

Then make a new branch

git checkout -b vlp64_v105_dev

which will give you this:

o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                             \
         o--o--o vlp64_v104           o--o--o--o vlp64_v105, vlp64_v105_dev
                \ 
                 A  vlp64_v104_dev


And then [1]:

git cherry-pick f4d5d8172b76 

We can also cherry pick a range of commits. In the example below, "BSP-1.0.4" is a tag that shows the end of the Renesas BSP, and "vlp64_v104_dev" is the branch that has has our changes. So basically we are asking it to copy all the changes we made on top of the Renesas BSP.

git cherry-pick BSP-1.0.4..vlp64_v104_dev

You could also use this command (using branch name instead of tag name)

git cherry-pick vlp64_v104..vlp64_v104_dev

In our example this is exactly the same as [1] because we have only one commit between vlp64_v104 and BSP-1.0.4. So again, graphically, it will end up like this

o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o remotes/origin/linux-4.19.y-cip
       \                             \
         o--o--o vlp64_v104           o--o--o--o vlp64_v105     
                \                               \
                 A  vlp64_v104_dev               A  vlp64_v105_dev

Note: When selecting a range of patches, both cherry-pick and rebase "skip" the first patch. If you want to include it, you have to explicitly specify it by adding a ^. For example, let's assume:

         o--o--o vlp64_v104           o--o--o--o vlp64_v105     
                \                               
                 A-B-C-D-E                       

Now if we want to cherry pick the patches A-B-C-D-E and apply them to vlp64_v105, we can use the command:

git cherry-pick A^..E
         o--o--o vlp64_v104           o--o--o--o vlp64_v105     
                \                               \
                 A-B-C-D-E                       A-B-C-D-E

If instead we do not use "^":

git cherry-pick A..E

we will end up in having:

         o--o--o vlp64_v104           o--o--o--o vlp64_v105     
                \                               \
                 A-B-C-D-E                       B-C-D-E