ti: config: kernel: Add `current` RT config file

[jsuhaas22]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

This PR adds the RT kernel config file for TI devices. If RT_KERNEL=yes is passed as an argument to ./compile.sh, a PREEMPT_RT image is built.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

Tested this on SK-AM62B.

Test 1: boot test: the board successfully booted Test 2: uname -a test: PREEMPT_RT string was present in the output, thus suggesting that its indeed an RT image Test 3: zcat /proc/config.gz | grep -i RT: Further confirmed that the PREEMPT_RT config is enabled in the running image

Checklist:

Please delete options that are not relevant.

• [ ] My code follows the style guidelines of this project
• [ ] I have performed a self-review of my own code
• [ ] My changes generate no new warnings

cc: @glneo @Grippy98 @nmenon @sadik-smd

[coderabbitai[bot]]

Walkthrough

A new Linux kernel configuration file, linux-k3-current-rt.config, has been added for ARM64 K3 platforms with real-time (PREEMPT_RT) support. This configuration enables a wide range of kernel features, drivers, and real-time options tailored for K3 SoCs. Additionally, the k3.conf source configuration was updated to treat the current-rt branch identically to the current branch, consolidating their configuration logic. No changes were made to exported or public entity declarations outside of the new configuration file.

Suggested labels

ready to merge

Suggested reviewers

• rpardini
• glneo
• igorpecovnik

---

📜 Recent review details

Configuration used: CodeRabbit UI Review profile: CHILL Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 35a5dca00f5088ec29f7b4f7b5ba511e8916c56b and 2aa3175a716d7665dd8bb741d94760fdaaa04648.

📒 Files selected for processing (2)

• config/kernel/linux-k3-current-rt.config (1 hunks)
• config/sources/families/k3.conf (1 hunks)

✅ Files skipped from review due to trivial changes (1)

• config/kernel/linux-k3-current-rt.config

🚧 Files skipped from review as they are similar to previous changes (1)

• config/sources/families/k3.conf

✨ Finishing Touches

🧪 Generate Unit Tests

• [ ] Create PR with Unit Tests
• [ ] Post Copyable Unit Tests in Comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Explain this complex logic.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai explain this code block.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and explain its main purpose.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai auto-generate unit tests to generate unit tests for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[rpardini]

This will cause inconsistency for .deb/apt repo, although it works for building images. You'd need to create a separate kernel package, so that you've both rt and non-rt .deb's available. Do so by changing LINUXFAMILY. It might be easier to create a BRANCH=k3-rt too.

[jsuhaas22]

@rpardini

This will cause inconsistency for .deb/apt repo, although it works for building images. You'd need to create a separate kernel package, so that you've both rt and non-rt .deb's available. Do so by changing LINUXFAMILY. It might be easier to create a BRANCH=k3-rt too.

Have updated the PR to use LINUXFAMILY. Tested on SK-AM62B; even got the *-rt*.deb packages built.

[glneo]

What happens if someone sets RT_KERNEL=yes but selects a kernel other than current? We would need to keep an RT version of every kernel config. Instead would it be easier to simply add a current-rt BRANCH?

[igorpecovnik]

Also this would be good to be solved generally. Not just for this family, similar as we do it here: https://github.com/armbian/build/blob/main/lib/functions/compilation/armbian-kernel.sh

[jsuhaas22]

@glneo

What happens if someone sets RT_KERNEL=yes but selects a kernel other than current? We would need to keep an RT version of every kernel config. Instead would it be easier to simply add a current-rt BRANCH?

We can do this, yes.

But are we sure we wouldn't want an edge-rt image in the future? If we eventually want to introduce an edge-rt image, then we'd have to introduce another edge-rt branch. It seems easier to just go with the RT_KERNEL build switch method, and add a check somewhere to fail with a proper error message if someone builds RT image for edge. This would also be in-line with Armbian's docs which mention only 3 branches (current, edge, legacy).

But if we don't want edge-rt in the near future, then yeah, I will add a current-rt branch.

[jsuhaas22]

Also this would be good to be solved generally. Not just for this family, similar as we do it here: https://github.com/armbian/build/blob/main/lib/functions/compilation/armbian-kernel.sh

TI kernel uses its own RT config file which overrides many options in the defconfig file. So we'd have to maintain a separate RT config file for TI devices.. I assume its the same with the other families too.

[igorpecovnik]

TI kernel uses its own RT config file which overrides many options in the defconfig file.

Understand. I am just trying to open discussion if something like that is possible - not by maintaining a separate config, but dedicated config override definitions. Just the diff. Maintaining separate configs for (all) other kernel is not possible - we barely manage to maintain default configs.

BTW. I was experimenting some AI assisted config management which could help doing this. In that case, many things become possible. For humans on the project ... there are already too many different configs.

[jsuhaas22]

TI kernel uses its own RT config file which overrides many options in the defconfig file.

Understand. I am just trying to open discussion if something like that is possible - not by maintaining a separate config, but dedicated config override definitions. Just the diff. Maintaining separate configs for (all) other kernel is not possible - we barely manage to maintain default configs.

Personally, I agree. As I said, we maintain override config files inside the TI kernel repository. So building the correct .config is just a matter of doing make ... defconfig <override-config-file>.

If other vendors also have the same flow, then we can just introduce a OVERRIDE_CONFIGS variable. This variable will hold the names of all override-config files that should be appended to the make defconfig command.

By doing so, we move the responsibility of managing kernel configs away from Armbian entirely. Ideally, we shouldn't maintain even diff's as you suggested; all of this should be provided by the vendor kernel itself.

This is just my personal opinion, maybe @glneo can correct me if I am wrong.

Anyway, even if we go ahead with this, it would take time align with the others. In the meantime, we'd have to continue with these individual config files in Armbian.

[igorpecovnik]

we maintain override config

I get that.

If other vendors

Some vendors might do that, but <10%, which means that would fall on us. And this is not something we could possibly afford.

By doing so, we move the responsibility of managing kernel configs away from Armbian entirely.

Even only you will use this functionality, we can find a way to integrate this into Armbian. There is always a way. But one issue was already exposed - if we have a different config, we need a different linux family. We can at least make this part automated - if RT config is uses, a subfamily is automatically generated. If we go for dedicated branch, this could IMO be a temporal solution, unless we go for legacy-rt, current-rt, edge-rt automation. And still there are two ways to achieve this and both can be possible - one is - integrating into framework with switch REALTIME_KERNEL=yes https://github.com/armbian/build/blob/main/lib/functions/compilation/armbian-kernel.sh and maintain it there (if it doesn't have any hw family specific configs) and second, if "rt" config file is used, then family / sub-branch management is automatic.

If there is no rush adding this, lets brainstorm and do it right.

[jsuhaas22]

We can at least make this part automated - if RT config is uses, a subfamily is automatically generated.

if "rt" config file is used, then family / sub-branch management is automatic.

Could you explain what you have in mind? You said you've been experimenting with AI for this, so does that work reliably?

integrating into framework with switch REALTIME_KERNEL=yes https://github.com/armbian/build/blob/main/lib/functions/compilation/armbian-kernel.sh and maintain it there (if it doesn't have any hw family specific configs)

We could move most configs to armbian-kernel.sh, but some board-/family-specific ones would always exist. So we'd have to maintain vendor-maintained diff's at least.

If there is no rush adding this, lets brainstorm and do it right.

I am hoping to have this merged by end of June, so we have a couple of weeks to get this right. So please do elaborate on your automatic generation idea and how we could go about it. There'd be some vendor-specific configs, so our method would have to accommodate that.

If it takes longer than that to implement a better method, then I'd suggest we merge this (with a separate current-rt branch, if you and Andrew prefer it that way) as a temporary measure until we implement the better method. TI will be maintaining its own config files, so it would not be additional effort for you.

[igorpecovnik]

Could you explain what you have in mind?

I am trying to find a way that when RT is used, that we don't overwrite kernel package, carrying the same name, with the RT variant.

You said you've been experimenting with AI for this, so does that work reliably?

To early to tell if this is suitable for production. For example, this config was made with help of AI: https://github.com/armbian/build/blob/main/config/kernel/linux-uefi-arm64-cloud.config from defconfig.

We could move most configs to armbian-kernel.sh, but some board-/family-specific ones would always exist. So we'd have to maintain vendor-maintained diff's at least.

How about this way?

• common RT config options goes to lib/functions/compilation/armbian-kernel.sh
• family specific config options goes to config/sources/families/k3.conf

Both conditioned with ENABLE_RT_KERNEL=yes ARMBIAN_RT_KERNEL=yes or similar

as a temporary measure until we implement the better method.

OK, we can merge this within a week / now as probably generic way ain't be ready by then.

[jsuhaas22]

@igorpecovnik

How about this way?

common RT config options goes to lib/functions/compilation/armbian-kernel.sh family specific config options goes to config/sources/families/k3.conf

Both conditioned with ENABLE_RT_KERNEL=yes ARMBIAN_RT_KERNEL=yes or similar

Yeah, this seems good. No role of AI agents in this, then?

OK, we can merge this within a week / now as probably generic way ain't be ready by then.

Thanks. I have updated this PR with @glneo's suggestion of having a current-rt branch instead of RT_KERNEL build switch. Tested the new change on SK-AM62B.