C127

You are right, this is a strange DTS issue. U-Boot is working, but the kernel can't initialize the SD card, which is why it drops to the initramfs shell. Unfortunately, I can't reproduce this specific error myself, but I agree with the analysis. I suspect this is the same reason why newer U-Boot versions initially failed to boot for me. I will start working on fixing the DTS next week. Thanks for finding this bug!

Yes, it works correctly debian@orangepi5pro:~$ lsusb -t ... /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=usb-storage, 5000M

You are right, I was too focused on the eMMC. The fact that sdio is used for WiFi/BT on this board suggests a more complex problem with the main SDHCI controller in U-Boot. This means my U-Boot patch is still in a very early stage, and I need to do a deeper analysis of how all these interfaces are powered and configured. I will continue working on it and will let you know when I have a new patch to test.

Hello @salas, Thank you for the incredibly detailed testing and analysis! You are right, the problem is aligned with U-Boot. The observation that the kernel can see the eMMC after booting from the SD card is the key. It proves the hardware is fine and the kernel's eMMC driver is working correctly. The issue is that the U-Boot SPL (Secondary Program Loader) is not initializing the eMMC interface properly at boot time. Based on this, I've created a new patch (v0.5) that specifically targets this U-Boot initialization problem. I have adjusted the U-Boot device tree in an attempt to correctly enable the eMMC interface during the SPL phase. I have just updated the pre-compiled image in the "Releases" section of my build repository to v0.5. Thanks again for your amazing help!

Hello @salas Thanks a lot for testing and for the eMMC boot log! That's super helpful. I'm ready to tackle the eMMC boot issue. As you saw, it's failing very early in the U-Boot SPL, so it's definitely a hardware initialization problem. I'm creating a new fork to add a patch for this (Patch >=v0.4). Since I can't test it myself (I don't own an eMMC module), I would need your help to flash and test the new images. With a bit of luck and your feedback, we should be able to get it working.

Hello everyone. @salas I have just implemented the out-of-box (OOB) network driver functionality in a new commit to the repository. This should serve as a temporary patch for now (or potentially a permanent one, depending on if/when the driver gets mainlined into the Linux kernel). @whywontitwork Thank you very much for the feedback and for testing the image. I need a bit more information to help track down the issue. My suspicion is that the system is successfully loading u-boot but failing to load the kernel. However, without debug logs, it's difficult to know the real cause. To help diagnose this, could you please tell me how you flashed the image? I flash my builds to a microSD card using the Balena Etcher software. Are you using the same method or a different one? I appreciate your support in getting the Orange Pi 5 Pro maintained! One of my main motivations for starting this project was to get Panthor support for the Mali GPU too. I can confirm that on my end, with the image I've built, the latest version of the drivers works correctly. Getting Vulkan and OpenGL running on an RK3588 board!

Thank you for the response. I've reviewed the PR you linked, and based on that, I have created my own: https://github.com/armbian/build/pull/8348 I appreciate the review. I have fixed the issue with the unnecessary wrapper in my `orangepi5pro.csc` file and have also addressed the other recommendations. Regarding the use of the latest U-Boot version, I did test it. However, it seems that with versions newer than 2024.04, U-Boot takes a very long time (~60 seconds) just to start the kernel. This is likely due to an issue from the refactoring that occurred after the 2024.04 release. Thanks again for your guidance.

Hello @salas! Thanks for the questions and your interest in testing! Let me clarify those points for you, as my initial explanation could have been clearer. The driver for the Ethernet adapter needs to be compiled from source. You can find the repository here: https://github.com/dante1613/Motorcomm-YT6801/ You're right, my board also has only one user-accessible M.2 NVMe slot. My "NVMe x2" note was a bit confusing. According to the board schematics, the RK3588S SoC provides two NVMe interfaces. On this board, one is routed to the M.2 slot, and the other is internally wired to the chip that drives the RJ45 Ethernet port. So, only one is available for storage. You are correct that the USB-C port is used for power delivery. However, based on the schematics, the USB-C controller's pins are also multiplexed. Some are routed for DisplayPort Alt Mode (which then goes to the HDMI port), while the remaining data lines are intended for USB 3.0. I am still investigating this part, so I'm not 100% certain yet, but that's what the hardware layout suggests. Thank you so much for offering to test with an eMMC card! That would be extremely helpful to confirm that it's working correctly. To make it easier for you, I've just uploaded a pre-compiled image to the "Releases" section of my Armbian build repository. You can also build it yourself from the source, of course. And yes, to confirm, all my work is for the Orange Pi 5 Pro variant. Regarding your question about the kernel patch: it's currently based on the Armbian edge kernel tree (v6.16), which includes its own set of patches. It might not apply cleanly to a vanilla mainline kernel (like one from kernel.org) without some adjustments. However, the core DTS changes should be a great starting point for upstreaming the work once it's more mature. That's definitely the end goal! Thanks again for your feedback!

Hello Armbian community, I'm new to the forums and I'm currently working on adding support for the Orange Pi 5 Pro. I have developed a DTS file that enables support for this board on the EDGE kernel (currently v6.16). Here is the current status of device support with my changes: Working Features: Wireless & Bluetooth USB 2.0 (x3 ports) HDMI 2.1 Gigabit Ethernet (via PCIe to RJ45 adapter - requires manual driver installation as it's not in the kernel) NVMe x2 (One slot tested with an NVMe drive, works perfectly. The other is used by the Ethernet adapter) GPIO PWM LEDs Audio CODEC (ES8388) GPU (with the latest Mesa drivers) Not Yet Working (Work in Progress): USB 3.1 HDMI output via USB-C DisplayPort Alt Mode NPU Untested (Hardware unavailable to me): These are expected to work but remain unconfirmed. Cameras Regulated FAN TouchScreen eMMC Flash Not Sure: VPU (Unable to test due to lack of VAAPI support) Additional Information: I have successfully booted the board using u-boot version 2024.04, and it will likely work with newer versions as well. Questions and Call for Collaboration: I've based my work on the Armbian build system, patching the kernel, u-boot, and modifying the board configuration file. Now that the initial work is done, I have a few questions: 1. Contribution Process: When my DTS and related changes are more mature, what is the proper procedure to submit them as a contribution to the official Armbian project? 2. Testing: My build is based on the nightly branch. I am looking for volunteers to help test the image. Is there a specific forum section or process for sharing test images and gathering community feedback? 3. Collaboration: I would greatly appreciate any help or collaboration, especially with getting USB 3.0 and DisplayPort (via USB-C) connectivity fully functional. If you're interested in helping, please let me know. Thank you for your time and any guidance you can provide. Repository: U-boot Patch: https://github.com/c127dev/u-boot/tree/orangepi5pro-dev-2404 Kernel Patch: https://github.com/c127dev/linux/tree/orange-pi-5-pro-dev Armbian build: https://github.com/c127dev/build/tree/orange-pi-5-pro-dev