orangepi5: fix slow boot on current kernel

[EvilOlaf]

Description

During my journey bumping rockchip64 to 7.0 I noticed that my orangepi5 was quite slow with booting and also showed very poor performance on raid6 test during boot. After poking around for quite a while I noticed that some stuff kicked in quite late during boot. Attempted to fix by building in instead of having modules apparently fixed the issue.

This affects both current and edge. However since edge is out for bump I included a fix for this in the respective PR.

• before: https://paste.armbian.com/uhomuwajos (didn't have a 'before' log for 6.18.y handy but the issue is the same).
• after: https://paste.armbian.com/ocarimopey

Interestingly this seem to be an issue for quite a while since the change was introduced in Jan 2024: #6202
I guess it DID apply for rk3588 😀 l @paolosabatino

Since this most likely affects other rockchip64 boards as well this shall be tested on various hw before merge

How Has This Been Tested?

• build
• boot orangepi5: see log above

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

Summary by CodeRabbit

• New Features
  • CPU frequency scaling enabled for dynamic frequency management.
  • USB Type-C controller support now built-in for improved device connectivity.
  • Enhanced network filtering and firewall capabilities.
  • Network address translation and masquerading enabled for IPv4 and IPv6.
  • Bridge networking features added for advanced network configurations.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 54ade91 and e1068c3.

📒 Files selected for processing (1)

• config/kernel/linux-rockchip64-current.config

---

📝 Walkthrough

Walkthrough

This pull request modifies the Rockchip 64-bit Linux kernel configuration file to enable CPU frequency scaling, USB Type-C controller support, and comprehensive netfilter/IPv4/IPv6 NAT, masquerading, and bridge filtering capabilities.

Changes

Cohort / File(s)

Summary

Kernel Configuration config/kernel/linux-rockchip64-current.config

Enabled CPU frequency scaling via CONFIG_CPUFREQ_DT (m→y); promoted USB Type-C controller stack (CONFIG_TYPEC, CONFIG_TYPEC_TCPM, CONFIG_TYPEC_TCPCI, CONFIG_TYPEC_FUSB302) and USB DP PHY (CONFIG_PHY_ROCKCHIP_USBDP) from modules to built-in; added netfilter legacy targets and IPv4/IPv6 NAT/masquerade/redirect functionality (CONFIG_NETFILTER_XTABLES_LEGACY, CONFIG_IP_NF_NAT, CONFIG_IP_NF_TARGET_MASQUERADE, CONFIG_IP6_NF_NAT, etc.); added bridge ebtables legacy and routing support.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 Hops with glee at configs bright,
Type-C power, USB delight!
Networks masked and bridges bold,
Kernel features, strong and rolled!
Rockchip rocketh, fast and true! 🚀

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'orangepi5: fix slow boot on current kernel' directly summarizes the main change: addressing slow boot performance on Orange Pi 5 with the current kernel through kernel configuration modifications.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a 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

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

[igorpecovnik]

Since this most likely affects other rockchip64 boards as well this shall be tested on various hw before merge

I don't see anything suspicious to cause regressions. A few of modules are going back into the kernel and you saw improvements ...

[EvilOlaf]

The odd thing is that it looks like nobody else complained yet. Perhaps because once fully booted it acts normal. Anyway I'd like to wait for Paolo's opinion.

[amazingfate]

What about adding the modules into initramfs instead of making the drivers built-in?

[HeyMeco]

The ones set to build in here in this PR seem to make sense. I'm in favor

[github-actions]

✅ This PR has been reviewed and approved — all set for merge!

[EvilOlaf]

What about adding the modules into initramfs instead of making the drivers built-in?

I guess that would work too but I think editing the kernel config is easier than creating a function or bsp thing to add those modules to initramfs?

[amazingfate]

What about adding the modules into initramfs instead of making the drivers built-in?

I guess that would work too but I think editing the kernel config is easier than creating a function or bsp thing to add those modules to initramfs?

Universal distros like debian prefer modules, and they should have similar issues. This family is aming at a specific platform so make some drivers built-in is fine.

I don't know if I recall it correctly, sometimes rewrite-kernel-config may make some drivers into module.

[EvilOlaf]

I don't know if I recall it correctly, sometimes rewrite-kernel-config may make some drivers into module.

While having no evidence I also believe this may happen sometimes. This is why I also did a rewrite to make sure it stays.

[HeyMeco]

I don't know if I recall it correctly, sometimes rewrite-kernel-config may make some drivers into module.

That should only happen when dependency drivers are set to module. I always check with https://www.kernelconfig.io/CONFIG_R8169 to set the them to y or m depending on what you want to achieve

[rpardini]

After poking around for quite a while I noticed that some stuff kicked in quite late during boot. Attempted to fix by building in instead of having modules apparently fixed the issue.

Sometimes cat /sys/kernel/debug/devices_deferred can help understand.

What about adding the modules into initramfs instead of making the drivers built-in?

I guess that would work too but I think editing the kernel config is easier than creating a function or bsp thing to add those modules to initramfs?

A nest of wasps; initramfs-tools might behave different than dracut or mkosi-initrd on the topic of selecting which modules get put into the initramfs. When building initramfs on the machine itself (eg when apt-upgrading kernel) might give different results than when building an image, as initramfs-tools might consider "what modules has the the host loaded right now". It's headache-inducing, and prone to change soon as fedora -> mkosi, ubuntu -> dracut, and who knows what else. I'd say say just make them required things =y as it is easier -- unless we're hitting vmlinuz/initramfs size limits vs u-boot loadaddr's (and even then, recent u-boots have relocation support).

Universal distros like debian prefer modules, and they should have similar issues. This family is aming at a specific platform so make some drivers built-in is fine.

I don't know if I recall it correctly, sometimes rewrite-kernel-config may make some drivers into module.

Not arbitrarily -- it does what it is told to do (usually in armbian-kernel.sh or hooks in family code) -- a rewrite should reveal if things are changed or not.

[paolosabatino]

@EvilOlaf Hello! I tend to be in accordance with other opinions about putting those modules as built-ins if they solve the slow boot problem. The merge request from 2024 fixed some weird kernel config overhaul happened for some - unknown to me - reason. There I restored the previous rockchip64 kernel configs and advanced them manually, but there are no reasons to stick to those configs if they cause issues since I did not really paid attention to module vs. built-in at that time.

I will run some tests on the next few days on my rorkchip64 boards, but I'm pretty sure there won't be any issues, so for me this is ok to merge as will 👍

[EvilOlaf]

Alright. Thank you everyone for your input.

[paolosabatino]

Had the time to check in for older rockchip64 devices. Both rk3399 and rk3328 works fine. Rk3399 (orangepi4-lts) type-c connector also still works fine (Power Delivery + HDMI + USB tested, both type-c connector orientations)