[Linux] Kernel Version Upgrade 2 (with ODROID-M1)
September seems to be the month for part 2s.
My posts keep getting delayed because I have a lot going on,
but I’ll try to work harder.
Prerequisites
Prepare the following:
- PC (Ubuntu 20.04LTS or later)
- ODROID-M1 board (x1)
- SSH-enabled environment
Kernel Upgrade
Commit History
In the previous post, we went through the process of organizing commits before the upgrade.
Now, we need to actually apply those commits to the BSP.
Before doing that, let’s review the history of the BSP and the M1.
First, the board has its main chips.
The ODROID-M1 is equipped with the RK3568.
The RK3568 includes a CPU, GPU, NPU, etc., and is provided by Rockchip.
To make this chip operational, the manufacturer (Rockchip) provides software, including the kernel, along with an EVB (Evaluation Board) that connects various I/Os for testing.
This software package is called a BSP (Board Support Package).
Since I will be upgrading the kernel, I’ll only look at the kernel history.
Rockchip’s BSP tends to follow the Linux kernel mainline.
The linux mainline looks like this:
...
*
*
...
* --- 5.10.y
...
*
* --- 4.19.y
It’s a structure where commits accumulate in a straight line by version.
Rockchip’s BSP (RK3568) looks like this:
...
*
* --- 5.10.y
*
*
*
*
* * --- rk356x_linux_20221220
* /
* ...
* /
* *
*/
* --- 4.19.y
The kernel update for the M1 is based on the BSP (as of 2023.09.01, the M1 BSP is rk356x_linux_20221220).
* --- odroidm1-4.19.y
*
*
...
*
* --- rk356x_linux_20221220
/
...
/
*
/
* --- 4.19.y
The BSP kernel is either built on top of previously provided commits, like this:
* --- rk356x_linux_aaaaaaaa
*
*
...
*
* --- rk356x_linux_20221220
/
...
/
*
/
* --- 4.19.y
Or, there are cases where the kernel version itself is upgraded:
<Linux>
*
rk356x_linux_bbbbbbbb --- * *
\ *
... *
\ *
* *
\*
* --- 5.10.y
...
*
*
*
* * --- rk356x_linux_aaaaaaaa
* *
* ...
* *
* * --- rk356x_linux_20221220
* /
* ...
* /
* *
*/
* --- 4.19.y
Looking at it again alongside the M1’s history:
<Linux>
*
rk356x_linux_bbbbbbbb --- * *
\ *
... *
\ *
* *
\*
* --- 5.10.y
...
*
*
*
* * --- odroidm1-4.19.y
* *
* * * --- (HEAD) -> odroidm1-5.10.y-dev
* ... /
* * *
* */
* * --- rk356x_linux_20221220
* /
* ...
* /
* *
*/
* --- 4.19.y
It looks like the diagram above.
We can see the continuous updates on the M1’s 4.19 kernel and the odroidm1-5.10.y-dev branch created in the previous post to organize the commits.
Now, we need to place these organized commits on top of the 5.10 version BSP.
In summary,
all commits between the rk356x_linux_20221220 branch and the odroidm1-5.10.y-dev branch must be moved
on top of the rk356x_linux_bbbbbbbb branch.
There are two main ways to do this: cherry-pick and rebase.
I mostly use cherry-pick when performing an upgrade.
This is because the number of commits is not overwhelmingly large (around 40), and I apply and test them one by one.
It also makes resolving conflicts much easier.
cherry-pick
<Linux>
*
rk356x_linux_bbbbbbbb --- * *
\ *
... *
\ *
* *
\*
* --- 5.10.y
...
*
*
*
* * --- odroidm1-4.19.y
* *
* * * --- (HEAD) -> odroidm1-5.10.y-dev
* ... /
* * *
* */
* * --- rk356x_linux_20221220
* /
* ...
* /
* *
*/
* --- 4.19.y
The cherry-pick method is straightforward.
Every M1 commit that was updated on top of the rk356x_linux_20221220 branch
is simply cherry-picked sequentially one by one onto the new BSP commits.
After cherry-picking all the commits and deleting the old branch, the result looks like this:
<Linux>
...
*
*
odroidm1-5.10.y-dev --- * *
* *
... *
* *
rk356x_linux_bbbbbbbb --- * *
\ *
... *
\ *
* *
\*
* --- 5.10.y
...
*
*
*
* * --- odroidm1-4.19.y
* *
* *
* ...
* *
* *
* * --- rk356x_linux_20221220
* /
* ...
* /
* *
*/
* --- 4.19.y
This state represents a completed upgrade.
rebase
<Linux>
*
rk356x_linux_bbbbbbbb --- * *
\ *
... *
\ *
* *
\*
* --- 5.10.y
...
*
*
*
* * --- odroidm1-4.19.y
* *
* * * --- (HEAD) -> odroidm1-5.10.y-dev
* ... /
* * *
* */
* * --- rk356x_linux_20221220
* /
* ...
* /
* *
*/
* --- 4.19.y
You need to rebase all commits between the rk356x_linux_20221220 branch and the odroidm1-5.10.y-dev branch.
For rebase, you use the –onto option.
If you just run a standard rebase, for example (while at HEAD: odroidm1-5.10.y-dev):
$ git rebase rk356x_linux_bbbbbbbb
This will attempt to apply all commits with a different history from the target branch (rk356x_linux_bbbbbbbb).
Because this would also rebase all the commits down to right above the Linux mainline 4.19 version, you must use the –onto option.
Using the –onto option prevents rebasing every commit with a different history than the target branch.
Instead, it specifies an exact range.
git rebase –onto ‘target’ ‘a’ ‘b’
This rebases commits from ‘a’ to ‘b’ onto ‘target’.
The command for the M1 upgrade is as follows (while at HEAD: odroidm1-5.10.y-dev):
$ git rebase --onto rk356x_linux_bbbbbbbb rk356x_linux_20221220 odroidm1-5.10.y-dev
Alternatively,
if you know the exact number of commits to move (say, 10), you can do this (while at HEAD: odroidm1-5.10.y-dev):
$ git rebase --onto rk356x_linux_bbbbbbbb HEAD~10 odroidm1-5.10.y-dev
You can rebase this way as well.
However, I do not generally recommend the rebase approach itself.
Of course, you have to resolve any conflicts that arise during the rebase process.
Once the rebase is complete, it takes the following shape:
<Linux>
...
*
*
odroidm1-5.10.y-dev --- * *
* *
... *
* *
rk356x_linux_bbbbbbbb --- * *
\ *
... *
\ *
* *
\*
* --- 5.10.y
...
*
*
*
* * --- odroidm1-4.19.y
* *
* *
* ...
* *
* *
* * --- rk356x_linux_20221220
* /
* ...
* /
* *
*/
* --- 4.19.y
Release
Testing is ongoing. Look forward to the next upgraded M1 release!
Leave a comment