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

From eLinux.org
Jump to: navigation, search
Line 7: Line 7:
 
           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 on one version, created their own branch and applied their own modifications:  
+
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--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

Revision as of 23:46, 9 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_v106
                \                               \                             \
                 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.