Automatic kernel config rewrite
#8902
Conversation
github-actions
bot
requested review from
AGM1968,
Grippy98,
JohnTheCoolingFan,
PanderMusubi,
Tonymac32,
chraac,
glneo,
igorpecovnik,
jonaswood01,
krachlatte,
pyavitz,
schwar3kat,
teknoid and
vidplace7
as code owners
|
Important Review skippedBot user detected. To trigger a single review, invoke the You can disable this status message by setting the Comment |
| @@ -1,4 +1,4 @@ | |||
| # Armbian defconfig generated with 6.12 | |||
| # Armbian defconfig generated with 6.6 | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
So here is my attempt to clean this up for the Beagle boards when using their custom kernel: #8913
| CONFIG_VIDEO_VGXY61=m | ||
| CONFIG_VIDEO_CCS=m | ||
| CONFIG_VIDEO_ET8EK8=m | ||
| CONFIG_VIDEO_GC2145=m |
There was a problem hiding this comment.
I wonder why this happens. It's moving stuff around. Wonder if we should | sort the defconfig to avoid this un-necessary juggling.
There was a problem hiding this comment.
Sadly Allwinner patchset is in bad state - probably there is a reason for this trouble ... something is not done right.
What to do with?
config/kernel/linux-rockchip-rv1106-vendor.config
github-actions
bot
force-pushed
the
update-kernel-configs
branch
from
ec115aa to
74feffa
Compare
github-actions
bot
requested review from
ColorfulRhino,
HeyMeco,
SuperKali,
TheSnowfield,
ahoneybun,
amazingfate,
brentr,
catalinii,
chainsx and
efectn
as code owners
github-actions
bot
requested review from
joekhoobyar,
lanefu,
paolosabatino and
prahal
as code owners
github-actions
bot
force-pushed
the
update-kernel-configs
branch
from
74feffa to
2e70a53
Compare
github-actions
bot
requested review from
ginkage and
sputnik2019
as code owners
github-actions
bot
force-pushed
the
update-kernel-configs
branch
from
2e70a53 to
78f2c17
Compare
| CONFIG_SND_SOC_SOF_TOPLEVEL=y | ||
| CONFIG_SND_SOC_SOF_OF=y | ||
| CONFIG_SND_SOC_SOF_MTK_TOPLEVEL=y | ||
| CONFIG_SND_SOC_J721E_EVM=m |
There was a problem hiding this comment.
for one... the current config claims to be against 6.12. this PR is re-running it against 6.18.
HOWEVER... I'm not clear that you ran rewrite-kernel-config prior to submitting #8960 so that 6.12 notation could easily be incorrect as this PR did bump the version.
There was a problem hiding this comment.
Note that running ./compile.sh kernel-config foo bar baz, and chasing down the drivers menu under CONFIG_SND_SOC, I do not see a menu for Texas Instruments
cache/sources/linux-kernel-worktree/6.18__k3-beagle__arm64/sound/soc/ti/Kconfig
# SPDX-License-Identifier: GPL-2.0-only
menu "Texas Instruments"
depends on DMA_OMAP || TI_EDMA || TI_K3_UDMA || COMPILE_TEST
tabris@brunnt:~/build/armbian-build$ egrep '(DMA_OMAP|TI_EDMA|TI_K3_UDMA)' -r cache/sources/linux-kernel-worktree/6.18__k3-beagle__arm64/.config
tabris@brunnt:~/build/armbian-build$
the menu appears to be dependent on things not present.
| CONFIG_BCM_SBA_RAID=m | ||
| CONFIG_DW_EDMA=m | ||
| CONFIG_TI_K3_UDMA=y | ||
| CONFIG_TI_K3_UDMA_AM62L=y |
There was a problem hiding this comment.
This block is an issue K3_UDMA is needed.
There was a problem hiding this comment.
these are technically overlays over top of defaults. have you checked, with rewrite-kernel-config, the config/kernel/linux-k3-beagle-edge.config vs the kernel tree's .config. removing it from this file may be the correct thing to do if it would have defaulted to these values anyway.
There was a problem hiding this comment.
to be clear... all rewrite-kernel-config does is load the kernel tree, overlay the changes from our config/kernel/foo.config, then run make oldconfig. then make savedefconfig.
So this is entirely what's going on in that kernel tree, not Armbian.
There was a problem hiding this comment.
cache/sources/linux-kernel-worktree/6.18__k3-beagle__arm64/drivers/dma/ti/Kconfig
config TI_K3_UDMA
tristate "Texas Instruments UDMA support"
depends on ARCH_K3
depends on TI_SCI_PROTOCOL
depends on TI_SCI_INTA_IRQCHIP
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
select TI_K3_RINGACC
select TI_K3_PSIL
help
Enable support for the TI UDMA (Unified DMA) controller. This
DMA engine is used in AM65x and j721e.
tabris@brunnt:~/build/armbian-build$ egrep '(ARCH_K3|TI_SCI_PROTOCOL|TI_SCI_INTA_IRQCHIP)' cache/sources/linux-kernel-worktree/6.18__k3-beagle__arm64/.config config/kernel/linux-k3-beagle-edge.config
cache/sources/linux-kernel-worktree/6.18__k3-beagle__arm64/.config:CONFIG_ARCH_K3=y
config/kernel/linux-k3-beagle-edge.config:CONFIG_ARCH_K3=y
so to enable CONFIG_TI_K3_UDMA, there's two symbols not enabled.
There was a problem hiding this comment.
So I validated that I could get CONFIG_TI_K3_UDMA to stick by adding
tabris@brunnt:~/build/armbian-build$ git diff upstream/main config
diff --git a/config/kernel/linux-k3-beagle-edge.config b/config/kernel/linux-k3-beagle-edge.config
index 95176fc8c..980b1880b 100644
--- a/config/kernel/linux-k3-beagle-edge.config
+++ b/config/kernel/linux-k3-beagle-edge.config
@@ -1100,3 +1100,7 @@ CONFIG_CORESIGHT_STM=m
CONFIG_CORESIGHT_CPU_DEBUG=m
CONFIG_CORESIGHT_CTI=m
CONFIG_MEMTEST=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_TI_SCI_INTA_IRQCHIP=y
+CONFIG_TI_MESSAGE_MANAGER=y
+CONFIG_MAILBOX=y
But CONFIG_TI_K3_UDMA_AM62L isn't present in the tree at all
tabris@brunnt:~/build/armbian-build$ egrep 'TI_K3_UDMA_AM62L' -r cache/sources/linux-kernel-worktree/6.18__k3-beagle__arm64/
cache/sources/linux-kernel-worktree/6.18__k3-beagle__arm64/.config.old:CONFIG_TI_K3_UDMA_AM62L=y
There was a problem hiding this comment.
So since the scripts only take the old defconfig, apply to new kernel, then save again, any changes to the ARM64 in-kernel defconfig get missed. In this case, since these symbols were broken out in upstream between 6.12 and 6.18 [0] they did not get applied even though they are default now.
This probably isn't an issue for moving from one patch release to the next, but for a configuration that moves between versions (like our edge configs which track the latest master tags) we might want one addition to the automation script. It should apply the in-kernel defconfig for the arch[1] before applying the current config.
I think in this case for now we will have to just review the config and make a one time set of manual adjustments for this first move of our edge kernel from v6.12 to v6.18.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c7691aec5e991cec9c5c5fdab08c24856a1fc56f
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/configs/defconfig
There was a problem hiding this comment.
Okay, sent the manual defconfig update for these K3 boards here[0].
@Grippy98 , @jonaswood01 , Would be good to review that PR and get a test in on your set of boards.
[0] #9019
Rewrite kernel configs
What this PR does
./compile.sh rewrite-kernel-configfor each scheduled (family, branch) and aggregates all changes into one PR.How it was produced
This PR is produced from this GHA script.
./compile.sh inventory-boards(deduped, sanitized).rewrite-kernel-configper matrix.Review tips
Files changed
Files: 16 • Lines: +505 / -498 (Δ 7)