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

From eLinux.org
Jump to: navigation, search
(One intermediate revision by the same user not shown)
Line 38: Line 38:
  
 
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.
 +
 +
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          o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v106       
 +
 +
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          o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v106       
 +
 +
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 he VLP 1.0.4 release and that we implemented some changes to it. For example we modified 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)
 +
 +
Staged and committed changes:
 +
 +
git add calibrate.c
 +
git commit -m "calibrate.c - Added some printk statements"
 +
 +
Then 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 the magic can begin. First we may want to create a copy of the old development branch:
 +
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 BSP-1.0.4 (= vlp64_v104) branch, to pretend that we forked the vlp_105_dev branch from the BSP-1.0.5 (vlp64_v105) 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   
 +
                \ vlp64_v105_dev
 +
                  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   
 +
                \                              \ vlp64_v105_dev
 +
                  A                              A

Revision as of 00:57, 11 February 2021

To migrate from one VLP version to the following, the best would be to rebase.

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:

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         

But customers have probably started working on one version, created their own branch and 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 customer_v1                    
                        \                                  
                         D customer_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:

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 customer_v1             A--B--C--D customer_v3        
                        \                                  \                                
                         D customer_v2                      E customer_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 customer_v1             A--B--C--D customer_v3        A--B--C--D--E customer_v5
                        \                                  \                                \
                         D customer_v2                      E customer_v4                    F customer_v6

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

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 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           o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v106         

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           o--o--o--o vlp64_v105      o--o--o--o--o vlp64_v106         

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 he VLP 1.0.4 release and that we implemented some changes to it. For example we modified 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)

Staged and committed changes:

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

Then 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 the magic can begin. First we may want to create a copy of the old development branch: 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 BSP-1.0.4 (= vlp64_v104) branch, to pretend that we forked the vlp_105_dev branch from the BSP-1.0.5 (vlp64_v105) branch. Please also have a look at the official git documentation 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     
                \ vlp64_v105_dev
                  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     
                \                               \ vlp64_v105_dev
                  A                              A