KingFalse

Hi everyone, I have physical access to an Orange Pi 5 Ultra with 16 GB RAM and would like to help with testing and maintenance of this board. Here is my first round of hardware testing on the current/mainline image. I am posting the working features, reproducible problems and remaining gaps separately. This is an initial test report, not a release sign-off. Image and test environmentBoard: Orange Pi 5 Ultra, RK3588, 16 GB RAM. Image: Armbian community 26.11.0-trunk.120, Ubuntu 26.04 Resolute, GNOME/Wayland, booted from microSD. Kernel: 6.18.60-current-rockchip64. Image build commit: c24ea08f8759a37aaa83a101774582c37c18eda6. Kernel, DTB and BSP packages: 26.11.0-trunk.120. Mesa: 26.0.8-1ubuntu0.3. Storage: 64 GB SDXC card using SDR104 at approximately 148.5 MHz; Samsung SSD 980 500 GB on PCIe 3.0 x4; Toshiba MQ04UBF100 1 TB USB hard disk detected at SuperSpeed 5000M. Ethernet: RTL8125B using r8169, linked to a 1 GbE LAN peer. Cooling fan present. PSU model/specification has not yet been recorded. Tests were run on 5–6 November 2026, UTC+8, using remote shell/Python automation and local hands-on cable/desktop checks. A baseline package list and boot log were saved before testing. The desktop updater subsequently updated userspace packages, including libc6 from 2.43-2ubuntu2.3 to 2.43-2ubuntu2.4. The recorded kernel/DTB packages and Mesa version remained as listed above. This should therefore not be treated as a completely untouched-image test for every later result. Additional test utilities were unpacked into a separate test directory. I do not yet have an armbianmonitor -u upload URL from this session. Redacted baseline boot, hardware and package information is included with the test evidence; a formal support report is still incomplete. Completed checksBoot and desktop: SD boot, GNOME/Wayland desktop, HDMI output, USB keyboard and mouse were usable. This covers this desktop image only, not a separate minimal/CLI image. GPU: accelerated OpenGL renderer reported Mali-G610 MC4 (Panfrost). glmark2 output validation passed. Vulkan enumeration with the Panfrost ICD and a 240-frame Wayland vkcube run completed successfully. Three short glmark2 scenes also completed; this was not the full default performance benchmark. RAM: memtester completed one full pass over 2 GiB with exit status 0 in 836.51 seconds. The highest sampled temperature during that test was 53.6°C. This is not exhaustive coverage of all 16 GB. CPU policy: three cpufreq policies were present, with observed peaks of 1.8 / 2.4 / 2.4 GHz during the memory test. The desktop tuning profile and ext4 commit=15 setting were present. A full CPU/VM soak result is still missing, as noted below. RTC: HYM8563 time reads worked. A future, minute-aligned alarm triggered the RTC hardware interrupt at the requested RTC timestamp; its IRQ counter increased from 0 to 1. This was an awake-system alarm test, not a suspend wake-up or battery-backed power-off retention test. Ethernet: TCP receive to the board was approximately 940 Mb/s and transmit from the board approximately 764 Mb/s. A bidirectional run also completed. IPv4, IPv6 and 1500-byte-MTU ping checks passed. The peer was limited to 1 GbE, so 2.5 GbE throughput was not validated. Storage checksfio 3.41 was used for bounded tests. SD and USB file tests used 1 MiB blocks, direct I/O, libaio queue depth 16 and CRC32C write/read verification. The NVMe test used direct, read-only access with a 4 GiB working set for 15 seconds. Rates below are decimal MB/s. Device / scope Write Read Result SD, 2 GiB file 24.75 MB/s 65.81 MB/s CRC32C verification passed USB hard disk, 1 GiB file, first USB 3 port 59.08 MB/s 138.65 MB/s CRC32C verification passed NVMe, read-only Not tested 1403.87 MB/s Read test passed; health queries completed The SD and USB 4 KiB random-read tests also completed. No new storage-related kernel errors were found during this test interval. These tests do not cover the entire capacity of the media. NVMe write verification and the second USB 3 port remain untested. Open finding 1: onboard Wi-Fi interface is missingAt baseline, Ethernet and Bluetooth were present but no WLAN interface or wireless PHY appeared. The installed bcmdhd-sdio-dkms package was built for the running kernel, while the SDIO bus had no enumerated device. The live device tree contained: mmc@fe2d0000 { status = "disabled"; };Observed package/driver state: bcmdhd-sdio-dkms: 101.10.591.52.27-10 bcmdhd-sdio/101.10.591.52.27-10, 6.18.60-current-rockchip64, aarch64: installed iw dev / iw phy: no wireless interface or PHY listed /sys/bus/sdio/devices/: emptyThe vendor board DTS contains SDIO enablement and a Wi-Fi power sequence. Missing board-level SDIO/power-sequence description is a suspect; no proposed fix or overlay has been runtime-tested in this session. Open finding 2: HDMI input self-loop did not lockWith no independent HDMI source available, I connected this board's HDMI OUT to its HDMI IN. A fullscreen colour-bar pattern was generated, and the receiver was given the v4l2-ctl HDMI EDID preset. DRM state confirmed a 1920×1080 at 60 Hz RGB 8 bpc transmitter mode, with a 148.5 MHz TMDS clock. The receiver reported power_present=1, but v4l2-ctl --query-dv-timings failed with “No locks available”. The kernel logged: hdmirx_phy_register_write wait cr write done failed hdmirx_controller_init wait timer base lock failed hdmirx_query_dv_timings: signal is not lockedThe HDMI RX HDMI/DMA IRQ counters stayed at zero while the 5V-detect GPIO IRQ counter increased. Unloading/reloading synopsys_hdmirx and reapplying the test EDID reproduced the same result. The original receiver EDID and monitor connection were restored afterward. This is a reproducible self-loop observation on this setup, not proof that every external HDMI source will fail. Testing with an independent source and checking a clean cold boot remain necessary. Relevant earlier changes include #10172 and the 6.18 patch adjustment #10180. Incomplete and intentionally omitted checksA 15-minute all-CPU plus 4 GiB VM verification run was started, but no final completion record has been collected. The last collected progress line was around 58 seconds. I am not counting this soak as passed. Later, new SSH connections were closed before authentication while the board still answered LAN pings. The cause has not been established, and I am not attributing it to the load test or kernel without further evidence. Bluetooth firmware loading, discovery and three rfkill recovery cycles were observed; pairing and data transfer were not validated. Further Bluetooth testing was intentionally skipped. Actual audio playback/capture, the second USB 3 port, repeated warm/cold boot recovery, RTC power-off retention, other images/kernel branches and additional header/camera interfaces remain outside this completed test set. Maintenance interestI would like to contribute release-image testing and reproducible board reports for the Orange Pi 5 Ultra. In particular, #10673 explicitly noted missing Ultra/Linux 6.18 runtime coverage, and #11157 reported no board hardware testing for the CPU policy changes. The observations above provide some additional runtime evidence, with the limitations stated. I have saved the scripts, package inventories and logs, and can provide specific redacted excerpts. Guidance on the highest-priority follow-up tests and the board-maintainer application process would be appreciated. KingFalse orangepi5-ultra-6.18-first-round-evidence.zip