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

From eLinux.org
Jump to: navigation, search
(change term customer to user)
(Replaced content with "this page can be deleted")
(Tag: Replaced)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
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.
+
this page can be deleted
 
 
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 "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 ==
 
 
 
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:
 
 
 
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             
 
 
 
And then collect all the patches from the VLP version:
 
 
 
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   
 
 
 
And apply them 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 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 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 stage and commit changes:
 
 
 
git add calibrate.c
 
git commit -m "calibrate.c - Added some printk statements"
 
 
 
Now we 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
 
 
 
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
 
..
 
..
 
 
 
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
 
git checkout -b vlp_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 vlp_105_dev'''
 
 
 
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:
 
 
 
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_v105_dev'''
 
To 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                              '''A vlp64_v105_dev'''
 
 
 
== 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:
 
 
 
git checkout vlp64_v104
 
git log --oneline
 
f4d5d8172b76 (HEAD -> vlp64_v104) Added some printk message
 
[..]
 
 
 
Then checkout the destination branch:
 
git checkout vlp_v105
 
 
 
And then ''[1]'':
 
git cherry-pick f4d5d8172b76
 
 
 
We can also cherry pick a range of commits:
 
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:
 
 
 
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           
 
To 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                              '''A'''
 

Latest revision as of 13:00, 23 July 2021

this page can be deleted