rockchip64: add edge kernel support for Youyeetoo YY3588 #9137
+1,242
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
SuperKali
requested review from
ColorfulRhino,
HeyMeco,
JohnTheCoolingFan,
TheSnowfield,
Tonymac32,
ahoneybun,
amazingfate,
brentr,
catalinii,
chainsx,
efectn,
igorpecovnik,
joekhoobyar,
krachlatte,
lanefu,
paolosabatino,
prahal,
pyavitz,
rpardini and
schwar3kat
as code owners
Contributor
📝 WalkthroughWalkthroughUpdated the Youyeetoo YY3588 board to build with both "vendor" and "edge" kernels and added a new RK3588 device tree source describing the board's hardware topology (regulators, audio, USB‑C PD, PCIe, Ethernet, HDMI, I2C/SPI, thermal, etc.). Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
🧰 Additional context used🧠 Learnings (12)📓 Common learnings📚 Learning: 2025-11-02T20:49:56.719ZApplied to files:
📚 Learning: 2025-10-26T10:41:35.118ZApplied to files:
📚 Learning: 2025-11-10T22:05:40.490ZApplied to files:
📚 Learning: 2025-08-21T08:10:59.502ZApplied to files:
📚 Learning: 2025-12-12T23:10:00.819ZApplied to files:
📚 Learning: 2025-06-25T03:42:09.086ZApplied to files:
📚 Learning: 2025-09-14T06:29:18.958ZApplied to files:
📚 Learning: 2025-08-02T05:46:10.664ZApplied to files:
📚 Learning: 2025-09-12T09:49:31.957ZApplied to files:
📚 Learning: 2025-10-13T02:26:18.249ZApplied to files:
📚 Learning: 2025-08-21T08:10:25.459ZApplied to files:
🔇 Additional comments (1)
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. Comment |
github-actions
bot
added
size/large
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
patch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts (1)
666-671: Minor: Non-standardpinctrl-names = "active"for PWM2.The typical convention is
pinctrl-names = "default"for the operational pinctrl state. The PWM driver should still work, but"active"is an unusual choice. Consider changing to"default"for consistency with other device nodes.Suggested change
/* PWN2 - Fan */ &pwm2 { - pinctrl-names = "active"; + pinctrl-names = "default"; pinctrl-0 = <&pwm2m2_pins>; status = "okay"; };
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
config/boards/youyeetoo-yy3588.cscpatch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
🧰 Additional context used
🧠 Learnings (19)
📓 Common learnings
Learnt from: HackingGate
Repo: armbian/build PR: 8665
File: config/boards/photonicat2.csc:4-4
Timestamp: 2025-10-26T10:41:35.118Z
Learning: In the Armbian build system, rk3576 boards consistently use BOARDFAMILY="rk35xx" for both vendor and edge kernel targets. The rk35xx family configuration sources rockchip64_common.inc, which provides edge and current kernel branch definitions, making these branches available even though they're not defined directly in rk35xx.conf.
Learnt from: rpardini
Repo: armbian/build PR: 8879
File: config/sources/families/uefi-x86.conf:0-0
Timestamp: 2025-11-06T15:36:04.682Z
Learning: As of PR #8879, the uefi-x86 family in the Armbian build system now includes kernel patches for the first time. The current and edge branches for uefi-x86 are specifically configured for Apple T2-based x86 machines, including T2-specific patches from the linux-t2 project and custom kernel configuration options for Apple hardware drivers.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.
Learnt from: igorpecovnik
Repo: armbian/build PR: 8789
File: config/kernel/linux-sunxi64-edge.config:839-839
Timestamp: 2025-10-22T07:51:53.015Z
Learning: In Armbian's wireless driver configuration, CONFIG_RK_WIFI_DEVICE_* options are Rockchip-specific device registration settings, while CONFIG_WLAN_UWE* are the actual cross-platform driver modules for UWE5622 wireless chips. The UWE5622 chip (manufactured by Unisoc/Spreadtrum) is used on multiple Allwinner boards including Orange Pi Zero 2/2W/3 and Orange Pi 3 LTS, so CONFIG_WLAN_UWE5621/5622 along with Unisoc infrastructure options (CONFIG_SPARD_WLAN_SUPPORT, CONFIG_SC23XX, CONFIG_UNISOC_WIFI_PS, CONFIG_WCN_BSP_DRIVER_BUILDIN) are correct in sunxi64 kernel configs.
Learnt from: tabrisnet
Repo: armbian/build PR: 8746
File: config/sources/families/filogic.conf:61-68
Timestamp: 2025-10-13T02:26:18.249Z
Learning: In the Armbian build system, the "edge" kernel branch is intended to be bleeding-edge and experimental. It does not require hardware testing or stability verification before merging, as it's expected to contain potentially unstable or untested code for early adopters and developers.
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.
Learnt from: tabrisnet
Repo: armbian/build PR: 8913
File: config/sources/families/k3-beagle.conf:16-16
Timestamp: 2025-11-10T22:05:40.490Z
Learning: In the Armbian build system, kernel branches using non-mainline/vendor forks (like BeagleBoard's linux repository) should be named "vendor" or "vendor-rt" rather than "current" or "edge". The "current" and "edge" naming is reserved for mainline kernel branches. This affects both the case statement in family config files (e.g., `vendor | vendor-rt)` instead of `current | current-rt)`) and the corresponding KERNEL_TARGET declarations in board config files.
Learnt from: tabrisnet
Repo: armbian/build PR: 9058
File: config/sources/families/spacemit.conf:39-45
Timestamp: 2025-12-12T23:10:00.819Z
Learning: In the Armbian build system, vendor kernel forks can use "vendor-edge" branch naming for bleeding-edge or pre-release vendor kernels, as demonstrated in config/sources/families/k3.conf. The typical vendor branch naming pattern is: "vendor" or "vendor-rt" for stable vendor releases, and "vendor-edge" for bleeding-edge/pre-release vendor versions. The "edge" naming without "vendor-" prefix is reserved for mainline kernel branches.
Learnt from: SuperKali
Repo: armbian/build PR: 8608
File: lib/functions/compilation/patch/drivers_network.sh:361-363
Timestamp: 2025-09-11T06:06:52.328Z
Learning: For the RTW88 SDIO RF path detection fix patch (004-rtw88-sdio-rf-path-detection-fix.patch), SuperKali prefers using exact version matching (eq 6.1 || eq 6.16) rather than range checks, as the patch has only been tested on those specific kernel versions and may be mainstreamed soon.
📚 Learning: 2025-11-02T20:49:56.719Z
Learnt from: igorpecovnik
Repo: armbian/build PR: 8849
File: config/boards/radxa-e54c.csc:14-28
Timestamp: 2025-11-02T20:49:56.719Z
Learning: In Armbian board configuration files (config/boards/*.conf, *.csc, etc.), do not use kernel_config_set, kernel_config_set_m, kernel_config_set_y, or custom_kernel_config__* functions to modify kernel configuration. Kernel configuration is associated with LINUXFAMILY/BOARDFAMILY, not individual BOARD. Board-specific kernel modifications cause inconsistency in kernel packages published to the apt repository because boards within a family share the same kernel packages. Kernel configuration changes must be made in the appropriate kernel config file (e.g., config/kernel/linux-*-*.config) or in family configuration files (config/sources/families/*.conf, *.inc) instead.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-10-26T10:41:35.118Z
Learnt from: HackingGate
Repo: armbian/build PR: 8665
File: config/boards/photonicat2.csc:4-4
Timestamp: 2025-10-26T10:41:35.118Z
Learning: In the Armbian build system, rk3576 boards consistently use BOARDFAMILY="rk35xx" for both vendor and edge kernel targets. The rk35xx family configuration sources rockchip64_common.inc, which provides edge and current kernel branch definitions, making these branches available even though they're not defined directly in rk35xx.conf.
Applied to files:
config/boards/youyeetoo-yy3588.cscpatch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
📚 Learning: 2025-11-10T22:05:40.490Z
Learnt from: tabrisnet
Repo: armbian/build PR: 8913
File: config/sources/families/k3-beagle.conf:16-16
Timestamp: 2025-11-10T22:05:40.490Z
Learning: In the Armbian build system, kernel branches using non-mainline/vendor forks (like BeagleBoard's linux repository) should be named "vendor" or "vendor-rt" rather than "current" or "edge". The "current" and "edge" naming is reserved for mainline kernel branches. This affects both the case statement in family config files (e.g., `vendor | vendor-rt)` instead of `current | current-rt)`) and the corresponding KERNEL_TARGET declarations in board config files.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-08-21T08:10:59.502Z
Learnt from: leggewie
Repo: armbian/build PR: 8524
File: config/boards/orangepi2.csc:6-6
Timestamp: 2025-08-21T08:10:59.502Z
Learning: Not all Armbian boards support all kernel versions (legacy, current, edge). Some boards may only support specific kernel versions due to hardware limitations or lack of mainline support, which is why their KERNEL_TARGET contains only the supported options (e.g., just "legacy").
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-12-12T23:10:00.819Z
Learnt from: tabrisnet
Repo: armbian/build PR: 9058
File: config/sources/families/spacemit.conf:39-45
Timestamp: 2025-12-12T23:10:00.819Z
Learning: In the Armbian build system, vendor kernel forks can use "vendor-edge" branch naming for bleeding-edge or pre-release vendor kernels, as demonstrated in config/sources/families/k3.conf. The typical vendor branch naming pattern is: "vendor" or "vendor-rt" for stable vendor releases, and "vendor-edge" for bleeding-edge/pre-release vendor versions. The "edge" naming without "vendor-" prefix is reserved for mainline kernel branches.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-06-25T03:42:09.086Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:42:09.086Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, KERNELSOURCE is explicitly declared when using unofficial or 3rd party kernel repositories (like the "dev" branch using https://github.com/apritzel/linux), but can be omitted when using the standard mainline kernel (like the "edge" branch) since it will fall back to the default mainline source.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-09-14T06:29:18.958Z
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-08-02T05:46:10.664Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-08-02T05:46:10.664Z
Learning: In the Armbian build system, the modern recommended approach for kernel configuration is to use the kernel-config command via "./compile.sh BOARD=boardname BRANCH=branchname kernel-config" instead of the deprecated KERNEL_CONFIGURE=yes flag. This provides a two-step workflow: configure using menuconfig, then build, with better transparency and control over configuration changes.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-09-12T09:49:31.957Z
Learnt from: amazingfate
Repo: armbian/build PR: 8617
File: lib/functions/compilation/kernel.sh:126-127
Timestamp: 2025-09-12T09:49:31.957Z
Learning: In the Armbian build system, the "all" target in kernel build has been used for a long time without issues. The "all" target builds vmlinux/Image/Image.gz defaults for the architecture and works correctly alongside KERNEL_IMAGE_TYPE in the build_targets_build array.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-10-13T02:26:18.249Z
Learnt from: tabrisnet
Repo: armbian/build PR: 8746
File: config/sources/families/filogic.conf:61-68
Timestamp: 2025-10-13T02:26:18.249Z
Learning: In the Armbian build system, the "edge" kernel branch is intended to be bleeding-edge and experimental. It does not require hardware testing or stability verification before merging, as it's expected to contain potentially unstable or untested code for early adopters and developers.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-08-21T08:10:25.459Z
Learnt from: leggewie
Repo: armbian/build PR: 8524
File: config/boards/nanopiduo2.csc:12-12
Timestamp: 2025-08-21T08:10:25.459Z
Learning: KERNEL_TARGET and KERNEL_TEST_TARGET in Armbian build system do not have enforced validation relationships. KERNEL_TARGET is used for interactive menu ordering and branch validation, while KERNEL_TEST_TARGET is used for build list generation and recorded in /etc/armbian-release. No existing codebase validation enforces that KERNEL_TEST_TARGET values must be present in KERNEL_TARGET.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-12-17T05:09:02.306Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.
Applied to files:
patch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
📚 Learning: 2025-11-08T06:39:24.527Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
Applied to files:
patch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
📚 Learning: 2025-12-23T04:44:25.212Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 9067
File: patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts:869-875
Timestamp: 2025-12-23T04:44:25.212Z
Learning: During code reviews of device tree changes (any .dts file), verify node properties against the official kernel device tree binding documentation (*.yaml) rather than relying solely on patterns observed in existing DTS files. This helps catch copy-paste or drift errors and ensures properties align with authoritative bindings for each device node type.
Applied to files:
patch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
📚 Learning: 2025-11-15T14:33:30.654Z
Learnt from: SuperKali
Repo: armbian/build PR: 8936
File: patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts:800-802
Timestamp: 2025-11-15T14:33:30.654Z
Learning: In RK3576 device tree files (like rk3576-nanopi-r76s.dts), the serial0 alias is already defined in the upstream kernel's rk3576.dtsi base file, so board-specific DTS files do not need to redeclare it when enabling &uart0 for serial console.
Applied to files:
patch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
📚 Learning: 2025-11-20T18:20:11.985Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.
Applied to files:
patch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
📚 Learning: 2025-12-19T13:56:45.124Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Applied to files:
patch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
📚 Learning: 2025-09-14T06:32:29.806Z
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.
Applied to files:
patch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
🔇 Additional comments (21)
config/boards/youyeetoo-yy3588.csc (2)
8-8: LGTM!The addition of
edgetoKERNEL_TARGETis correct. Therockchip-rk3588family inherits edge kernel branch definitions fromrockchip64_common.inc, and the corresponding mainline device tree is provided in therockchip64-6.18patch directory. Based on learnings, "edge" naming is appropriate for mainline kernel branches.
17-28: Minor observation: HDMI1 audio rule may be unused.The PR description notes that HDMI1 is not present on this board, yet the udev rules include
hdmi1-sound. This is harmless but could be cleaned up for clarity. Since this code is pre-existing and not part of the current changes, this is just a note for potential future cleanup.patch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts (19)
1-31: LGTM!The header, model/compatible strings, aliases, and chosen node follow standard RK3588 mainline DTS conventions. The license (GPL-2.0+ OR MIT) is appropriate, and the alias mappings correctly reference the RTL8125 PCIe NIC as primary ethernet and GMAC1 as secondary.
33-64: LGTM!The ADC keys configuration follows the standard
adc-keysbinding with properly ordered threshold voltages (descending from keyup to vol-up). TheKEY_*macros are correctly used from the included<dt-bindings/input/input.h>.
66-108: LGTM!The ES8323 audio codec integration using
simple-audio-cardfollows standard patterns. The audio routing correctly separates headphone outputs (LOUT2/ROUT2) from speaker amplifier inputs (LOUT1/ROUT1), with proper headphone detection GPIO and speaker amplifier enable control.
110-116: LGTM!The PWM fan configuration with 6 cooling levels is standard. The fan is properly linked to thermal management via the cooling-maps defined later in the file.
238-246: Verify:vcc5v0_hostregulator has novin-supplyor GPIO control.This regulator is defined as always-on/boot-on but lacks a
vin-supplyor GPIO to control it. This pattern is sometimes used for board-level power rails that are always present, but verify this matches the actual hardware design where this 5V rail is directly powered without software control.
278-322: LGTM!The combo PHY enablement and CPU power supply assignments follow the standard RK3588 tri-cluster configuration: LITTLE cores (l0-l3) on
vdd_cpu_lit_s0, big cluster 0 (b0-b1) onvdd_cpu_big0_s0, and big cluster 1 (b2-b3) onvdd_cpu_big1_s0.
324-340: LGTM!The GMAC1 configuration for RTL8211F PHY follows standard patterns: RGMII-RXID mode with internal RX clock delay, appropriate TX delay (0x43), and proper reset GPIO timing.
342-380: LGTM!The GPU and HDMI configuration is correct. Only HDMI0 is enabled (matching the hardware description), with proper VOP2 endpoint linkage. The HDMI receiver enables video input functionality with appropriate HPD GPIO.
481-517: LGTM!The USB-C connector definition is comprehensive with proper dual-role configuration, PD sink/source profiles, and correct port mappings for high-speed, super-speed, and SBU lanes linking to the USBDP PHY endpoints.
542-574: LGTM!The I2S and MDIO configurations are correct. I2S0 connects to the ES8323 codec, I2S5-7 support HDMI audio paths, and MDIO1 properly defines the RGMII PHY at address 0x1.
576-615: LGTM!The PCIe configuration properly allocates lanes: PCIe 2.0 x1 for WiFi and RTL8125 2.5GbE, and PCIe 3.0 x4 for NVMe. The RTL8125 device node definition enables the
ethernet0alias mapping.
633-636: Note: GPIO1_PB4 used for both PCIe reset and clkreqn pinctrl.This GPIO is configured in both
pcie30x4_clkreqn_m1pinctrl and asreset-gpiosforpcie3x4. This is a known RK3588 pattern where the CLKREQ# pin is multiplexed with the reset function during initialization. The configuration appears intentional.
709-741: LGTM!The storage configuration is well-structured: eMMC with HS400 enhanced strobe at 200MHz, SD card with UHS-SDR104 at 150MHz, and SFC correctly disabled to avoid the UART7 pin conflict as documented.
743-1068: LGTM!The RK806 SPI PMIC configuration is comprehensive with proper supply chain definitions, all required DCDC/PLDO/NLDO regulators, suspend state management, and DVS pin configuration. This follows the standard RK3588 power management architecture.
1070-1102: LGTM!The thermal management configuration properly integrates with the PWM fan: two temperature thresholds (55°C and 65°C) with appropriate hysteresis and cooling level mappings for progressive fan speed control.
1104-1139: LGTM!The USB 2.0 PHY configuration properly enables all four PHYs with appropriate power supplies. The
rockchip,typec-vbus-detproperty onu2phy0_otgcorrectly enables USB-C VBUS detection.
1141-1163: LGTM!The UART configuration enables the debug console (uart2) and additional UARTs. UART7 is properly enabled now that SFC is disabled to resolve the pin conflict.
1165-1225: LGTM!The USB host controller configuration is comprehensive: USB-C with role-switch via XHCI and USBDP PHY0 (with orientation switching and SBU DC detection), plus USB 3.0 host via USBDP PHY1 with DP lane muxing.
1227-1243: LGTM!The VOP2 configuration correctly maps VP0 to HDMI0 output with proper endpoint linkage. The single video output path matches the hardware description.
patch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
Outdated
Show resolved
Hide resolved
- Add mainline device tree for YY3588 board - Enable all peripherals: USB 3.0, Ethernet, PCIe, HDMI, audio - Configure ES8323 audio codec with speaker amplifier - Add RK8602 PMIC regulators for CPU/NPU power - Enable I2C buses for PMIC, RTC, and audio codec - Fix pinctrl conflicts (I2C1 M2, disable SFC for UART7) - Configure USB-C and USB 3.0 host ports - Add HDMI0 output with HDPTX PHY - Enable thermal management with PWM fan - Add SD card and eMMC storage support - Configure all UARTs, I2S audio, and SPI buses
SuperKali
force-pushed
the
yy3588-edge
branch
from
42b41d0 to
5231dd5
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
config/boards/youyeetoo-yy3588.csc (1)
17-28: Remove unnecessary HDMI1 audio rule.Line 22 creates a udev rule for HDMI1 audio, but the PR description explicitly states "single HDMI0 output (HDMI1 absent)" and "HDMI1 not present". Since this hardware lacks HDMI1, the rule is unnecessary and misleading.
🔎 Proposed fix to remove HDMI1 audio rule
function post_family_tweaks__youyeetoo_yy3588_naming_audios() { display_alert "$BOARD" "Renaming Youyeetoo YY3588 audios" "info" mkdir -p $SDCARD/etc/udev/rules.d/ echo 'SUBSYSTEM=="sound", ENV{ID_PATH}=="platform-hdmi0-sound", ENV{SOUND_DESCRIPTION}="HDMI0 Audio"' > $SDCARD/etc/udev/rules.d/90-naming-audios.rules - echo 'SUBSYSTEM=="sound", ENV{ID_PATH}=="platform-hdmi1-sound", ENV{SOUND_DESCRIPTION}="HDMI1 Audio"' >> $SDCARD/etc/udev/rules.d/90-naming-audios.rules echo 'SUBSYSTEM=="sound", ENV{ID_PATH}=="platform-hdmiin-sound", ENV{SOUND_DESCRIPTION}="HDMI-In Audio"' >> $SDCARD/etc/udev/rules.d/90-naming-audios.rules echo 'SUBSYSTEM=="sound", ENV{ID_PATH}=="platform-dp0-sound", ENV{SOUND_DESCRIPTION}="DP0 Audio"' >> $SDCARD/etc/udev/rules.d/90-naming-audios.rules echo 'SUBSYSTEM=="sound", ENV{ID_PATH}=="platform-es8323-sound", ENV{SOUND_DESCRIPTION}="ES8323 Audio"' >> $SDCARD/etc/udev/rules.d/90-naming-audios.rules return 0 }
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
config/boards/youyeetoo-yy3588.cscpatch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
🚧 Files skipped from review as they are similar to previous changes (1)
- patch/kernel/archive/rockchip64-6.18/dt/rk3588-youyeetoo-yy3588.dts
🧰 Additional context used
🧠 Learnings (12)
📓 Common learnings
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub or the PR API to get the complete picture of what files are being added or modified.
Learnt from: HackingGate
Repo: armbian/build PR: 8665
File: config/boards/photonicat2.csc:4-4
Timestamp: 2025-10-26T10:41:35.118Z
Learning: In the Armbian build system, rk3576 boards consistently use BOARDFAMILY="rk35xx" for both vendor and edge kernel targets. The rk35xx family configuration sources rockchip64_common.inc, which provides edge and current kernel branch definitions, making these branches available even though they're not defined directly in rk35xx.conf.
Learnt from: rpardini
Repo: armbian/build PR: 8879
File: config/sources/families/uefi-x86.conf:0-0
Timestamp: 2025-11-06T15:36:04.682Z
Learning: As of PR #8879, the uefi-x86 family in the Armbian build system now includes kernel patches for the first time. The current and edge branches for uefi-x86 are specifically configured for Apple T2-based x86 machines, including T2-specific patches from the linux-t2 project and custom kernel configuration options for Apple hardware drivers.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub API (https://api.github.com/repos/armbian/build/pulls/{pr_number}/files) to get the complete picture of what files are being added or modified, especially for U-Boot patches that will be applied during the build process.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.
Learnt from: SuperKali
Repo: armbian/build PR: 8608
File: lib/functions/compilation/patch/drivers_network.sh:361-363
Timestamp: 2025-09-11T06:06:52.328Z
Learning: For the RTW88 SDIO RF path detection fix patch (004-rtw88-sdio-rf-path-detection-fix.patch), SuperKali prefers using exact version matching (eq 6.1 || eq 6.16) rather than range checks, as the patch has only been tested on those specific kernel versions and may be mainstreamed soon.
📚 Learning: 2025-11-02T20:49:56.719Z
Learnt from: igorpecovnik
Repo: armbian/build PR: 8849
File: config/boards/radxa-e54c.csc:14-28
Timestamp: 2025-11-02T20:49:56.719Z
Learning: In Armbian board configuration files (config/boards/*.conf, *.csc, etc.), do not use kernel_config_set, kernel_config_set_m, kernel_config_set_y, or custom_kernel_config__* functions to modify kernel configuration. Kernel configuration is associated with LINUXFAMILY/BOARDFAMILY, not individual BOARD. Board-specific kernel modifications cause inconsistency in kernel packages published to the apt repository because boards within a family share the same kernel packages. Kernel configuration changes must be made in the appropriate kernel config file (e.g., config/kernel/linux-*-*.config) or in family configuration files (config/sources/families/*.conf, *.inc) instead.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-10-26T10:41:35.118Z
Learnt from: HackingGate
Repo: armbian/build PR: 8665
File: config/boards/photonicat2.csc:4-4
Timestamp: 2025-10-26T10:41:35.118Z
Learning: In the Armbian build system, rk3576 boards consistently use BOARDFAMILY="rk35xx" for both vendor and edge kernel targets. The rk35xx family configuration sources rockchip64_common.inc, which provides edge and current kernel branch definitions, making these branches available even though they're not defined directly in rk35xx.conf.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-11-10T22:05:40.490Z
Learnt from: tabrisnet
Repo: armbian/build PR: 8913
File: config/sources/families/k3-beagle.conf:16-16
Timestamp: 2025-11-10T22:05:40.490Z
Learning: In the Armbian build system, kernel branches using non-mainline/vendor forks (like BeagleBoard's linux repository) should be named "vendor" or "vendor-rt" rather than "current" or "edge". The "current" and "edge" naming is reserved for mainline kernel branches. This affects both the case statement in family config files (e.g., `vendor | vendor-rt)` instead of `current | current-rt)`) and the corresponding KERNEL_TARGET declarations in board config files.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-08-21T08:10:59.502Z
Learnt from: leggewie
Repo: armbian/build PR: 8524
File: config/boards/orangepi2.csc:6-6
Timestamp: 2025-08-21T08:10:59.502Z
Learning: Not all Armbian boards support all kernel versions (legacy, current, edge). Some boards may only support specific kernel versions due to hardware limitations or lack of mainline support, which is why their KERNEL_TARGET contains only the supported options (e.g., just "legacy").
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-12-12T23:10:00.819Z
Learnt from: tabrisnet
Repo: armbian/build PR: 9058
File: config/sources/families/spacemit.conf:39-45
Timestamp: 2025-12-12T23:10:00.819Z
Learning: In the Armbian build system, vendor kernel forks can use "vendor-edge" branch naming for bleeding-edge or pre-release vendor kernels, as demonstrated in config/sources/families/k3.conf. The typical vendor branch naming pattern is: "vendor" or "vendor-rt" for stable vendor releases, and "vendor-edge" for bleeding-edge/pre-release vendor versions. The "edge" naming without "vendor-" prefix is reserved for mainline kernel branches.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-06-25T03:42:09.086Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:42:09.086Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, KERNELSOURCE is explicitly declared when using unofficial or 3rd party kernel repositories (like the "dev" branch using https://github.com/apritzel/linux), but can be omitted when using the standard mainline kernel (like the "edge" branch) since it will fall back to the default mainline source.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-09-14T06:29:18.958Z
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-08-02T05:46:10.664Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-08-02T05:46:10.664Z
Learning: In the Armbian build system, the modern recommended approach for kernel configuration is to use the kernel-config command via "./compile.sh BOARD=boardname BRANCH=branchname kernel-config" instead of the deprecated KERNEL_CONFIGURE=yes flag. This provides a two-step workflow: configure using menuconfig, then build, with better transparency and control over configuration changes.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-09-12T09:49:31.957Z
Learnt from: amazingfate
Repo: armbian/build PR: 8617
File: lib/functions/compilation/kernel.sh:126-127
Timestamp: 2025-09-12T09:49:31.957Z
Learning: In the Armbian build system, the "all" target in kernel build has been used for a long time without issues. The "all" target builds vmlinux/Image/Image.gz defaults for the architecture and works correctly alongside KERNEL_IMAGE_TYPE in the build_targets_build array.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-10-13T02:26:18.249Z
Learnt from: tabrisnet
Repo: armbian/build PR: 8746
File: config/sources/families/filogic.conf:61-68
Timestamp: 2025-10-13T02:26:18.249Z
Learning: In the Armbian build system, the "edge" kernel branch is intended to be bleeding-edge and experimental. It does not require hardware testing or stability verification before merging, as it's expected to contain potentially unstable or untested code for early adopters and developers.
Applied to files:
config/boards/youyeetoo-yy3588.csc
📚 Learning: 2025-08-21T08:10:25.459Z
Learnt from: leggewie
Repo: armbian/build PR: 8524
File: config/boards/nanopiduo2.csc:12-12
Timestamp: 2025-08-21T08:10:25.459Z
Learning: KERNEL_TARGET and KERNEL_TEST_TARGET in Armbian build system do not have enforced validation relationships. KERNEL_TARGET is used for interactive menu ordering and branch validation, while KERNEL_TEST_TARGET is used for build list generation and recorded in /etc/armbian-release. No existing codebase validation enforces that KERNEL_TEST_TARGET values must be present in KERNEL_TARGET.
Applied to files:
config/boards/youyeetoo-yy3588.csc
🔇 Additional comments (1)
config/boards/youyeetoo-yy3588.csc (1)
8-8: Adding edge kernel target looks correct.The addition of "edge" to KERNEL_TARGET aligns with the PR objective of adding mainline kernel 6.18 support for this board. The rockchip-rk3588 family inherits edge branch support from rockchip64_common.inc with proper kernel 6.18 configuration, and the corresponding device tree file exists in the patch directory.
rpardini
approved these changes
Dec 28, 2025
Member
rpardini
left a comment
rpardini
left a comment
There was a problem hiding this comment.
Nice. If mainline DT is working well then getting mainline u-boot should be quite simple too, check v2026.01directory as that has simple dt/ et al folders for patch-less u-boot.
Member
Author
|
@rpardini I’m still working on this PR, I have a problem with the audio driver es8323, it’s seen by the kernel but I don’t have any audio output either from the headphones or from the speaker, I’m looking for a solution because in the R1 model this problem had been solved. |
Member
Author
|
Do not merge it, il will merge it after an audio fix. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Add edge (mainline) kernel support for Youyeetoo YY3588 RK3588 board. This change enables the 6.18 kernel by adding a complete mainline device tree based on vendor DTS adapted for mainline kernel bindings.
Main changes:
rk3588-youyeetoo-yy3588.dtswith all peripherals enabledHow Has This Been Tested?
Tested on: Youyeetoo YY3588 with kernel 6.18
Checklist:
Summary by CodeRabbit
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.