Automatic kernel config rewrite

[github-actions]

Rewrite kernel configs

What this PR does

• Regenerates and synchronizes Linux kernel config fragments across boards/families based on the prepared inventory.
• Runs ./compile.sh rewrite-kernel-config for each scheduled (family, branch) and aggregates all changes into one PR.
• No userspace changes; only Kconfig option updates (enable/disable/modules/values) aligned with the targeted kernel branches.

How it was produced

This PR is produced from this GHA script.

1. Built a matrix: ./compile.sh inventory-boards (deduped, sanitized).
2. Executed rewrite-kernel-config per matrix.
3. Collected only changed files from each job as artifacts; aggregated and committed them here.

Review tips

• Skim the table below for big deltas; open those configs to verify intent.
• If a particular change is undesirable, comment on that file and we can exclude/adjust and re-run.

Files changed

File	+	-	Δ
config/kernel/linux-k3-current.config	7	14	-7
config/kernel/linux-rockchip-rv1106-vendor.config	242	189	53
config/kernel/linux-sunxi64-edge.config	1	1	0

Files: 3 • Lines: +250 / -204 (Δ 46)

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch update-kernel-configs

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[rpardini]

Something is very wrong with this beagle / k3 stuff.
The boards beagley-ai.conf (1x) and pocketbeagle2.conf (2x) are all sharing a LINUXFAMILY and apparently also a LINUXCONFIG, although they're all different KERNELSOURCEs and KERNELBRANCH's.

That is why this is flipping between 6.6 and 6.12.

It needs cleanup; preferably unifying it around a single kernel, or actually using separate LINUXFAMILY/LINUXCONFIG for each, otherwise crazy will ensue.

@igorpecovnik who is actually maintaining those? it is probably causing other problems (overwritten .deb's in apt repo, maybe) other than this.

[igorpecovnik]

Something is very wrong with this beagle / k3 stuff

Indeed.

who is actually maintaining those?

Themselves https://github.com/orgs/armbian/teams/boards-texasinstruments with my assistance. I recently asked @tabrisnet to help around such problems, so I expect that situation will improve soon.

[Grippy98]

On our side the way things are is basically this-

All Texas Instruments SoC based boards are K3 (Keystone 3 Family) so they are built with k3.conf.

BeagleBoards then re-use most of infra except they keep their own Kernel and Uboot configs.

All TI based EVMs should then use TI defconfigs and sources for Kernel/Uboot. (Although we did want to add mainline options instead of just vendor at some point in the future)

For Beagle - boards that are in mainline (like BeaglePlay) are easy, but then in the case of PocketBeagle2 (and especially) BeagleY we had to keep them with post-family configs to pin BeagleY to a patched 6.6 kernel from Beagle for example. Beagleboard maintain a forks of the TI Linux & Uboot with their own patches. It's messy at the best of times and I'm not sure how to really clean this up currently... it's mostly on the Beagle side.

For KConfigs - the TI ones should in theory be pruned regularly to align with what we ship in Yocto releases with some small deltas where it makes sense. Beagle keeps their own separate KConfigs since they have a lot more historic stuff switched on due to users asking for them.

Any recommendations I'm very open to....
@jonaswood01 @glneo for visibility too.

[glneo]

The Beagle boards should be using the TI kernel and upstream, only the two mentioned cases I see LINUXFAMILY="k3-beagle" for using the "Beagle" kernel, but the LINUXCONFIG would remain the default from the TI/upstream kernel settings. We should either use a different LINUXCONFIG for those, or at this point switch them away from the Beagle kernels and back to the normal TI/upstream kernel.

[Grippy98]

I think in this particular case Play and AI64 would both boot fine off of TI branch... Pb2 may as well.

If they don't boot like that should I just revert them to CSC and keep the hackyness w/Beagle sources for now?

[rpardini]

Booting-or-not, internal details of each board, etc, are not in question here.

All Texas Instruments SoC based boards are K3 (Keystone 3 Family) so they are built with k3.conf.

That's fine, but...

BeagleBoards then re-use most of infra except they keep their own Kernel and Uboot configs.

... that is not correct. If each board needs a different kernel (due to a different source branch, .config, or whatever that in the end causes it to be a different kernel / different .deb package) then each board should be in it's own LINUXFAMILY, with it's own LINUXCONFIG.

Sincerely I recommend ya'll try to unify it - there's expenses (of both machine-time, bandwidth, but most important of maintainer time, as you can see in this PR) related to having multiple kernels.

[rpardini]

Since I spent the time already, here goes.

{
  "BOARD": "beaglebone-ai64",
  "BRANCH": "current",
  "kernel": "k3",
  "needed_by": 8,
  "ARMBIAN_KERNEL_DEB_NAME": "k3-current",
  "LINUXCONFIG": "linux-k3-current",
  "KERNELSOURCE": "https://github.com/TexasInstruments/ti-linux-kernel",
  "KERNELBRANCH": "tag:11.00.09"
}
{
  "BOARD": "beaglebone-ai64",
  "BRANCH": "edge",
  "kernel": "k3",
  "needed_by": 8,
  "ARMBIAN_KERNEL_DEB_NAME": "k3-edge",
  "LINUXCONFIG": "linux-k3-edge",
  "KERNELSOURCE": "https://github.com/TexasInstruments/ti-linux-kernel",
  "KERNELBRANCH": "tag:11.00.12"
}
{
  "BOARD": "beagley-ai",
  "BRANCH": "current",
  "kernel": "k3-beagle",
  "needed_by": 1,
  "ARMBIAN_KERNEL_DEB_NAME": "k3-beagle-current",
  "LINUXCONFIG": "linux-k3-current",
  "KERNELSOURCE": "https://github.com/beagleboard/linux",
  "KERNELBRANCH": "branch:v6.6.58-ti-arm64-r21"
}
{
  "BOARD": "pocketbeagle2",
  "BRANCH": "edge",
  "kernel": "k3-beagle",
  "needed_by": 1,
  "ARMBIAN_KERNEL_DEB_NAME": "k3-beagle-edge",
  "LINUXCONFIG": "linux-k3-beagle-edge",
  "KERNELSOURCE": "https://github.com/beagleboard/linux",
  "KERNELBRANCH": "branch:v6.12.24-ti-arm64-r43"
}

As you can see, the k3-current kernel (used by 8 boards, amongst them beaglebone-ai64) is using LINUXCONFIG linux-k3-current.

The k3-beagle-current kernel (used by a single board, beagley-ai) is also using LINUXCONFIG linux-k3-current.

This obviously is incorrect.

There is also a plethora of other problems, like -rt variants just left there, etc.

[glneo]

So here is my attempt to clean this up for the Beagle boards when using their custom kernel: #8913

[rpardini]

I wonder why this happens. It's moving stuff around. Wonder if we should | sort the defconfig to avoid this un-necessary juggling.