Hello Toradex community,
My project requires me to make modifications to the Toradex linux kernel. My workflow is that I develop the kernel separately and when I’m happy with the modifications I push them to my enterprise git repo and then have yocto pull and build the kernel based on a specified commit from that repo. This workflow works fine.
For context I’m calling the git.toradex.com remote “toradex” and my enterprise server is “origin”.
Currently my modifications are against toradex_imx_3.14.28_1.0.0_ga and I would like to upgrade to 3.14.52 while preserving those modifications. This is what I do:
# Check out the local 3.14.28 based branch with my modifications git checkout my_toradex_imx_3.14.28_1.0.0_ga # Create a new branch intended for 3.14.52 merge git checkout -b my_toradex_imx_3.14.52_1.1.0_ga # Merge with upgraded Toradex branch git fetch toradex && git merge toradex/toradex_imx_3.14.52_1.1.0_ga
However this is causing a large amount of conflicts:
$ git merge toradex/toradex_imx_3.14.52_1.1.0_ga Auto-merging sound/soc/soc-core.c Auto-merging sound/soc/fsl/imx-wm8962.c CONFLICT (content): Merge conflict in sound/soc/fsl/imx-wm8962.c Auto-merging sound/soc/fsl/imx-mqs.c CONFLICT (add/add): Merge conflict in sound/soc/fsl/imx-mqs.c Auto-merging sound/soc/fsl/imx-cs42888.c ...
I would expect there to be some conflicts related to my own modifications but these conflicts are mostly with files I haven’t touched.
This leads me to the conclusion that my upgrade workflow is flawed, granted I’m unexperienced with linux development.
Can you please suggest a less conflict prone way for me to migrate between Toradex kernel versions?