Active threads

Hello there, 👋 I've connected an NVMe drive that I used in my PC to the Banana Pi F3, but it's not being detected. I'm using a USB-C PD power supply (Pine64 PinePower Desktop) to ensure sufficient power, yet it's still not recognized. The drive might be faulty. Has anyone successfully used an NVMe drive with this board? If so, could you share which NVMe drives are known to work with it? Thanks! _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.5.1 for BananaPi BPI-F3 running Armbian Linux 6.6.87-current-spacemit Packages: Debian rolling (trixie) IPv4: (LAN) 192.168.1.185, 192.168.1.83 (WAN) 82.65.177.146 IPv6: 2a01:e0a:5ed:6230:fcfe:feff:fef8:f4be, 2a01:e0a:5ed:6230:3718:a97e:8a7b:a2c6 (WAN) 2a01:e0a:5ed:6230:9f8a:b5c1:f849:3f6f Performance: Load: 2% Up time: 1:31 Memory usage: 2% of 15.51G CPU temp: 45°C Usage of /: 12% of 113G Commands: Configuration : armbian-config Monitoring : htop [...] # Check PCIe-related kernel messages sudo dmesg | grep -E "(pcie|nvme|k1x-dwc)" # Check PCIe power management cat /sys/module/nvme_core/parameters/default_ps_max_latency_us # Monitor PCIe during boot sudo journalctl -b | grep -i pcie [ 0.404937] k1x-dwc-pcie ca400000.pcie: has no power on gpio. [ 0.407218] k1x-dwc-pcie ca400000.pcie: host bridge /soc/pcie@ca400000 ranges: [ 0.407260] k1x-dwc-pcie ca400000.pcie: IO 0x009f002000..0x009f101fff -> 0x009f002000 [ 0.407280] k1x-dwc-pcie ca400000.pcie: MEM 0x0090000000..0x009effffff -> 0x0090000000 [ 0.507413] k1x-dwc-pcie ca400000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G [ 1.507664] k1x-dwc-pcie ca400000.pcie: Phy link never came up [ 1.508176] k1x-dwc-pcie ca400000.pcie: PCI host bridge to bus 0001:00 [ 1.514835] pcieport 0001:00:00.0: PME: Signaling with IRQ 65 [ 1.515235] pcieport 0001:00:00.0: AER: enabled with IRQ 65 [ 1.515884] k1x-dwc-pcie ca800000.pcie: has no power on gpio. [ 1.518096] k1x-dwc-pcie ca800000.pcie: host bridge /soc/pcie@ca800000 ranges: [ 1.518126] k1x-dwc-pcie ca800000.pcie: IO 0x00b7002000..0x00b7101fff -> 0x00b7002000 [ 1.518150] k1x-dwc-pcie ca800000.pcie: MEM 0x00a0000000..0x00afffffff -> 0x00a0000000 [ 1.518164] k1x-dwc-pcie ca800000.pcie: MEM 0x00b0000000..0x00b6ffffff -> 0x00b0000000 [ 1.618263] k1x-dwc-pcie ca800000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G [ 2.618384] k1x-dwc-pcie ca800000.pcie: Phy link never came up [ 2.618513] k1x-dwc-pcie ca800000.pcie: PCI host bridge to bus 0002:00 [ 2.625055] pcieport 0002:00:00.0: PME: Signaling with IRQ 69 [ 2.625444] pcieport 0002:00:00.0: AER: enabled with IRQ 69 [ 8.000939] systemd[1]: Starting modprobe@nvme_fabrics.service - Load Kernel Module nvme_fabrics... [ 8.348576] systemd[1]: modprobe@nvme_fabrics.service: Deactivated successfully. [ 8.349624] systemd[1]: Finished modprobe@nvme_fabrics.service - Load Kernel Module nvme_fabrics. [ 9.227876] systemd[1]: nvmefc-boot-connections.service - Auto-connect to subsystems on FC-NVME devices found during boot was skipped because of an unmet condition check (ConditionPathExists=/sys/class/fc/fc_udev_device/nvme_discovery). 100000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: has no power on gpio. juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: host bridge /soc/pcie@ca400000 ranges: juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: IO 0x009f002000..0x009f101fff -> 0x009f002000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: MEM 0x0090000000..0x009effffff -> 0x0090000000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: Phy link never came up juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: PCI host bridge to bus 0001:00 juil. 04 19:00:44 bananapif3 kernel: pcieport 0001:00:00.0: PME: Signaling with IRQ 65 juil. 04 19:00:44 bananapif3 kernel: pcieport 0001:00:00.0: AER: enabled with IRQ 65 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: has no power on gpio. juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: host bridge /soc/pcie@ca800000 ranges: juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: IO 0x00b7002000..0x00b7101fff -> 0x00b7002000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: MEM 0x00a0000000..0x00afffffff -> 0x00a0000000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: MEM 0x00b0000000..0x00b6ffffff -> 0x00b0000000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: Phy link never came up juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: PCI host bridge to bus 0002:00 juil. 04 19:00:44 bananapif3 kernel: pcieport 0002:00:00.0: PME: Signaling with IRQ 69 juil. 04 19:00:44 bananapif3 kernel: pcieport 0002:00:00.0: AER: enabled with IRQ 69 poddingue@bananapif3 ~ $ # Enable all available kernel modules for NVMe sudo modprobe nvme sudo modprobe nvme-core sudo modprobe nvme-pci # Check if modules loaded lsmod | grep nvme modprobe: FATAL: Module nvme-pci not found in directory /lib/modules/6.6.87-current-spacemit nvme_fabrics 118784 0

Ok the backlight turning on confirms that it uses PWM0. It is worth noting at this point that PWM works but is not perfect on the A10 as the pwm-sun4i driver assumes all devices are 16-bit resolution however only the lower 8-bits are only valid on the A10. Looking into this again it would probably make it easier for yourself to include the panel parameters within the DTS as well. As mention earlier the "starry,kr070pe2t" is included within panel-simple.c. What is the current output of sudo dmesg | grep drm? I am curious to see if there is even an attempt to bind the panel. All the best Ryzer

do you have correct permissions? maybe run as root on my rock3a content is fine but got [Jul 4 20:19] warn_alloc: 19 callbacks suppressed [ +0.000026] dec0:0:hevc_rkm: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=user.slice,mems_allowed=0 [ +0.000115] CPU: 2 PID: 2339021 Comm: dec0:0:hevc_rkm Not tainted 6.1.115-vendor-rk35xx #1 [ +0.000011] Hardware name: Radxa ROCK3 Model A (DT) [ +0.000011] Call trace: [ +0.000008] dump_backtrace+0xf0/0x12c [ +0.000023] show_stack+0x20/0x30 [ +0.000011] dump_stack_lvl+0x7c/0xa0 [ +0.000016] dump_stack+0x18/0x34 [ +0.000010] warn_alloc+0xe0/0x17c [ +0.000012] __alloc_pages+0x524/0x854 [ +0.000010] __kmalloc_large_node+0xb8/0x114 [ +0.000012] __kmalloc+0x4c/0x100 [ +0.000009] __regset_get+0x60/0xd8 [ +0.000013] regset_get_alloc+0x1c/0x28 [ +0.000010] elf_core_dump+0x500/0xbc8 [ +0.000011] do_coredump+0xabc/0x100c [ +0.000012] get_signal+0x1b8/0x634 [ +0.000013] do_notify_resume+0x194/0xda8 [ +0.000010] el0_da+0x5c/0x70 [ +0.000012] el0t_64_sync_handler+0xc0/0x13c [ +0.000010] el0t_64_sync+0x19c/0x1a0 [ +0.000013] Mem-Info: [ +0.000010] active_anon:112109 inactive_anon:125820 isolated_anon:0 active_file:31285 inactive_file:45270 isolated_file:0 unevictable:0 dirty:2210 writeback:0 slab_reclaimable:16665 slab_unreclaimable:16446 mapped:15455 shmem:105 pagetables:1861 sec_pagetables:510 bounce:0 kernel_misc_reclaimable:0 free:82604 free_pcp:125 free_cma:35560 [ +0.000022] Node 0 active_anon:448436kB inactive_anon:503280kB active_file:125140kB inactive_file:181080kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:61820kB dirty:8840kB writeback:0kB shmem:420kB writeback_tmp:0kB kernel_stack:4192kB pagetables:7444kB sec_pagetables:2040kB all_unreclaimable? no [ +0.000017] DMA free:330416kB boost:14364kB min:19988kB low:21964kB high:23940kB reserved_highatomic:2048KB active_anon:448188kB inactive_anon:503568kB active_file:125312kB inactive_file:181216kB unevictable:0kB writepending:8840kB present:2095104kB managed:2014252kB mlocked:0kB bounce:0kB free_pcp:544kB local_pcp:0kB free_cma:142240kB [ +0.000018] lowmem_reserve[]: 0 0 0 0 [ +0.000015] DMA: 20626*4kB (UMEHC) 16291*8kB (UMEHC) 4462*16kB (UMHC) 1263*32kB (UMHC) 92*64kB (MHC) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 330528kB [ +0.000049] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [ +0.000010] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB [ +0.000008] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ +0.000009] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB [ +0.000008] 129311 total pagecache pages [ +0.000007] 52636 pages in swap cache [ +0.000006] Free swap = 11240188kB [ +0.000007] Total swap = 11792380kB [ +0.000006] 523776 pages RAM [ +0.000006] 0 pages HighMem/MovableOnly [ +0.000006] 20213 pages reserved [ +0.000007] 135168 pages cma reserved command used /usr/share/jellyfin-ffmpeg/ffmpeg -y -c:v hevc_rkmpp -i 2025-06-29_22-05_rec.ts -map v -c:v h264 _rkmpp -b:v 8000k -map 0:1 -c:a copy -t 300 dvbt2.h264.ts

I have a BananaPi M1, same SoC, same kernel (the upgrade went fine for me last week). Although I only use it for its SATA connector (big HDD as NBD, OS on SD-card), audio 3.5mm plug did work. Maybe I could see what mine does, but rather with a default Debian player, like mpv, works via ssh CLI. I can generate some FLAC file, but I don't want to search for the specific song/title. Also I could do a temp exfat on a loopdev or so or just play from NFS, Btrfs or Ext4 loopdev.

Good to meet a fellow armbian android tv box fan. We need a logo or shorthand alias for fans 🤣. ZFS - was easy but not clear. Inside armbian-config under System/Storage is a script to install ZFS support. I did this and it didn't work... then undid it and then installed it a second time and it worked. Somewhere in there I also ran the standard commands for install: sudo apt install zfsutils-linux sudo apt install zfs-fuse Probably after the first uninstall... but the commands indicate failure. But then installing the second time seemed to work. Did that on both of these boxes I have working. Thanks for the ethtool command. Here's my results on box1 ports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: Twisted Pair PHYAD: 0 Transceiver: external MDI-X: Unknown netlink error: Operation not permitted Current message level: 0x0000003f (63) drv probe link timer ifdown ifup Link detected: yes Not an expert and first time reading this command but looks like 1000 is the answer. Crazy thing - box 2 does not have the line "MDI-X: Unknown" shown towards the bottom and "Port: MII" instead of "Port: twisted pair" but is otherwise identical. Posting in case it helps anyone else - but these are beyond me. If you confirm that the above = 1000 I will update both my box running posts. By the way - Another favorite is Software/Management/Cockpit. Easy to see how the server is doing. Plus it has a built in terminal and file manager. Add that to Tailscale and you can check on the server or grab a file while out of the house. curl -fsSL https://tailscale.com/install.sh | sh Those are my favorites. What are yours?

The way I understand it is that you only need the full firmware package in a few exceptional circumstances. What is the wifi chipset on your SBC? Do you have the wireless-regdb package installed? "dpkg -l wireless-regdb"

Thank you for sharing. Would be good to have your findings corroborated by some of official documentation. Thanks again for sharing.

If they boot, I wouldn't worry about any difference.

I know, but who cares if it is impractical IMO and various distros by default use that path. And RPiOS needs /boot/firmware, I myself use also /boot/uboot so I am more flexible w.r.t bootloaders. What is on boot FAT or in SPI-flash or tftpboot or else is secondary, the master (from package manager) is in rootfs. Read back my 1st message; there is option -p A snapshot is identified by its UUID, whether local or remote/other/foreign filesystem. So my backup tool/script figures that out. If an SD-card would be end of life or damaged scrub will notice it and then I regenerate the whole thing on a new SD-card from the latest transferred snapshot. I do not use /home for any meaningful data. All is on NAS. Some have no local storage except SPI for bootloader. I also treat all Linux computers the same, except those that are NAS or a clone of it. For rare Windows I indeed use 'imaging' although there is WinBTRFS.

sounds good. good luck and keep us posted!

this is somewhat 'off-topic' but still relevant to 'orange pi zero 3' If Orange Pi Zero 3 is operated in warm climates (e.g. room temperature 30 deg C etc) , it can at times run up to like 60 deg C. this is in open still air adding a fan blowing at it reduce that by some 20 deg C to 40 deg C ! And this is my ghetto fan setup, no fancy case, no heatsink nothing, just a single long machine screw that lifts it up checking temperatures is easy > armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 18:03:39 480 MHz 0.00 0% 0% 0% 0% 0% 0% 40.8 °C 0/7^C strictly speaking, 60 deg C is 'nothing to scream about' , I've a Rpi 4 hitting up 80 deg C and it throttles. similarly use a fan blowing at it + a heat sink over the cpu, drastically reduce running temperatures. for 'occasional' use, I don't think it is necessary to have a fan blowing at the Orange Pi Zero 3. I think it is feasible to run at lower temperatures if I disable and unclock the GPU and HDMI, but for now I'm not sure how to go about doing that. Initially, I'm thinking maybe the wifi is causing it, but now I don't think so, it is moderately likely the gpu is heating it up a bit. And still air don't seem to dissipate heat very well.

The image from https://dl.armbian.com/orangepi5/Noble_vendor_gnome works well for me. It might be good to see some GDM logs as i am not sure where the problem arises from.

Hello @Aknot, better late than never? This is likely because USB OTG support is on out of the box now. You used to have to add an overlay to get it to work. You will need to modify the the overylays to change this.

I disassembled my tv box - there are 4 screws under the 4 rubbery feet. Removed the motherboard and I drilled some holes of 1/4 inch (7 mm) diameter through the bottom plastic piece. Then I placed a USB fan underneath the tv box and wow the temperature really goes down and stays down around 45 C to 60 C depending on work load. The fans are 80mm and 120mm in size. I chose 120mm to be sure.

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!

Well its equivalent so other than vendor not beeing in a database does not count as custom in my books, but that is beside the point. Armbian correctly recognizes the size and I can write to it and that is important. Now flashing an existing image is simple. My preferred way is dd as described by Piter75: dd if=uboot.img of=/dev/mtdblock0 bs=4K for u-boot images and dd if=idbloader.img of=/dev/mtdblock0 seek=64 bs=512 conv=sync dd if=u-boot.itb of=/dev/mtdblock0 seek=16384 bs=512 conv=sync if used with image tree blob. Nice thing is that if new u-boot hangs or does not boot I can just short pin 23-25 to boot from SD card and try again. Since I have an 8Mb flash I would really like to bake in m.2 to SATA drivers - for ASM1166 in my case. Any pointers are welcome. DeMo

As part of the activities Embedded Recipes in Nice, France, Collabora hosted a PipeWire workshop/hackfest, an opportunity for attendees to meet face-to-face with PipeWire developers and participate in direct discussions about the future of PipeWire. View the full article

I am always happy to see people keeping old hardware running. But I think it would be best to make the necessary changes in Armbian itself. I am happy to help out where I can be useful.

The ones I linked. You mentioned that you have no experience to compile stuff. One option is to target another SBC or a virtual machine so that you can focus on learning the build framework (explicit instructions are already given in some of the links) instead of having to deal with a multitude of issues (setting up your compilation host, getting compilation to succeed, finding the artifact to flash, only to then run into the next issue that armbian currently does not support your board). With a virtual system, you can be sure that you should get a working image. You can then focus on the compilation and familiarize yourself with that before jumping into real hardware enablement.

Do you have specific instructions for installing the X96 X6? @Chris4arm Thank you very much.

Ok I was able to get the LCD working with a self built image, by copying the linux config from the armbian.com image to the build/userpatches/linux-sunxi64-edge.config Currently rebuilding without the successful linux config, and then I will look at the difference Update: I didn't find any differences and the new image without the userpatches config accepts the LCD DTS and bin file. Ok, I dont understand what was happening before. Now I am getting the same X11 error as before: MESA-LOADER: failed to open panel-mipi-dbi: /usr/lib/dri/panel-mipi-dbi_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/aarch64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri) I see that this panel-mipi-dbi_dri.so is part of libgl1-mesa-dri debian package, in DEBIAN SID, but not Bookworm https://packages.debian.org/sid/arm64/libgl1-mesa-dri/filelist https://packages.debian.org/bookworm/arm64/libgl1-mesa-dri/filelist Next, when I rebuilt the armbian OS with xfce desktop, I get the same panel-mipi-dbi-spi error: can't find the bin file. I checked the config again... and it was the same Update: It was easier to build Sid minimal, and install labwc (wayland), just remember to install seatd: https://eirenicon.org/labwc-a-tutorial/ I isolated why the panel-mipi-dbi-spi can't load when I apply it in an Armbian OS with XFCE. xcfe requires plymouth, and plymouth does something to the uInitRd And when I reboot immediately after installing plymouth, the SPI LCD does not start, and dmesg shows that panel-mipi-dbi-spi could not find the firmware file.

Hello everyone, I have an old POS machine that uses the Rockchip RK3288 processor. It has a 1920x1080 screen and works fine, but I don’t have any root or bootloader unlock permissions. I would like to flash Armbian on it and make better use of the device. So far I’ve tried: ADB access (only recovery available) Tried using adb reboot bootloader, but the device just powers off Identified some test points like KEY, T3, T2, T52, T51, but not sure which one is for MaskROM shorting Found no physical recovery button, only a reset and power button There might be a UART port, but I’m not sure 👉 Can someone please help me: Identify which test points or pads I can short to enter MaskROM mode Locate a possible UART debug port on the board Any advice for dumping original firmware or unlocking bootloader I've attached front and back photos of the mainboard. Any suggestions or experience with RK3288 boards are greatly appreciated! Thank you 🙏

FYI: I managed to fix my eMMC again, I found a working spl_loader bin file to flash with rkdeveloptool. See the following post for details:

To add a datapoint: In the past, I've been succesfully installing to eMMC using `armbian-install` using an Armbian 24.2.1 Jammy image. IIRC I had to change the `ftdfile=` line in `/boot/armbianEnv.txt` (as documented at https://www.armbian.com/orangepi-5/) but it otherwise worked right away. Now recently I have been playing with newer bootloaders and images and kernels (in order to fix an issue where a reboot hangs), and in that process I updated the U-boot on the eMMC, which caused booting from eMMC to fail, and when booting from SD card, I no longer have the eMMC device so I cannot fix this (I think this might be exactly what @sns1081 describes in the first post of this topic). I've been trying to fix this (see this post for details), but on my previous attempt I could not get `rkdeveloptool` to work: it kept giving "Write LBA failed!" errors on on the `wl` command. I suspected this was because I needed the `db` (download bootloader) command first to download and run a bootloader to then handle the `wl` command, but I could not find the right spl_loader file. But with this thread (and in particular this post by @Andrius Vainorius) offered a filename I could google and then found it here: https://dl.radxa.com/rock5/sw/images/loader/rock-5b/release/ With that, at least the db and wl commands work: ❯ sudo ~/bin/rkdeveloptool db ~/Downloads/rk3588_spl_loader_v1.15.113.bin Downloading bootloader succeeded. ❯ sudo ~/bin/rkdeveloptool wl 0 some_img.img Write LBA from file (100%) For this, I cannected USB-C cable to the J11 USB connector in the middle, powered up via the USB-C connector in the corner and pressed the maskrom button on powerup. Note that it did not seem to be necessary to have the rkdeveloptool and the images to write in the same directory, as suggested by others here. Note that the the "some_img.img" is an image I lifted from an SD-card with Armbian 24.2.1 Jammy, so it is not the original clean image, but it does have the same stuff on it. Just the above commands recovered my board: It can boot from eMMC again and the /dev/mmcblk0 eMMC device is available again (both when booting from eMMC and when booting from SD). Analyzing why eMMC was broken before, I compared the serial output from the broken and fixed cases. The main difference is here seems to be the u-boot SPL version. AFAIU, this is what happens: Some ROM bootloader boots, which loads U-boot SPL from eMMC U-boot SPL checks SD-card and then eMMC to load the main U-boot Maybe there is another bootloader stage involved (between ROM and SPL, since there is some serial output before SPL shows up that is different between both cases). Here's a diff of the serial output between both cases (up to the moment where U-boot runs and no more interesting differences appear): --- old-opi5.txt 2025-07-02 21:20:08.631329154 +0200 +++ old-opi5-emmc-fixed.txt 2025-07-02 23:01:17.982196616 +0200 @@ -1,26 +1,24 @@ -üDDR d5483af87d cym 23/11/23-16:15:24,fwver: v1.15 +þDDR V1.11 f1474cf52f cym 23/05/09-11:02:36 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB Manufacturer ID:0x1 -CH0 RX Vref:29.3%, TX Vref:22.8%,21.8% -CH1 RX Vref:28.9%, TX Vref:20.8%,21.8% +CH0 RX Vref:28.5%, TX Vref:23.8%,22.8% +CH1 RX Vref:29.3%, TX Vref:20.8%,20.8% CH2 RX Vref:29.3%, TX Vref:22.8%,21.8% -CH3 RX Vref:27.9%, TX Vref:20.8%,20.8% +CH3 RX Vref:26.7%, TX Vref:21.8%,21.8% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL board init -U-Boot SPL 2017.09 (Feb 25 2025 - 08:48:59) -sfc cmd=9fH(6BH-x4) -unrecognized JEDEC id bytes: ff, ff, ff -unknown raw ID ff ff ff -Trying to boot from MMC2 -spl: partition error +U-Boot SPL 2017.09 (Feb 09 2024 - 18:56:36) +unknown raw ID 0 0 0 +unrecognized JEDEC id bytes: 00, 00, 00 +Trying to boot from MMC1 Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7efcd01a0f...) + OK @@ -29,7 +27,7 @@ ## Checking atf-2 0xff100000 ... sha256(1163474a5b...) + OK ## Checking atf-3 0x000f0000 ... sha256(da90adf3a4...) + OK Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000) -Total: 304.579/460.237 ms +Total: 245.95 ms INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang @@ -42,11 +40,10 @@ INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: system boots from cpu-hwid-0 INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 -ERROR: dfs get fsp_params[0] error, 0xfead0004 != 0xfead0003 -ERROR: dfs get fsp_params[1] error, 0x1111 != 0xfead0003 -ERROR: dfs get fsp_params[2] error, 0x0 != 0xfead0003 -ERROR: dfs get fsp_params[3] error, 0x60241520 != 0xfead0003 -ERROR: loader&trust unmatch!!! Please update trust if need enable dmc +INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz +INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz +INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz +INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK @@ -67,18 +64,8 @@ CR: M/C/I Using default environment -no mmc device at slot 1 -Card did not respond to voltage select! -do_rkimg_test: dev_desc is NULL! mmc@fe2c0000: 0, mmc@fe2e0000: 1 -Card did not respond to voltage select! -PCIe-0 Link Fail - -Device 0: unknown device -Card did not respond to voltage select! -switch to partitions #0, OK -mmc0 is current device -Bootdev(scan): mmc 0 +Bootdev(atags): mmc 0 MMC0: Legacy, 52Mhz PartType: EFI DM: v2 Since in both cases, the main U-boot (Feb 09 2024) runs from the SD-card, I suspect that the U-boot SPL (or the preceding bootloader, if any) is somehow involved in setting up the eMMC properly, and the new one does not do the setup properly (or otherwise messes something up). Next things I could try are: Flash a recent Armbian image (different version/flavors) to eMMC using rkdeveloptool and see if any of those produce a working system/eMMC. Figure out how the boot process *really* works and what parts of the eMMC are loaded in what order and how Compare a working and broken armbian image (in the areas that contain bootloader-stuff) and swap out some of these parts to see what is the part that breaks it. However, my main issue is fixing reboots on the older armbian system we are using, so I might not get around to the above anytime soon (OTOH, it seems the newer U-boot SPL actually fixes the reboot issue, so that could motivate me to see if we can upgrade to the new u-boot version without losing eMMC).

I did so, but openvfd still doesn't work and can't compile.