|
|
| (12 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.
| + | this page can be deleted |
| − | | |
| − | 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 [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 modift 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 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 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
| |
| − | \ '''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
| |
| − | 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.
| |
| − | 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 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'''
| |
