|
|
| (23 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 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 (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
| |
