| Message ID | 20250220041010.3801-1-honyuenkwun@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Orange Pi 5 Ultra | expand |
On Wed, Feb 19, 2025, Jimmy Hon <honyuenkwun@gmail.com> wrote:
> This patchset is looking for testers. I do not have the hardware to test.
I do have hardware and I gave your branch[1] a test.
The following things tested successfully for me:
- Kernel boots
- Ethernet
- SPI NOR
- Micro SD card
- eMMC
- Bottom M.2 M-key slot (using an NVME drive)
- USB 2.0 ports
- Blue LED (using heartbeat trigger at least)
I did not test:
- RTC
- UART
- HDMI1
- HDMI IN
- Analog audio
- Mali GPU
- Heat sink fan
However, neither of the USB 3.0 ports work. There are no XHCI messages
during boot. I confirmed my kernel config does build XHCI. I haven't
ruled out a mistake on my end yet.
Also, the green LED is constantly lit even when the trigger is set to
none and the brightness is set to 0. This made is a bit harder to
confirm that the blue LED was working. I haven't ruled out a mistake on
my end for this one yet either.
I'll also see if I can give HDMI a test.
JE
[1] https://github.com/jimmyhon/linux/tree/integrate-6.15
On Fri, Feb 21, 2025 at 5:13 PM Johannes Erdfelt <johannes@erdfelt.com> wrote: > > On Wed, Feb 19, 2025, Jimmy Hon <honyuenkwun@gmail.com> wrote: > > This patchset is looking for testers. I do not have the hardware to test. > > I do have hardware and I gave your branch[1] a test. Thanks for the test results > > The following things tested successfully for me: > - Kernel boots > - Ethernet > - SPI NOR > - Micro SD card > - eMMC > - Bottom M.2 M-key slot (using an NVME drive) > - USB 2.0 ports > - Blue LED (using heartbeat trigger at least) > > I did not test: > - RTC > - UART > - HDMI1 > - HDMI IN > - Analog audio > - Mali GPU > - Heat sink fan > > However, neither of the USB 3.0 ports work. There are no XHCI messages > during boot. I confirmed my kernel config does build XHCI. I haven't > ruled out a mistake on my end yet. Does your kernel config have CONFIG_PHY_ROCKCHIP_USBDP? Both USB 3 ports on the Max/Ultra ports are wired to the usbdp controller and not combphy2_psu controller. It'll be set if you're using the arm64 defconfig. On my Orange Pi 5 Max, dmesg | grep xhci will show (e.g. io mem) [ 0.769699] xhci-hcd xhci-hcd.4.auto: xHCI Host Controller [ 0.769919] xhci-hcd xhci-hcd.4.auto: new USB bus registered, assigned bus number 1 [ 0.770062] xhci-hcd xhci-hcd.4.auto: hcc params 0x0220fe64 hci version 0x110 quirks 0x0000808002000010 [ 0.770119] xhci-hcd xhci-hcd.4.auto: irq 89, io mem 0xfc000000 [ 0.770351] xhci-hcd xhci-hcd.4.auto: xHCI Host Controller [ 0.770585] xhci-hcd xhci-hcd.4.auto: new USB bus registered, assigned bus number 2 [ 0.770602] xhci-hcd xhci-hcd.4.auto: Host supports USB 3.0 SuperSpeed [ 0.770837] usb usb1: Manufacturer: Linux 6.14.0-rc1-2-rockchip-ARCH xhci-hcd [ 0.770844] usb usb1: SerialNumber: xhci-hcd.4.auto [ 0.772069] usb usb2: Manufacturer: Linux 6.14.0-rc1-2-rockchip-ARCH xhci-hcd [ 0.772076] usb usb2: SerialNumber: xhci-hcd.4.auto [ 0.792369] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller [ 0.792640] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 3 [ 0.792781] xhci-hcd xhci-hcd.5.auto: hcc params 0x0220fe64 hci version 0x110 quirks 0x0000808002000010 [ 0.792826] xhci-hcd xhci-hcd.5.auto: irq 90, io mem 0xfc400000 [ 0.793058] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller [ 0.793311] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 4 [ 0.793327] xhci-hcd xhci-hcd.5.auto: Host supports USB 3.0 SuperSpeed [ 0.793530] usb usb3: Manufacturer: Linux 6.14.0-rc1-2-rockchip-ARCH xhci-hcd [ 0.793537] usb usb3: SerialNumber: xhci-hcd.5.auto [ 0.794703] usb usb4: Manufacturer: Linux 6.14.0-rc1-2-rockchip-ARCH xhci-hcd [ 0.794710] usb usb4: SerialNumber: xhci-hcd.5.auto > > Also, the green LED is constantly lit even when the trigger is set to > none and the brightness is set to 0. This made is a bit harder to > confirm that the blue LED was working. I haven't ruled out a mistake on > my end for this one yet either. Checking the schematic for the Max and the Ultra, they both use PWM4_M0 and PWM5_M1 to control the blue and green LEDs. Have you tried booting the vendor BSP 5.10 or 6.1 kernels? What's the behavior on those kernels? It's using GPIO pins there, whereas we're using PWM to be able to control brightness. > > I'll also see if I can give HDMI a test. Please report your results when you do. This is one of the differences from the Orange Pi 5 Max. The HDMI1 pinctrls does not use the default pinctrls like other RK3588 boards (including the Orange Pi 5 Plus). > > JE > > [1] https://github.com/jimmyhon/linux/tree/integrate-6.15 > Jimmy
On Fri, Feb 21, 2025, Jimmy Hon <honyuenkwun@gmail.com> wrote: > On Fri, Feb 21, 2025 at 5:13 PM Johannes Erdfelt <johannes@erdfelt.com> wrote: > > However, neither of the USB 3.0 ports work. There are no XHCI messages > > during boot. I confirmed my kernel config does build XHCI. I haven't > > ruled out a mistake on my end yet. > > Does your kernel config have CONFIG_PHY_ROCKCHIP_USBDP? > Both USB 3 ports on the Max/Ultra ports are wired to the usbdp > controller and not combphy2_psu controller. > It'll be set if you're using the arm64 defconfig. Yeah, we came to the same conclusion. I noticed this was disabled in my config when I was looking for potential mistakes I may have made. Enabling it fixes the USB 3.0 port problem. > > Also, the green LED is constantly lit even when the trigger is set to > > none and the brightness is set to 0. This made is a bit harder to > > confirm that the blue LED was working. I haven't ruled out a mistake on > > my end for this one yet either. > > Checking the schematic for the Max and the Ultra, they both use > PWM4_M0 and PWM5_M1 to control the blue and green LEDs. Some brief testing makes it seem like the LEDs are inverted. If I set the trigger for each LED to "default-on", then they turn off. If both are set to "default-on", then only the red LED is lit. Also, "heartbeat" appears to be inverted. I tried a new DT with this patch and it appears to work correctly on the Ultra I have. However, it raises the question why the Max behaves differently from the Ultra. diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-compact.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-compact.dtsi index 87090cb98020..ed51a4763318 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-compact.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-compact.dtsi @@ -4,6 +4,7 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/pinctrl/rockchip.h> +#include <dt-bindings/pwm/pwm.h> #include "rk3588-orangepi-5.dtsi" / { @@ -62,13 +63,13 @@ &hym8563 { &led_blue_pwm { /* PWM_LED1 */ - pwms = <&pwm4 0 25000 0>; + pwms = <&pwm4 0 25000 PWM_POLARITY_INVERTED>; status = "okay"; }; &led_green_pwm { /* PWM_LED2 */ - pwms = <&pwm5 0 25000 0>; + pwms = <&pwm5 0 25000 PWM_POLARITY_INVERTED>; }; /* phy2 */ JE
On Fri, Feb 21, 2025, Jimmy Hon <honyuenkwun@gmail.com> wrote: > On Fri, Feb 21, 2025 at 5:13 PM Johannes Erdfelt <johannes@erdfelt.com> wrote: > > I'll also see if I can give HDMI a test. > > Please report your results when you do. This is one of the differences > from the Orange Pi 5 Max. The HDMI1 pinctrls does not use the default > pinctrls like other RK3588 boards (including the Orange Pi 5 Plus). No luck yet. I do see this message in the kernel logs 8 times at boot: [ 41.552751] rockchip-drm display-subsystem: [drm] *ERROR* failed to get pll_hdmiphy0 I'll confirm with the vendor image that my HDMI setup is correct. JE
On Fri, Feb 21, 2025 at 10:36 PM Johannes Erdfelt <johannes@erdfelt.com> wrote: > > On Fri, Feb 21, 2025, Jimmy Hon <honyuenkwun@gmail.com> wrote: > > On Fri, Feb 21, 2025 at 5:13 PM Johannes Erdfelt <johannes@erdfelt.com> wrote: > > > I'll also see if I can give HDMI a test. > > > > Please report your results when you do. This is one of the differences > > from the Orange Pi 5 Max. The HDMI1 pinctrls does not use the default > > pinctrls like other RK3588 boards (including the Orange Pi 5 Plus). > > No luck yet. I do see this message in the kernel logs 8 times at boot: > > [ 41.552751] rockchip-drm display-subsystem: [drm] *ERROR* failed to > get pll_hdmiphy0 Oh, I believe you're hitting this. https://lore.kernel.org/linux-rockchip/0dd48599-448f-4472-9a8a-54b7f0379c13@collabora.com/T/#ma4eb427de77b5a4806a2c2b5bef2fc8d4003f801 I included that patchset in the integrate-6.15 branch. I don't have the problem on the Max because it has both the HDMI0 and HDMI1 enabled. However, with only HDMI1 on the Ultra, it's not handling the disabled hdptxphy0. A quick hack is to also enable hdptxphy0 also in the Ultra dts. > > I'll confirm with the vendor image that my HDMI setup is correct. > > JE > Jimmy
> > > Also, the green LED is constantly lit even when the trigger is set to > > > none and the brightness is set to 0. This made is a bit harder to > > > confirm that the blue LED was working. I haven't ruled out a mistake on > > > my end for this one yet either. > > > > Checking the schematic for the Max and the Ultra, they both use > > PWM4_M0 and PWM5_M1 to control the blue and green LEDs. > > Some brief testing makes it seem like the LEDs are inverted. > > If I set the trigger for each LED to "default-on", then they turn off. > If both are set to "default-on", then only the red LED is lit. > > Also, "heartbeat" appears to be inverted. > > I tried a new DT with this patch and it appears to work correctly on the > Ultra I have. However, it raises the question why the Max behaves > differently from the Ultra. > > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-compact.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-compact.dtsi > index 87090cb98020..ed51a4763318 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-compact.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-compact.dtsi > @@ -4,6 +4,7 @@ > > #include <dt-bindings/gpio/gpio.h> > #include <dt-bindings/pinctrl/rockchip.h> > +#include <dt-bindings/pwm/pwm.h> > #include "rk3588-orangepi-5.dtsi" > > / { > @@ -62,13 +63,13 @@ &hym8563 { > > &led_blue_pwm { > /* PWM_LED1 */ > - pwms = <&pwm4 0 25000 0>; > + pwms = <&pwm4 0 25000 PWM_POLARITY_INVERTED>; Oh, there is a difference in the vendor BSP. The Max has GPIO_ACTIVE_HIGH while the Ultra uses GPIO_ACTIVE_LOW. https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-6.1-rk35xx/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-max.dts#L401 https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-6.1-rk35xx/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-ultra.dts#L416 On the schematic, the 5 Plus and the 5 Max have 2SK3018s on the LED, but the 5 Ultra does not have it. I will separate them out in v2. Thanks for debugging it. > status = "okay"; > }; > > &led_green_pwm { > /* PWM_LED2 */ > - pwms = <&pwm5 0 25000 0>; > + pwms = <&pwm5 0 25000 PWM_POLARITY_INVERTED>; > }; > > /* phy2 */ > > JE > Jimmy
On Fri, Feb 21, 2025, Jimmy Hon <honyuenkwun@gmail.com> wrote: > > On Fri, Feb 21, 2025, Jimmy Hon <honyuenkwun@gmail.com> wrote: > > > On Fri, Feb 21, 2025 at 5:13 PM Johannes Erdfelt <johannes@erdfelt.com> wrote: > > > > I'll also see if I can give HDMI a test. > > > > > > Please report your results when you do. This is one of the differences > > > from the Orange Pi 5 Max. The HDMI1 pinctrls does not use the default > > > pinctrls like other RK3588 boards (including the Orange Pi 5 Plus). > > > > No luck yet. I do see this message in the kernel logs 8 times at boot: > > > > [ 41.552751] rockchip-drm display-subsystem: [drm] *ERROR* failed to > > get pll_hdmiphy0 > Oh, I believe you're hitting this. > https://lore.kernel.org/linux-rockchip/0dd48599-448f-4472-9a8a-54b7f0379c13@collabora.com/T/#ma4eb427de77b5a4806a2c2b5bef2fc8d4003f801 > > I included that patchset in the integrate-6.15 branch. I don't have > the problem on the Max because it has both the HDMI0 and HDMI1 > enabled. However, with only HDMI1 on the Ultra, it's not handling the > disabled hdptxphy0. A quick hack is to also enable hdptxphy0 also in > the Ultra dts. That was it. With the last patch in that thread applied, I get HDMI output. I'll see if I can figure out a setup to test the HDMI RX port as well. JE