ti: config: kernel: Add current RT config file
#8280
Conversation
WalkthroughA new Linux kernel configuration file named Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
✨ Finishing Touches🧪 Generate Unit Tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed 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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
github-actions
bot
added
08
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
config/kernel/linux-k3-rt-current.config (1)
927-928: Security frameworks disabled for RT performance.SELinux and AppArmor are disabled, which is common in RT kernels to reduce overhead. However, this reduces security posture.
Consider implementing application-level security measures since kernel-level security frameworks are disabled. You may also want to evaluate if mandatory access controls are required for your specific use case and document this security trade-off.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
config/kernel/linux-k3-rt-current.config(1 hunks)config/sources/families/k3.conf(1 hunks)
🔇 Additional comments (5)
config/kernel/linux-k3-rt-current.config (4)
972-976: LGTM! Proper RT kernel configuration.The real-time specific configurations are correctly set:
PREEMPT_RT=yenables full real-time preemptionHZ_1000=yprovides 1ms timer resolution for low latencyNO_HZ_FULL=yenables full tickless operation for isolated CPUsCONTEXT_TRACKING_USER=ysupports user/kernel context trackingThese settings are appropriate for real-time workloads requiring deterministic latency.
81-90: CPU power management correctly disabled for RT.The configuration appropriately disables CPU power management features that can introduce latency jitter:
CPU_IDLE=nprevents CPU from entering idle statesCPU_FREQ=ndisables dynamic frequency scalingCPU_FREQ_GOV_PERFORMANCE=yensures maximum performance modeThis is correct for real-time applications requiring consistent performance.
961-982: Debugging and instrumentation appropriately configured for RT.Most debugging features are disabled to minimize overhead:
SCHED_DEBUG=nremoves scheduler debuggingFTRACE=ndisables function tracingPERF_EVENTS=ndisables performance monitoringSome ARM64 features are also disabled to reduce complexity. This configuration prioritizes deterministic performance over observability.
37-70:❓ Verification inconclusive
Review the disabled ARM64 CPU errata workarounds.
Multiple ARM64 CPU errata workarounds are disabled, which could cause stability issues on affected hardware. While this may reduce overhead for RT performance, it could lead to system instability on vulnerable CPU models.
Please verify that the target TI K3 hardware doesn't require these errata workarounds, or consider enabling the ones relevant to your target platform:
🏁 Script executed:
#!/bin/bash # Check which ARM64 errata are commonly needed for TI K3 platforms echo "Searching for ARM64 errata references in TI K3 related files..." rg -A 3 "ARM64_ERRATUM.*K3|K3.*ARM64_ERRATUM" rg -A 3 "ERRATUM.*AM6" rg -A 3 "erratum.*j721e|j721e.*erratum"Length of output: 251
#!/bin/bash set -e # 1. Check SoC and architecture settings in the K3 RT defconfig echo "Inspecting config/kernel/linux-k3-rt-current.config for SoC/ARCH definitions..." grep -E 'CONFIG_SOC_|CONFIG_ARCH_' config/kernel/linux-k3-rt-current.config || true # 2. List any device-tree source files in the repo echo -e "\nFound .dts files:" fd --extension dts || true # 3. Search those DTS files for TI K3/AM6-compatible strings echo -e "\nSearching .dts files for TI K3/AM6 SoC identifiers..." fd --extension dts -x rg -H -n 'compatible.*ti,(j721e|j7200|am6|am62)' {}
#!/bin/bash set -e # 1. Search for AM6 references in arch/arm64 Kconfig echo "Searching for AM6 in arch/arm64/Kconfig..." rg -n "AM6" arch/arm64/Kconfig || true # 2. Search for ARM64 errata entries in the CPU feature Kconfig echo -e "\nSearching for ARM64_ERRATUM in arch/arm64/cpufeature/Kconfig..." rg -n "ARM64_ERRATUM" arch/arm64/cpufeature/Kconfig || true # 3. Search device-tree source files for TI K3 SoC identifiers (j721e, j7200, am6) echo -e "\nSearching .dts files for TI K3 compatible strings..." rg -n "compatible.*ti,(j721e|j7200|am6|am62)" --glob '*.dts' || true # 4. As a fallback, look for any mention of j721e/j7200 across the repo echo -e "\nSearching for j721e/j7200 mentions in repository..." rg -n "j721e|j7200" || true
Verify ARM64 CPU Errata for TI K3
We didn’t find any TI K3–specific erratum references in the config or DTS files; please manually confirm that none of the disabled workarounds are required for your SoC (J721E/J7200/AM6):• Check arch/arm64/cpufeature/Kconfig for any ERRATUM entries targeting the Cortex-A cores used on TI K3.
• Inspect your device-tree (.dts/.dtsi) forcompatible = "ti,j721e","ti,j7200","ti,am62", etc., and cross-reference against the ARM64_ERRATUM_* options.
• Consult the TI K3 Technical Reference Manual or errata sheets to determine which CPU errata workarounds are mandatory for your silicon revision.If any apply, enable them in your config to avoid potential stability issues.
config/sources/families/k3.conf (1)
23-26: LGTM! Clean conditional logic for RT kernel selection.The implementation correctly:
- Checks for
RT_KERNEL=yesenvironment variable- Provides user feedback with
display_alert- Sets
LINUXCONFIGto use the new RT configuration- Uses proper bash conditional syntax with
[[ ]]The placement before the
BRANCHcase statement ensures the RT configuration takes precedence when requested.
|
This will cause inconsistency for .deb/apt repo, although it works for building images. |
TI SDK supports images with real-time kernel. Add support for building such images for the `current` release by adding a config file for it. Signed-off-by: Suhaas Joshi <s-joshi@ti.com>
Have updated the PR to use LINUXFAMILY. Tested on SK-AM62B; even got the *-rt*.deb packages built. |
|
What happens if someone sets |
|
Also this would be good to be solved generally. Not just for this family, similar as we do it here: |
igorpecovnik
added
Discussion
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 ( But if we don't want edge-rt in the near future, then yeah, I will add a |
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. |
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. |
Personally, I agree. 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 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. |
I get that.
Some vendors might do that, but <10%, which means that would fall on us. And this is not something we could possibly afford.
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. |
Could you explain what you have in mind? You said you've been experimenting with AI for this, so does that work reliably?
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.
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 |
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 -atest: PREEMPT_RT string was present in the output, thus suggesting that its indeed an RT imageTest 3:
zcat /proc/config.gz | grep -i RT: Further confirmed that the PREEMPT_RT config is enabled in the running imageChecklist:
Please delete options that are not relevant.
cc: @glneo @Grippy98 @nmenon @sadik-smd