OrangePi5Pro: Comprehensive HW Support: YT6801 PCIe-Eth, Codec ES8388 Audio, eFUSE & U-Boot v2025.10#9600
Conversation
This commit adds a suite of 4 patches for U-Boot v2025.10 to enable
full support for the Xunlong Orange Pi 5 Pro SBC.
The Orange Pi 5 Pro introduces several significant hardware departures
from the base Orange Pi 5, necessitating specific driver and DTS
adjustments:
1. Networking (Motorcomm YT6801):
- The Pro variant replaces the SoC's built-in GMAC1 NIC with a
PCIe-attached Motorcomm YT6801 controller.
- Introduce a new glue driver (dwc_eth_qos_motorcomm) to bridge
the core DWC EQoS IP to the PCIe bus.
- Core EQoS driver is modified to support the YT6801's unique
32-byte descriptor size and Descriptor Skip Length requirements.
- Auto-generation of MAC addresses from CPU ID is disabled to
preserve the hardware's native eFuse MAC.
2. Audio and I/O:
- Audio routing is moved from I2S1 to I2S2 (M1 mux) with the
ES8388 codec on I2C3.
- LEDs are remapped from GPIO to PWM control (PWM3/PWM15).
- Headphone amplifier enable is remapped to GPIO4_PB5.
3. Thermal and Power:
- PWM Fan control is implemented with a specific 20ms (50Hz)
period. This is CRITICAL because the hardware's RC filter gate
logic causes MOSFET overheating if standard 25kHz PWM is used.
4. Wireless:
- Full support for the AP6256 module via SDIO and UART9.
Patch Summary:
- [0001] Board support (DTS, defconfig, doc). DTS based on initial
submission by Dennis Gilmore.
- [0002] Motorcomm YT6801 PCIe glue driver and PHY support.
- [0003] Core EQoS driver extension for descriptor/DSL overrides.
- [0004] Rockchip board MAC setup bypass for Pro hardware.
Signed-off-by: c127dev <contact@c127.dev>
…rnel
This commit enables full support for the Orange Pi 5 Pro on the current
Linux kernel (rockchip64-6.18). It includes a comprehensive device tree,
board configuration updates, and a series of patches for the PCIe Motorcomm
YT6801 Ethernet controller.
Key additions and modifications:
1. Device Tree Updates (rk3588s-orangepi-5-pro.dts):
- Added support for DisplayPort 1.4 to HDMI 2.0 (DP0/VP2).
- Configured USB3 Type-A ports (with USB2 OTG PHY) and explicitly set the
USB-C port to power-delivery only (no FUSB302/data/alt-mode).
- Configured combphy2_psu for NVMe M.2 slot support by disabling
conflicting USB3 modes.
- Re-mapped fan to PWM2 and LEDs to PWM3/PWM15.
- Added full AP6256 Wi-Fi/Bluetooth support (SDIO and UART9).
2. Motorcomm YT6801 Ethernet Support (Patches 1-5):
- Added generic suspend/resume helper for PCI-based controllers.
- Backported glue driver for Motorcomm YT6801 and YT8531S PHY support.
- Included fixes for eFUSE MAC address read failures.
- Resolved specific stmmac/motorcomm driver compilation errors and
panics on kernel 6.18.
3. Board Configuration (orangepi5pro.csc):
- Refactored U-Boot configuration selection logic, segregating mainline
and vendor branches correctly.
- Configured the Armbian build system to automatically enable the newly
added Motorcomm PHY, STMMAC_ETH, and STMMAC_PLATFORM kernel configs
for the "current" and "edge" branches.
Signed-off-by: c127dev <contact@c127.dev>
This commit enables full support for the Orange Pi 5 Pro on the edge
Linux kernel (rockchip64-7.0). It synchronizes the device tree additions
with the current kernel and includes the necessary eFUSE MAC address fix for
the Motorcomm Ethernet controller.
Key additions and modifications:
1. Device Tree Updates (rk3588s-orangepi-5-pro.dts):
- Added support for DisplayPort 1.4 to HDMI 2.0 (DP0/VP2).
- Configured USB3 Type-A ports (with USB2 OTG PHY) and explicitly set the
USB-C port to power-delivery only (no FUSB302/data/alt-mode).
- Configured combphy2_psu for NVMe M.2 slot support by disabling
conflicting USB3 modes.
- Re-mapped fan to PWM2 and LEDs to PWM3/PWM15.
- Added full AP6256 Wi-Fi/Bluetooth support (SDIO and UART9).
2. Motorcomm YT6801 Ethernet Support (Patches):
- Included fix for Motorcomm YT6801 eFUSE MAC address read failures
on the 7.0 kernel.
Signed-off-by: c127dev <contact@c127.dev>
This commit introduces a patch for the rockchip64 kernel (current 6.18 and edge 7.0 branches) to fix audio routing issues affecting the ES8328 codec. The patch modifies the ASoC es8328 driver to explicitly allow sharing the LRCK (Left/Right Clock) between the microphone and playback interfaces. This is required for hardware designs where capture and playback must share the same clock line. Signed-off-by: c127dev <contact@c127.dev>
c127dev
requested review from
ColorfulRhino,
HeyMeco,
JohnTheCoolingFan,
SuperKali,
TheSnowfield,
Tonymac32,
ahoneybun,
amazingfate,
brentr,
catalinii,
chainsx,
efectn,
igorpecovnik,
joekhoobyar,
krachlatte,
lanefu,
paolosabatino,
prahal,
pyavitz,
rpardini and
schwar3kat
as code owners
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds Orange Pi 5 Pro support and board-specific adjustments: new U‑Boot v2025.10 board and drivers, removal of v2025.07 patchset, Motorcomm YT6801 glue driver and PHY updates, STMMAC PCI helpers, eFUSE MAC-read fixes, ES8328 LRCK probe option, extensive RK3588S device-tree rewrites, and build-hook/config tweaks. Changes
Sequence Diagram(s)sequenceDiagram
participant Boot as U-Boot/Kernel<br/>Boot
participant PCI as PCI Bus
participant Driver as Motorcomm<br/>Glue Driver
participant HW as YT6801<br/>Controller
participant eFUSE as eFUSE<br/>Controller
participant STMMAC as STMMAC<br/>Core Driver
Boot->>PCI: enumerate PCI devices
PCI->>Driver: probe()
Driver->>Driver: map BAR0, enable mem & bus mastering
Driver->>HW: motorcomm_reset()
HW-->>Driver: reset deasserted
Driver->>Driver: usleep_range(15000,20000)
Driver->>Driver: motorcomm_init()
Driver->>eFUSE: motorcomm_efuse_read_mac()
eFUSE->>eFUSE: readl_poll_timeout_atomic()
eFUSE-->>Driver: MAC bytes (or zero)
alt valid eFUSE MAC
Driver->>Driver: use eFUSE MAC
else
Driver->>Driver: generate random MAC
end
Driver->>HW: configure DMA/AXI/core, disable OOB WOL
Driver->>Driver: setup interrupts (MSI-X/MSI)
Driver->>STMMAC: stmmac_dvr_probe()
STMMAC-->>Boot: network available
Estimated code review effort🎯 4 (Complex) | ⏱️ ~65 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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
05
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
config/boards/orangepi5pro.csc (1)
17-18: Consider removing stale commented freeze override once finalized.The commented
KERNEL_UPGRADE_FREEZEline can become misleading over time; dropping it keeps board config intent clearer.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@config/boards/orangepi5pro.csc` around lines 17 - 18, Remove the stale commented configuration line for KERNEL_UPGRADE_FREEZE (the "# KERNEL_UPGRADE_FREEZE=\"vendor-rk35xx@24.8.1\"" entry) from the board config so the intent is not misleading; if you need to preserve the value for history, move it to a changelog or commit message instead of leaving it commented in the file.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@config/boards/orangepi5pro.csc`:
- Around line 17-18: Remove the stale commented configuration line for
KERNEL_UPGRADE_FREEZE (the "# KERNEL_UPGRADE_FREEZE=\"vendor-rk35xx@24.8.1\""
entry) from the board config so the intent is not misleading; if you need to
preserve the value for history, move it to a changelog or commit message instead
of leaving it commented in the file.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c1e6ec24-0b9b-4824-abbe-22e1db47f73f
📒 Files selected for processing (2)
config/boards/orangepi5pro.cscconfig/kernel/linux-rockchip-rk3588-edge.config
…rs, add test targets) Signed-off-by: c127dev <contact@c127.dev>
|
I wonder if the motorcomm driver can be added as module rather than forcing it into the kernel? |
Signed-off-by: c127dev <contact@c127.dev>
Hi EvilOlaf, you are right. Initially I've set it to built-in thinking about network availability inside initramfs for recovery scenarios. However, I forgot realizing the config applies to the entire |
|
✅ This PR has been reviewed and approved — all set for merge! |
|
@c127dev &pcie2x1l1 { Possibly caused by this? I see top is pcie2 but internal is pcie3. |
|
Log after rescan: |
|
Hi @eebssk1, Thanks for the feedback! It's interesting that it requires a manual rescan to appear. This often points to timing issues during the initial PCIe link training or a conflict with the I've refactored the node to a more "failsafe" configuration by removing the Also, could you please provide:
I can provide a testing .deb or a pre-compiled dtb if you prefer, but if you can patch and recompile the DTS locally, it would be great to confirm if this simplified node solves the detection issue. If this fixes it for you, I'll submit a new PR with these stability improvements. |
Thanks for the fix. I'm currently using a rescan script in initramfs early so disk can be used in real system. armbian trunk |
Unfortunately,this fix does not work. |
|
Hmmm... I've been analyzing the Orange Pi 5 Pro schems and comparing them with the recent upstream patch for this board submitted to the mainline kernel just a few days ago. So looking at the M.2 slot schematic, power pins (2, 4, 70, 72, 74) are directly tied to the However, i suspect that some drives often require strict PCIe specification delays (100ms wait after power stable before releasing Let's align exactly with the mainline implementation. By adding Could you please test this block? If it stills failling, probably adding this fixes the issue: This configuration theoretically forces the kernel to respect the regulator timing, giving the drive the milliseconds it needs before the bus enumeration. Let me know how it goes. |
is this correct, because your second block does not compile so I changed a little. 点击展开/Click to show |
|
Oops, I had a clipboard error in my previous snippet regarding the If this still doesn't work, we need to determine if this is a regression or an underlying driver/hardware quirk. Could you try testing with the original DTS (before these commits) to see if the drive behaves the same way? If it also fails on the old DTS, then I strongly suspect the issue goes deeper than the Device Tree. |
the minimal does not work too. |
|
Hmmm... I went back to the schematics, and I have a suspicion about what is causing this. Looking at the RK3588 block diagram, the M.2 slot ( To prove the theory, could you please try testing with this older DTS (from before the USB/DP refactoring)? If patching the DTS doesn't work, I recommend flashing and booting a very old release I made over a year ago which uses that old tree: If the old DTS (or the v0.7 release) detects your SN500 correctly without a rescan, then we have found the exact culprit: the USB3/DP |
Tried your image(wow the image really chocked my serial input much),still no luck. |
|
@c127dev |
Ah, that completely explains it! Since the SN520 failed on the old release as well (and is throwing I/O errors even after a rescan), it definitely points to a hardware quirk or a failing controller on that specific drive, rather than a DTS regression. Thanks for taking the time to test the old image and swapping the drive! |
Thanks for the effort. |
5 participants
Description
This PR brings a comprehensive and stable hardware support for the Orange Pi 5 Pro SBC, bridging the gap between existing partial-support and a almost fully-functional SBC out of the box.
So, previously, the board relied on a
.debpackage installed during the first boot to enable the Motorcomm YT6801 Ethernet controller, which significantly slowed down the initial boot process. (Now 4~5s dmesg) This PR integrates the newly mainlined YT6801 driver directly into thecurrent(6.18) andedge(7.0) kernels, alongside U-Boot v2025.10, fixing several low-level hardware bugs in the process.Key Motivations and Fixes:
reset -> delay -> readsequence that guarantees the eFUSE MAC is correctly read in both U-Boot and the Linux Kernel.v2025.10.es8328ASoC driver to explicitly allow LRCK sharing and added missingMic Biasrouting to the DTS. Both onboard mic and headphone jack now work flawlessly.lore.kernel.org. (Note: v3 and v4 patches currently exhibit PCIe read issues, so v2 was heavily refactored and proven stable). Synced this DTS across U-Boot,current, andedgekernels.Documentation summary for feature / change
If documentation entry is predicted, please provide key elements for further implementation into main documentation and set label to "Needs Documentation".
.debinstallation), enabled full audio support (3.5mm Jack Output and onboard/headset Microphone) via ES8388. Enabled safe PWM Fan control, M.2 NVMe, and AP6256 Wi-Fi/BT.How Has This Been Tested?
Extensive testing was performed across multiple environments to ensure stability in both the bootloader phase and different kernel versions.
Checklist:
Summary by CodeRabbit
New Features
Bug Fixes
Chores