Add a recipe to compile qcom staging kernel. #784
Conversation
Add a recipe for the linux-qcom-staging 6.12 kernel. This staging kernel tree includes additional patches on top of the 6.12 kernel, many of which are in the process of being upstreamed. Starting with 6.12, this tree will continue to catch up with the latest releases (6.13, 6.14, etc.), with patches being dropped and rebased in the process. Eventually, all patches from this staging kernel will be available in the mainline kernel. Signed-off-by: Viswanath Kraleti <[email protected]>
Now that we want to validate BSP against staging kernel, include CI kas configuration file for to set virtual/kernel to linux-qcom-staging. Signed-off-by: Viswanath Kraleti <[email protected]>
quic-vkraleti
requested review from
NainaMehtaQUIC,
sbanerjee-quic,
ndechesne,
quaresmajose and
ricardosalveti
as code owners
Test jobs for commit 74fc497 |
| SRCBRANCH ?= "qclinux.6.12.y" | ||
| SRC_URI = "${LINUX_QCOM_GIT};branch=${SRCBRANCH}" | ||
|
|
||
| SRCREV = "10325dc2277dc03687683b9f5f57a472b37de0b4" |
There was a problem hiding this comment.
This is 6.12.0, while the latest release from that branch is 6.12.17. Is there a reason for missing the fixes / updates?
There was a problem hiding this comment.
+1
I think it's important that we use the latest -stable version for our own builds
There was a problem hiding this comment.
I think it's important that we use the latest -stable version for our own builds
Since we are revising mainline kernel workflow, would be good to focus there.
This staging on v6.12 shall serve to bring up rest of Qualcomm Linux.
| KERNEL_CONFIG ??= "qcom_defconfig" | ||
|
|
||
| # Additional fragment for qcom value add features | ||
| KERNEL_CONFIG_FRAGMENTS += " ${S}/arch/arm64/configs/qcom_addons.config" |
There was a problem hiding this comment.
If there is an an in-tree .config, why do we need extra fragments?
There was a problem hiding this comment.
If there is an an in-tree .config, why do we need extra fragments?
This just acts as a separation to club custom downstream CONFIGs together in qcom_addons.config.
| SRCBRANCH ?= "qclinux.6.12.y" | ||
| SRC_URI = "${LINUX_QCOM_GIT};branch=${SRCBRANCH}" | ||
|
|
||
| SRCREV = "10325dc2277dc03687683b9f5f57a472b37de0b4" |
There was a problem hiding this comment.
Would it be possible to use devupstream class to build the ${AUTOREV} instead? By default it should still build the selected revision and builds should work with BB_NO_NETWORK=1.
|
What is the expected cadence? 6.13 has been released on 20th of January, more than a month ago. When do you expect a 6.13-based branch? Is it going to be a rebase or a fresh start? |
|
Given this it seems this staging is a candidate for meta-qcom-hwe, staging branch. |
-ENOSUCHBRANCH |
@ndechesne , @ricardosalveti , me and @quic-vkraleti have discussed and agreed in past couple of weeks about the need for a staging branch only on meta-qcom-hwe layer. Which will serve as a staging for technology components that at this time cannot be accepted into meta-qcom master. |
Can you provide an example of such a component? The 'staging' branch has one main issue: you push some code there, where it stays, other people start to depend on it, etc. Then you try to move it to meta-qcom. Kaboom. There is a review of "this is not a way to be done, please start from the scratch". Now you have to spend time again on reingeneering the component which is assumingly done already. I'd very much prefer to have a set of PRs open again meta-qcom and an optional autobuilder which provides a linux-next-like branch, instead of having the external 'staging'. |
I don't understand. Nobody is pushing back against merging linux-qcom-staging in meta-qcom. and we agreed to merge the recipe, just not make it 'default' until it is up-to-date with linux current release. I am seeing review comments from Dmitry like the use of devupstream or the in-tree config. let's finalize these comments and merge the recipe, no? |
This PR is submitted based on the discussions that happened in PR745 and sync-ups with @ndechesne and @ricardosalveti about the need for a recipe to build a staging kernel tree with additional patches, especially for boards based on QCS9100 & QCS6490. For the early enablement of other Qcom technologies such as Multimedia and Connectivity on these boards, we need this staging kernel to be built.
This staging kernel tree includes additional patches on top of the 6.12 kernel, many of which are in the process of being upstreamed. Starting with 6.12, this tree will continue to catch up with the latest releases (6.13, 6.14, etc.), with patches being dropped and rebased in the process. Eventually, all patches from this staging kernel will be available in the mainline kernel.
This patch series brings a recipe for the staging kernel and a CI yml file to build linux-qcom-staging. The machine configuration files are untouched and continue to build the linux-yocto-dev kernel. To build the staging kernel, run the kas command as below:
kas build meta-qcom/ci/qcs6490-rb3gen2-core-kit.yml:meta-qcom/ci/staging-kernel-provider.ymlI’ll further work with @ndechesne, @koenkooi, and @ricardosalveti to enable this staging kernel in GitHub CI to avoid regressions.