All Activity

I've also encountered this. SATA fails on some drives but not others. Possibly related to how much power they draw.

I've added a ton of info. I can provide logs if needed. This is a bug with Armbian and/or uboot. I believe I've traced it to the preboot code, so that would be uboot? https://github.com/armbian/build/issues/9532 https://lists.denx.de/pipermail/u-boot/2026-July/624426.html I have two versions of Armbian, one works and one doesn't: Armbian_26.5.1_Odroidhc4_trixie_current_6.18.33_minimal.img.xz - fails Armbian_25.8.1_Odroidhc4_bookworm_current_6.12.41_minimal.img.xz - works

Moved post to the correct forum section

Hello Im a begginer and dont know Linux. I have a tv box : enyBox x98q Cpu amlogic s905w2 2g ram 16g rom My need to install MetaTrader5 on linux on this tv box. I downloaded both files on site this link: debian 13 ubuntu 26.04 I need to learn the install way by watching a video clip. I request you for making it

Same thing is happeing with me at first it booted correctly with armbian imager then suddenly it crashed and after that whenever i tried to flash it using armbian imgaer its giving error of initramfs , btw iam using Radxa zero 3w , any solution or any step iam doing wrong , i have tried it with different imager but same problem.

Hello @4A studio ,I'm sorry for the late reply. I accidentally installed the image to a partition on the Micro SD card using the `dd` command (of=/dev/sd*2). I eventually resolved the issue by using the correct `dd` command (of=/dev/sd*).

@bedna Thanks for the pointers, I'll try tonight or tomorrow. And yes, my plan was to set up a swap file on the SSD. @SteeMan I don't know if I'm doing something else wrong, but on my /etc/default/armbian-zram-config I have ENABLED=false and SWAP=false, but I keep seeing the swap mounted on lsblk and listed on htop

Similar quick test here: N100 with PCIe ethernt and wifi HW, already a br0 with enslaved ethernet, I set up a working hostapd.conf, enabled hostapd.service and added /etc/systemd/network/22-wlp2s0.network [Match] Name=wlp2s0 [Network] Bridge=br0 ConfigureWithoutCarrier=yes Then reboot and properly working AP. Is Opensuse Tumbleweed. But it is rather 'static', not as flexible/dynamic as with NM. For example, if I do networkctl down wlp2s0 ; sleep 30 ; networkctl up wlp2s0 the AP still works, but network list shows failed for wlp2s0 I though maybe it has to do with the fact that Tumbleweed has no sysV compatibility anymore (folder /etc/init.d/ is not there), so no option that something goes wrong potentially due to some sync issues, but I think I cannot draw that conclusion. Quick check shows no relation between hostapd.service and systemd-networkd, but it is much more extensive than for debian13 for sure.

It has been offically supported. Thanks! https://armbian.com/boards/norco-emb-3531

This should be specified down to just 2 things: Armbian U-Boot package and kernel package. The DTB package is redundant as the .dtb file is in the kernel package. For more low-level tests, I usually rename boot.scr and use manual extlinux, so easy to select a certain kernel+initrd+dtb(o). This also works for example with Opensuse Tumbleweed as userspace although (Wayland KDE ) GUI not anymore with vendor 6.1.115. For just standard Ext4 rootfs, note that multiple kernels is automatically handled by standard Debian package u-boot-menu (see its config in /etc/default/u-boot).

Hi @Kwiboo and Armbian rk35xx maintainers, I'm hitting a boot-time eMMC reliability issue on NanoPi R76S with the current Armbian U-Boot 2026.04 build, and the community-known workaround from OpenWrt PR #23520 breaks kernel boot completely in our Armbian environment. Sharing detailed reproduction and requesting guidance. ## Setup - Board: NanoPi R76S (RK3576), 4GB LPDDR5, 64GB Hynix eMMC (hC8aP, manfid 0x000090) - Armbian build: derived from 26.5.1, `linux-u-boot-nanopi-r76s-vendor 26.5.1` - U-Boot: 2026.04_armbian-2026.04-S88dc-P3cfe-H30d2-V3c1d-Bd0d2-R448a - Kernel: 6.1.115-vendor-rk35xx (Armbian rk35xx vendor kernel) - BL31: v2.3 fwver v1.20 ## Baseline Symptom (Reproducible ~50%) `sudo reboot` from Linux → SPL/BL31/U-Boot proper OK → boot.scr loads (255 B) → first `ext4load` of kernel Image fails with `fs_devread read error - block`. Second `ext4load` also fails, block layer reports `No partition table - mmc 0`. Reproduction across both warm reboot and cold power cycle. Matches OpenWrt issue #23491 exactly. Interestingly `mmc rescan` in U-Boot prompt re-reads mmc info (58.2 GiB Hynix detected, partition table intact) but subsequent `boot` command still fails — suggesting U-Boot driver leaves stale state that even a manual rescan cannot clear. ## Attempted Workarounds (All Failed in Our Environment) ### v1: 26 MHz variant (aggressive) - U-Boot embedded DT `mmc@2a330000`: dropped `cap-mmc-highspeed`, `mmc-hs400-1_8v`, `mmc-hs400-enhanced-strobe`; set `max-frequency=<26000000>` - Kernel DT overlay (same node): same property removal + 26 MHz - Result: `Starting kernel ...` reached, then **immediate hang, no dmesg**. ### v2: OpenWrt PR #23520 exact patch (52 MHz, U-Boot only) - U-Boot DT: kept `cap-mmc-highspeed`, removed only `mmc-hs400-1_8v` and `mmc-hs400-enhanced-strobe`; set `max-frequency=<52000000>` (52 MHz HS) - Kernel DT: untouched (HS400ES) - Result: U-Boot loads kernel at 44.5 MiB/s (HS speed confirmed), reaches `Starting kernel ...`, then **hang, no dmesg**. ### v3: Symmetric 52 MHz on both U-Boot and kernel DT - U-Boot DT: same as v2 - Kernel DT overlay: removed HS400 properties + 52 MHz cap - Result: identical hang after `Starting kernel ...`. Observation: **any modification to U-Boot's embedded DT for mmc@2a330000 appears to make the Armbian vendor kernel silently fail before earlycon initialization.** The stock Armbian U-Boot + stock kernel DT combination boots kernel reliably (log flushes normally), but exhibits the ~50% warm-reboot bug. Rolling back U-Boot to the original (via slot B rootfs `u-boot.itb`) restores kernel boot immediately. ## Questions 1. Has anyone successfully applied OpenWrt PR #23520's workaround (or any variant) to Armbian's vendor kernel on RK3576? If so, what was the specific property combination? 2. Is this a known incompatibility between the mainline U-Boot mmc probe path and the Armbian rk35xx vendor kernel's dw_mshc driver? The Rockchip PSCI handoff seems to fail silently before console_init. 3. Would upgrading to U-Boot 2026.07 (just released) help? My search showed zero mmc/sdhci commits in v2026.04..v2026.07 range for rockchip. Am I missing a Karlman patch series that isn't yet in Armbian's fork? 4. Any suggested next step: (a) chase FriendlyElec BSP U-Boot behavior, (b) patch the vendor kernel's dw_mshc probe to handle inherited controller state, or (c) accept as known-limitation until Armbian moves to kernel 6.6+? 5. If (b), which specific probe/reset path in `drivers/mmc/host/dw_mmc-rockchip.c` or `sdhci-of-dwcmshc.c` should we audit? Any references to similar rk3588 handoff issues that were resolved? Full boot logs (successful, failed variants v1/v2/v3, rollback recovery) available on request. Willing to test patches against test board and report back with UART logs. Thanks for maintaining rockchip U-Boot, Peter Rim Related: - https://github.com/openwrt/openwrt/issues/23491 - https://github.com/openwrt/openwrt/pull/23520 - https://github.com/armbian/build/pull/9869 (R76S migration to v2026.04) rk3576-mmc-bug-attachments.tar.gz

Then I don't know why it does not work, and I would assume this combination of SBC and NVME just won't work. Such cases exists, although frustrating that is does not work. You could cross check, but I don't know it you have other brands NVME to try with the OPi5 Ultra. I would also be not surprised if there is simply something wrong of missing in the U-Boot or DTB (all versions, even the one from manufacturer/xunlong). You can look at versions history of U-Boot for example, just to see how much your luck is or would be. And/or until someone with the same combination sees this topic. I only have Samsung NVME's. primarily 970+ in a ROCK5B, is also RK3588 4-lane PCIEv3 and older earlier 970 in an ROCK3A (2-lane PCIEv3). The latter one works but only with a very specific set of U-Boot, BTB and kernel (for my use case).

Introduction This guide describes a tested method for running Android, Armbian, and Ubuntu on the same NVMe SSD of the Orange Pi 5 Plus. This is not an official Orange Pi installation procedure. The entire workflow was developed through extensive real-world testing. The following configuration has been successfully verified: ✅ Android boots from the NVMe SSD. ✅ Armbian boots from the same NVMe SSD via UEFI. ✅ Ubuntu boots from the same NVMe SSD via UEFI. ✅ All three operating systems coexist on a single NVMe SSD. ✅ Armbian and Ubuntu share the same EFI partition. ✅ Android, Armbian, and Ubuntu can share a common data partition. 1. Requirements Hardware Orange Pi 5 Plus. An NVMe SSD (the larger the better, and it must have a larger capacity than the eMMC to provide free space for Armbian and Ubuntu). A 16GB or 32GB eMMC module (16GB recommended). A microSD card for UEFI. A PC/Laptop or an NVMe USB enclosure for partition management. A microSD card can also be used instead of eMMC for Android, but a large-capacity card is not recommended because it reduces the available space for Linux on the NVMe SSD. Software Android ROM (tested and verified; the AGTV ROM can be flashed directly to the eMMC using rkdeveloptool). Armbian. Ubuntu. UEFI image. BalenaEtcher, Rufus, or any software capable of writing IMG files to a microSD card. A partition manager such as GParted, DiskGenius, or MiniTool Partition Wizard. 2. Boot Method Android Android uses the standard Rockchip boot process. Requirements: The SPI flash must be empty or completely erased. Android boots directly from the NVMe SSD. Armbian and Ubuntu Armbian and Ubuntu boot through UEFI. Write the UEFI image to a microSD card. Insert the microSD card whenever you want to boot Linux. Both operating systems share the same EFI partition on the NVMe SSD. 3. NVMe Partition Layout The NVMe SSD contains two groups of partitions. Android Keep all Android system partitions intact, for example: boot vendor_boot dtbo vbmeta super metadata userdata ... Do not modify any Android system partition. Linux Create the following additional partitions: EFI Armbian RootFS Ubuntu RootFS Data The Data partition can be shared between Armbian and Ubuntu. 4. Preparing Android Flash Android to the eMMC. Boot Android and verify that everything works correctly. Boot Armbian or Ubuntu from a microSD card or an external SSD (this Linux installation will later be used to copy its RootFS to the NVMe SSD after partitioning). Back up the entire eMMC using the dd command. Restore the Android image from the eMMC to the NVMe SSD using dd. After this step, the NVMe SSD will contain the complete Android partition layout. Since the NVMe SSD is larger than the eMMC: The beginning of the NVMe SSD will contain all Android partitions. The remaining space will remain Unallocated, which will later be used for the Linux partitions. Next, erase all data on the eMMC and remove the eMMC module from the Orange Pi 5 Plus. Then power on the board and verify that Android boots successfully from the NVMe SSD. This confirms that the system is running entirely from the NVMe drive rather than from the eMMC. 5. Creating Space for Linux Keep all Android partitions unchanged. Using tool on either Windows or Linuxuse the Unallocated space located after the Android partitions, create the following partitions: EFI (used to boot Armbian and Ubuntu through UEFI) Armbian Ubuntu Data 6. Installing Armbian Restore or copy the Armbian RootFS to the Armbian partition on the NVMe SSD. Copy the EFI boot files to the EFI partition. Update the UUIDs if necessary. Verify that Armbian boots successfully through UEFI. 7. Installing Ubuntu Restore or copy the Ubuntu RootFS to the Ubuntu partition on the NVMe SSD. Copy the EFI boot files to the EFI partition. Update the UUIDs if necessary. Verify that Ubuntu boots successfully through UEFI. 8. Booting the Operating Systems Boot Android Remove the microSD card containing the UEFI bootloader. Make sure the SPI flash is empty. [7/10/2026 10:56 AM] Vũ Minh Tâm: The Orange Pi 5 Plus will boot Android directly from the NVMe SSD. Boot Armbian or Ubuntu Insert the microSD card containing the UEFI bootloader. Select the desired operating system from the UEFI boot menu. The selected Linux system will boot from its corresponding partition on the NVMe SSD. 9. Current Status The following configuration has been successfully verified: ✅ Android running from the NVMe SSD. ✅ Armbian running from the NVMe SSD. ✅ Ubuntu running from the NVMe SSD. ✅ Armbian and Ubuntu share the same EFI partition. ✅ Android, Armbian, and Ubuntu can share a common Data partition (NTFS is recommended). ✅ Switching between Android and Linux only requires inserting or removing the microSD card. 10. Notes This method has only been tested on the Orange Pi 5 Plus. It is based entirely on real-world testing and is not an official Orange Pi installation procedure. Some adjustments may be required when using different firmware versions, bootloaders, or hardware revisions. It is strongly recommended to back up both the eMMC and the NVMe SSD before modifying the partition layout. 11. Discussion If you have successfully implemented a similar setup or know of a simpler approach, feel free to share your experience. Any suggestions or improvements are welcome and will help make this guide even better.

Unfortunately, Link Star H68K is not one of the supported boards. Hinlink H68K is Community Maintained and is provided as-is with no guaranteed support and no any maintainer listed. If you can figure out what is different in the bootloader and device tree, you should be able to adapt what is in the Hinlink H68K build configuration.

Or probably the easier way is to edit /etc/default/armbian-zram-config

I want to get an sbc to make personal server running website with backend for me, so basically JS, Python, and other stuff. I also want to connect my microcontrollers like esp32 to make my custom smart home system, by using camera. Maybe i also could use AI to analize the image. I found one Banana pi M3(2gb ram) for under 10$, so i am thinking whether to buy it. I feel like the deal is great since i can't find other sbcs with such hardware, ram to be specific, but i heard that software support is bad. Is that true for now? Or is it usable? I am also thinking of getting Orange pi one plus(1gb ram), but it costs more and also has less ram. What should i do?

@Biasio95 Wait, I'm an idiot, the kernel parameter disables zSWAP, not zram. sry. Try "swapoff /dev/zram0" (or whatever the dev is named) and then remove the module with "modprobe -r zram" "echo 'blacklist zram' >> /etc/modprobe.d/blacklist.conf", add another swap and reboot. Or you could disable the zram-generator with the kernel parameter "systemd.zram=0", that way no zram should be able to be created. One of the methods should work, but I have not actually tried it on armbian, so there might be configs that can throw errors if you just remove the module, IDK. If not, read: https://docs.kernel.org/admin-guide/blockdev/zram.html#add-remove-zram-devices and remove the device in /sys/class/zram-control/hot_remove, I would assume that would stick. I assume you know how to setup a "normal" swap partition, because running without swap altogether is prob not a good idea.

I'm getting the same serial output stopping in the same place on my board: https://github.com/yisding/rock-5b-ysp/blob/main/findings/2026-07-09-rock5b-armbian-sd-boot-investigation.md Both zeroed out SPI and working (26.5.1) SPI don't boot. Got it to spin up HDMI by dd-ing over some new 26.5.1 bits over to the SD card but still not quite working. Good news is that 26.5.1 Ubuntu 26.04 does boot, and it also has a package for the 6.1 vendor kernel which boots also. I'm sure there's going to be some kernel/userspace mismatch between 6.1 and 26.04 so I've been "vibe-porting" the hardware encoding/decoding drivers to 6.18. Not quite ready yet for distribution, although it does work with ffmpeg and makes gnome-remote-desktop run silky smooth.

Just managed to distract myself some more in this outrageous heat here in the UK and can confirm that the RELEASE=stable (6.18) build (from compile.sh) boots ok after some tweaking. It got stuck on "Starting Kernel" but when I added these lines to /boot/armbianEnv.txt to see why it failed, then it booted ok - dunno why. I think keep_bootcon was the important bit. extraargs=earlycon=uart8250,mmio32,0x02500000 keep_bootcon ignore_loglevel loglevel=8 The other problem then was getting the ethernet to work which I did by creating a device tree overlay file - much the same as other here is it only seems be working at 100M unlike the 1000M in the 5.15 kernel. The extra problem seemed to be that the wifi driver would periodically crash and cause a kernel-panic. The following DTS file pulls the ethernet down to 100M and disables the wifi to stop it crashing. You then compile this into a .dtbo file, copy it to /boot/overlay-user and reference it in armbianEnv.txt with this line user_overlays=opi4a-network-fix The opi4a-network-fix.dts syntax to create it is as follows ... apart from that I can't get it to do much more, so will go down the 5.15 bookworm route until things change /dts-v1/; /plugin/; / { compatible = "xunlong,orangepi-4a", "allwinner,sun55i-t527"; /* Maintain working Ethernet at 100M address 1 */ fragment@0 { target-path = "/soc/ethernet@4510000"; __overlay__ { phy-mode = "rgmii-id"; phy-handle = <&ext_rgmii_phy>; status = "okay"; mdio { #address-cells = <1>; #size-cells = <0>; ext_rgmii_phy: ethernet-phy@1 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <1>; max-speed = <100>; }; }; }; }; /* Hard disable the unstable wireless MMC controller block */ fragment@1 { target-path = "/soc/mmc@4021000"; __overlay__ { status = "disabled"; }; }; };

@bedna I tried disabling zram, both with armbian-config (so disabling it in /etc/default/armbian-zram-config) and also adding extraargs=zswap.enabled=0 on /boot/armbianEnv.txt, but the swap still show up htop and mounted in the lsblk output. What am I missing?

Comprehensive Guide: Installing Armbian on the TX10 PRO (Allwinner H313) Introduction This technical guide documents the complete process for deploying Linux on the TX10 PRO Android TV Box (Allwinner H313). Due to hardware variations and kernel compatibility issues common on these devices, establishing a functional Armbian environment requires specific images, DTBs, and configuration steps. This documentation is designed to streamline the installation process and avoid common hardware compatibility problems. Technical Specifications & Environment The procedures in this guide were validated on a TX10 PRO with the following hardware: Component Specification ---------------- ----------------------------------- SoC Allwinner H313 (sun50iw9p1) CPU Quad-core Cortex-A53 (ARM64) Memory 1 GB LPDDR3 (Samsung eMCP) Storage 8 GB eMMC Board Revision WFTECH_V2.0 Device Codename titan-p1 Product walley Stock OS Android (Modified Build) Bootloader U-Boot Tested Kernel Linux 6.12.64 (bookworm) Tested working image: Armbian-unofficial_26.02.0-trunk_X96q-v1-3_bookworm_current_6.12.64_minimal.img.xz Kernel: Linux 6.12.64 bookworm Base OS: Debian Bookworm Server Target: X96Q DDR3 / Allwinner H313 Although this image is labeled for the X96Q DDR3, it successfully booted on my TX10 PRO with the WFTECH_V2.0 board and Allwinner H313 SoC. Hardware revisions vary, so compatibility with other TX10 PRO units is not guaranteed. ⚠ Crucial Hardware Warning TV box manufacturers frequently change internal components (RAM layout, Wi-Fi chipsets, and board revisions) without changing the product name. Always verify your board revision before proceeding. Using the wrong Device Tree Blob (DTB) can result in an unbootable system. Advantages & Disadvantages of Running Linux Advantages: Cost Efficiency Much cheaper than a Raspberry Pi or other SBC. Enclosure Included Comes with a case and power supply. Low Power Consumption Runs quietly with very low power usage, making it suitable for lightweight servers. Disadvantages: No Official Support Linux support depends entirely on community-maintained images. Thermal Throttling Cheap passive cooling causes overheating during heavy workloads. Weak eMMC Storage Internal storage may wear out under frequent writes. Slow I/O USB ports are usually USB 2.0 only. No SATA, NVMe, or native Gigabit Ethernet. Driver Problems Wi-Fi, Bluetooth, and hardware video acceleration usually require manual setup. Prerequisite Hardwares: MicroSD Card (8GB or larger) MicroSD Card Reader (Cost: 0.45 USD ) HDMI Monitor (Tv) USB Keyboard Ethernet Adapter Integrated Wi-Fi rarely works immediately on bookworm Linux. A wired Ethernet connection is strongly recommended for initial setup. Installation Process Step 1 — Download Armbian Official Armbian images generally do not include all hardware support for the H313. Download a trusted community image designed for Allwinner H313/H616 boards using the 6.12.64 kernel. USE THIS: Armbian-unofficial_26.02.0-trunk_X96q-v1-3_bookworm_current_6.12.64_minimal.img.xz Step 2 — Flash the SD Card ⚠ Warning Avoid using the Linux dd command if you are unfamiliar with it. Selecting the wrong drive can permanently erase your computer. Instead, use BalenaEtcher. Flashing Steps: Install and open BalenaEtcher. Insert your MicroSD card. Click Flash from File. Select the downloaded .img.xz image. Click Select Target. Choose your MicroSD card carefully. Click Flash! Wait until flashing and verification reach 100%. Safely eject the card. Step 3 — Hardware Setup Before powering on: Insert the MicroSD card. Connect HDMI. Connect USB keyboard. Connect USB Ethernet. Connect power. Step 4 — First Boot The first boot performs: Filesystem expansion Initial setup System configuration This may take several minutes. Expected boot sequence: U-Boot ↓ Linux Kernel ↓ Armbian Login Prompt Step 5 — Initial Login Default credentials: Username: root Password: 1234 After logging in you will be required to: Change the root password Create a normal user Configure timezone Configure locale Step 6 — Verify Network Built-in Wi-Fi will probably not work. The board uses the SSV6x5x / SV6256 chipset which requires extra drivers. Verify Ethernet: ip a ping -c 3 1.1.1.1 Step 7 — Update the System Enable network time: sudo timedatectl set-ntp true Then update: sudo apt update sudo apt upgrade -y Step 8 — Install to eMMC (Optional) Once everything works from the SD card: sudo armbian-config Navigate to: System ↓ Install ↓ Boot from eMMC Follow the installer. After completion: Shut down Remove the SD card Boot from internal storage Hardware Compatibility Working - perfectly HDMI Output USB Ports USB Ethernet Known Issues Wi-Fi - Not working Requires manual compilation of the SSV6256 driver. Graphics No hardware acceleration. Software rendering only. DTB Compatibility Boot success depends heavily on selecting the correct DTB. Different board revisions may require different DTBs. Best Practices Test from SD First Never install to eMMC before confirming that everything works. Backup Android Create a backup of the original Android firmware before modifying internal storage. DTB Troubleshooting If the device: Boot loops Shows a black screen Fails to boot Mount the SD card on another computer. Open: armbianEnv.txt Try different H313/H616 DTB files until the system boots successfully.

I tried all the images including Armbian and the result is the same. The disk is a Silicon Power P34A60 256 GB NVME not SATA

Ultra is not the standard OPi5 nor OPi5Pro, AFAIR it is also RK3588 v.s. RK3588S wich is a major difference w.r.t. PCIE Use a recent kernel/image, see https://armbian.com/boards/orangepi5-ultra And report brand and type of the M.2 NVME SSD. Some people have asked similar question and turned out to be a M.2 SATA SSD

orangepi@orangepi5ultra:~$ dmesg -T | grep -Ei 'pcie|nvme|ltssm|link fail|fe150000' lspci -nn lsblk [Thu Jul 9 14:07:43 2026] vcc3v3_pcie30: 3300 mV, disabled [Thu Jul 9 14:07:43 2026] reg-fixed-voltage vcc3v3-pcie30: Looking up vin-supply from device tree [Thu Jul 9 14:07:43 2026] vcc3v3_pcie30: supplied by vcc5v0_sys [Thu Jul 9 14:07:43 2026] reg-fixed-voltage vcc3v3-pcie30: vcc3v3_pcie30 supplying 3300000uV [Thu Jul 9 14:07:43 2026] vcc3v3_pcie2x1l0: 3300 mV, enabled [Thu Jul 9 14:07:43 2026] reg-fixed-voltage vcc3v3-pcie2x1l0: Looking up vin-supply from device tree [Thu Jul 9 14:07:43 2026] vcc3v3_pcie2x1l0: supplied by vcc12v_dcin [Thu Jul 9 14:07:43 2026] reg-fixed-voltage vcc3v3-pcie2x1l0: vcc3v3_pcie2x1l0 supplying 3300000uV [Thu Jul 9 14:07:43 2026] reg-fixed-voltage vcc3v3-pcie-eth: Looking up vin-supply from device tree [Thu Jul 9 14:07:43 2026] vcc3v3_pcie_eth: supplied by vcc12v_dcin [Thu Jul 9 14:07:43 2026] vcc3v3_pcie_eth: 3300 mV, enabled [Thu Jul 9 14:07:43 2026] reg-fixed-voltage vcc3v3-pcie-eth: vcc3v3_pcie_eth supplying 3300000uV [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: invalid prsnt-gpios property in node [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: invalid prsnt-gpios property in node [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: Looking up vpcie3v3-supply from device tree [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: Looking up vpcie3v3-supply from device tree [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: Looking up vpcie3v3-supply property in node /pcie@fe190000 failed [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: Looking up vpcie3v3-supply property in node /pcie@fe180000 failed [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: no vpcie3v3 regulator found [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: no vpcie3v3 regulator found [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: invalid prsnt-gpios property in node [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: Looking up vpcie3v3-supply from device tree [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: IRQ msi not found [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: use outband MSI support [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: Missing *config* reg space [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: host bridge /pcie@fe190000 ranges: [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: err 0x00f4000000..0x00f40fffff -> 0x00f4000000 [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: IO 0x00f4100000..0x00f41fffff -> 0x00f4100000 [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: MEM 0x00f4200000..0x00f4ffffff -> 0x00f4200000 [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: MEM 0x0a00000000..0x0a3fffffff -> 0x0a00000000 [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: Missing *config* reg space [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: invalid prsnt-gpios property in node [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: invalid resource [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: Looking up vpcie3v3-supply from device tree [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: IRQ msi not found [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: use outband MSI support [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: Missing *config* reg space [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: host bridge /pcie@fe180000 ranges: [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: err 0x00f3000000..0x00f30fffff -> 0x00f3000000 [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: IO 0x00f3100000..0x00f31fffff -> 0x00f3100000 [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: MEM 0x00f3200000..0x00f3ffffff -> 0x00f3200000 [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: MEM 0x09c0000000..0x09ffffffff -> 0x09c0000000 [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: Missing *config* reg space [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: invalid resource [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: IRQ msi not found [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: use outband MSI support [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: Missing *config* reg space [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: host bridge /pcie@fe170000 ranges: [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: err 0x00f2000000..0x00f20fffff -> 0x00f2000000 [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: IO 0x00f2100000..0x00f21fffff -> 0x00f2100000 [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: MEM 0x00f2200000..0x00f2ffffff -> 0x00f2200000 [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: MEM 0x0980000000..0x09bfffffff -> 0x0980000000 [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: Missing *config* reg space [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: invalid resource [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: IRQ msi not found [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: use outband MSI support [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: Missing *config* reg space [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: host bridge /pcie@fe150000 ranges: [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: err 0x00f0000000..0x00f00fffff -> 0x00f0000000 [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: IO 0x00f0100000..0x00f01fffff -> 0x00f0100000 [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: MEM 0x00f0200000..0x00f0ffffff -> 0x00f0200000 [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: MEM 0x0900000000..0x093fffffff -> 0x0900000000 [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: Missing *config* reg space [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: invalid resource [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: PCIe Linking... LTSSM is 0x3 [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: PCIe Linking... LTSSM is 0x0 [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: PCIe Linking... LTSSM is 0x1 [Thu Jul 9 14:07:44 2026] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 [Thu Jul 9 14:07:44 2026] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [Thu Jul 9 14:07:44 2026] rk-pcie fe150000.pcie: PCIe Linking... LTSSM is 0x1 [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: PCIe Link up, LTSSM is 0x130011 [Thu Jul 9 14:07:44 2026] rk-pcie fe180000.pcie: PCI host bridge to bus 0003:30 [Thu Jul 9 14:07:44 2026] pcieport 0003:30:00.0: PME: Signaling with IRQ 154 [Thu Jul 9 14:07:47 2026] rk-pcie fe170000.pcie: PCIe Link Fail [Thu Jul 9 14:07:47 2026] rk-pcie fe170000.pcie: failed to initialize host [Thu Jul 9 14:07:47 2026] rk-pcie fe190000.pcie: PCIe Link Fail [Thu Jul 9 14:07:47 2026] rk-pcie fe190000.pcie: failed to initialize host [Thu Jul 9 14:07:47 2026] rk-pcie fe150000.pcie: PCIe Link Fail [Thu Jul 9 14:07:47 2026] rk-pcie fe150000.pcie: failed to initialize host [Thu Jul 9 14:07:47 2026] rockchip-pm-domain fd8d8000.power-management:power-controller: Looking up pcie-supply from device tree [Thu Jul 9 14:07:47 2026] rockchip-pm-domain fd8d8000.power-management:power-controller: Looking up pcie-supply property in node /power-management@fd8d8000/power-controller failed [Thu Jul 9 14:07:47 2026] reg-fixed-voltage pcie20-avdd0v85: Looking up vin-supply from device tree [Thu Jul 9 14:07:47 2026] pcie20_avdd0v85: supplied by vdd_0v85_s0 [Thu Jul 9 14:07:47 2026] pcie20_avdd0v85: 850 mV, enabled [Thu Jul 9 14:07:47 2026] reg-fixed-voltage pcie20-avdd0v85: pcie20_avdd0v85 supplying 850000uV [Thu Jul 9 14:07:47 2026] reg-fixed-voltage pcie20-avdd1v8: Looking up vin-supply from device tree [Thu Jul 9 14:07:47 2026] pcie20_avdd1v8: supplied by avcc_1v8_s0 [Thu Jul 9 14:07:47 2026] pcie20_avdd1v8: 1800 mV, enabled [Thu Jul 9 14:07:47 2026] reg-fixed-voltage pcie20-avdd1v8: pcie20_avdd1v8 supplying 1800000uV [Thu Jul 9 14:07:47 2026] reg-fixed-voltage pcie30-avdd0v75: Looking up vin-supply from device tree [Thu Jul 9 14:07:47 2026] pcie30_avdd0v75: supplied by avdd_0v75_s0 [Thu Jul 9 14:07:47 2026] pcie30_avdd0v75: 750 mV, enabled [Thu Jul 9 14:07:47 2026] reg-fixed-voltage pcie30-avdd0v75: pcie30_avdd0v75 supplying 750000uV [Thu Jul 9 14:07:47 2026] reg-fixed-voltage pcie30-avdd1v8: Looking up vin-supply from device tree [Thu Jul 9 14:07:47 2026] pcie30_avdd1v8: supplied by avcc_1v8_s0 [Thu Jul 9 14:07:47 2026] pcie30_avdd1v8: 1800 mV, enabled [Thu Jul 9 14:07:47 2026] reg-fixed-voltage pcie30-avdd1v8: pcie30_avdd1v8 supplying 1800000uV 0003:30:00.0 PCI bridge [0604]: Rockchip Electronics Co., Ltd Device [1d87:3588] (rev 01) 0003:31:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05) NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mtdblock0 31:0 0 16M 0 disk mmcblk0 179:0 0 58.2G 0 disk ├─mmcblk0p1 179:1 0 1G 0 part /boot └─mmcblk0p2 179:2 0 56.6G 0 part /var/log.hdd / zram0 254:0 0 3.9G 0 disk [SWAP] zram1 254:1 0 200M 0 disk /var/log orangepi@orangepi5ultra:~$

orange pi 5 ultra Orange Pi 1.0.0 Jammy with Linux 5.10.160-rockchip-rk3588 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mtdblock0 31:0 0 16M 0 disk mmcblk0 179:0 0 58.2G 0 disk ├─mmcblk0p1 179:1 0 1G 0 part /boot └─mmcblk0p2 179:2 0 56.6G 0 part /var/log.hdd / zram0 254:0 0 3.9G 0 disk [SWAP] zram1 254:1 0 200M 0 disk /var/log [Thu Jul 9 13:41:39 2026] rk-pcie fe150000.pcie: PCIe Link Fail [Thu Jul 9 13:41:39 2026] rk-pcie fe150000.pcie: failed to initialize host