Upgrading the Linux Kernel in OpenIPC linux

Repository layout

Branch	Purpose
master	Single orphan commit containing the base kernel tree
upstream-patches	Vendor patches rebased on top of master
openipc	Main integration branch (README, CI config)

Why an orphan commit?

GitHub rejects pushes that produce pack files larger than 2 GB. The full Linux kernel history is enormous, so pushing a real kernel commit as master will hit that limit every time.

Instead we store only the tree snapshot as a single root commit with no parents. Because git is content-addressable, subsequent updates only transfer the blobs that actually changed between releases — keeping the pack small.

---

Part 1 — Setting a new kernel version on master

This is the procedure for bumping the base kernel (e.g. from 7.0-rc6 to 7.0, or from 7.0 to 7.1).

Prerequisites

A local mirror of the official kernel repository:

# One-time setup
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git \
    ~/git/torvalds/linux

# Before each upgrade, pull latest tags
cd ~/git/torvalds/linux && git fetch --tags

Step-by-step

cd ~/git/linux

# 1. Configure git identity
git config user.name  "Your Name"
git config user.email "you@openipc.org"

# 2. Add the local mirror as a remote (skip if already added)
git remote add upstream ~/git/torvalds/linux/

# 3. Fetch the target release tag
git fetch upstream tag v7.1

# 4. Record the current master SHA (old orphan)
OLD_MASTER=$(git rev-parse master)

# 5. Create a new orphan commit from the release tree
NEW_MASTER=$(git commit-tree v7.1^{tree} -m "Linux 7.1")

# 6. Point master to the new orphan
git update-ref refs/heads/master $NEW_MASTER

# 7. Rebase vendor patches onto the new base
git checkout upstream-patches
git rebase --onto $NEW_MASTER $OLD_MASTER

# 8. Force-push both branches
git push origin master --force
git push origin upstream-patches --force

What each command does

• git commit-tree <tree> -m <msg> — creates a commit with the given tree and no parents (an orphan). No files are checked out.
• git update-ref — moves the branch pointer without touching the working tree.
• git rebase --onto NEW OLD — replays every commit between OLD and HEAD onto NEW. If conflicts arise, git pauses and lets you resolve them one patch at a time (git add <file>, then git rebase --continue).

Common mistakes to avoid

Mistake	What happens	How to avoid
Using a real kernel commit instead of orphan	Push fails with "pack exceeds 2 GB"	Always use git commit-tree to create orphan
Wrong OLD_MASTER in rebase	Replays thousands of commits from full history	Always use git rev-parse master before updating master
Missing user.name/user.email	git commit-tree fails with "Author identity unknown"	Set with git config before starting
SSH auth fails after flashing device	sysupgrade stops dropbear mid-session	Wait for full reboot, then reconnect

---

Part 2 — Syncing patches with the torvalds repository

Incremental update (point release, e.g. 7.0 → 7.0.1)

The tree difference is small. The procedure is identical to Part 1:

git fetch upstream tag v7.0.1
OLD=$(git rev-parse master)
NEW=$(git commit-tree v7.0.1^{tree} -m "Linux 7.0.1")
git update-ref refs/heads/master $NEW
git checkout upstream-patches && git rebase --onto $NEW $OLD
git push origin master upstream-patches --force

Major version bump (e.g. 7.0 → 7.1)

Same commands, but conflicts are more likely. Tips:

• Read the changelog for subsystems your patches touch (MTD, I2C, clock drivers, device tree bindings) before starting.
• Resolve one patch at a time. After editing the conflicted file, run git add <file> then git rebase --continue.
• Drop patches accepted upstream. If a patch was merged into mainline, use git rebase --skip to remove it.

Cherry-picking individual upstream fixes

When you need a specific fix without bumping the whole version:

# Find the commit in torvalds repo
cd ~/git/torvalds/linux
git log --oneline --all --grep="fix spi-nor timeout"

# Cherry-pick into upstream-patches
cd ~/git/linux
git checkout upstream-patches
git cherry-pick <commit-sha>
git push origin upstream-patches --force

Cherry-picked commits are dropped automatically during the next full rebase if the same change already exists in the new base tree.

---

Verification

After any kernel update, always build and test on real hardware.

1. CI build

gh workflow run build-one -R OpenIPC/firmware -f platform=hi3516ev300_neo
gh run watch <run-id> -R OpenIPC/firmware --exit-status

2. Flash the device

The firmware is uploaded to the latest GitHub release automatically:

ssh root@<device> \
  "sysupgrade --url=https://github.com/OpenIPC/firmware/releases/download/latest/openipc.<soc>-nor-<variant>.tgz"

3. Confirm kernel version

ssh root@<device> "uname -r"

Output should show the new version without an -rcN suffix.

---

Quick reference

Full upgrade in 6 commands:

git fetch upstream tag vX.Y
OLD=$(git rev-parse master)
NEW=$(git commit-tree vX.Y^{tree} -m "Linux X.Y")
git update-ref refs/heads/master $NEW
git checkout upstream-patches && git rebase --onto $NEW $OLD
git push origin master upstream-patches --force