All Activity

Hello! I'm so glad you responded! I've been trying to reflash this device for three days. Unfortunately, the behavior after reflashing is always the same: the red LED lights up, goes out after 15-20 seconds, and the device no longer shows any signs of working. I've reflashed the device about 50 times with different settings. And of course, I checked the "Write to address" box. I built the firmware from your git - https://github.com/vidplace7/armbian-build/tree/luckfox-lyra-ultra I also built the firmware from the Armbian office git. There were no errors during the build. I've built the firmware from Debian and Ubuntu. I've also tried various methods (again, I've been trying to reflash the device for three days now). I'm desperate. Would you be so kind as to post the firmware that works 100% for you and tell me how to flash it correctly? I'm pinning all my hopes on you!

There's no problem of course, I just did not have time for this yet, and was asking if it's not pointless. Thanks for the response so far, I'll try...

Yeah I ended up ordering a refurbished office mini pc, might repurpose the android box for something else down the line, like a pihole or something. Moved the plex server to my desktop and running it like that atm. That was pretty much all I was using the box for. Thanks a lot for all the help!

Hi @Mayuyu, I burned the image "Armbian-unofficial_25.05.0-trunk_X96q-ddr3_bookworm_edge_6.12.11_server.img.xz" using Balena Etcher onto an SD card, then inserted it into the box and booted normally. Before that, I had tested the MiniArch-20231112-6.6.2-board-h313.x96_q-SD-Image.img image, and I found that it resolved my boot issue after performing an update.

@Malay You were really close, from what I can see in your screenshot. You need to check the "Write by Address" box when using the Windows tool there, everything else in the screenshot looks correct.

This means to me that there is a power problem. That can be complex, with a backfeeding situation that exists with the CPU box but not with other computer. Might be electronically something damaged now, not impossible even if it worked for weeks. Might a different U-Boot that does incomplete initialization or does finally something correct but as a consequence that your setup does not work anymore. I see things initiated in the kernel log, but what is what is not clear to me. So maybe have a look at lsusb (with proper options) output. I must also say that USB connected storage is something I avoid. Wasted loads of time on it on RPI4, eventually made own power-supply, also battery fed now, that was main reason for own electronics actually. Else I could also have sold it, I have RK35xx devices now and use SATA from those and 12V based power.

moved

Thanks for the tip regarding armbian logs. I have a hunch that the hub is not the problem as it worked before reimagine and works on windows. here’s armbian logs: https://paste.armbian.com/hinutehewa

Hi, I suggest you try with a different powered hub see if there's a difference. However, please provide logs with armbianmonitor -u

@Робертс Hi friend, I tried your instructions, but I'm probably doing something wrong. My situation is similar to yours. Could you please tell me step by step what you did to get the screen working? I tried following this article, but it looks like you're using a custom Linux installation. I watched Pancake's instructions; he's building his own Armbian. I'd really appreciate it if you could give me a step-by-step explanation of how you set up these devices. I'm using the base Armbian from orangepi version 6.1.31 I also tried this DTS, but had no success with it.

Hi @wolf7250, I'm not familiar with OMV, so not sure what that update/upgrade process looks like. If it will update/upgrade the armbian packages to the latest release 25.11, then the correct version of armbian-bsp-cli will be installed. The installation of that package should update /boot/boot.scr and make a new U-Boot image available that you would have to install with nand-sata-install. Gr,

Hello, I have been trying to get sound working on my Orange Pi Zero 3, and I am facing persistent issues. I installed every operating system listed on Armbian’s Orange Pi Zero 3 page and followed all the standard setup procedures. Despite updating all packages and even performing kernel updates, I have never been able to get any sound output from the device. I have checked multiple configurations, tried different OS images, and ensured that all drivers are up to date, but nothing works. The device otherwise functions normally, but audio simply does not come through under any circumstances. Could you please provide guidance or a solution? Any help would be greatly appreciated.

It looks like the training of AI bots is getting to a stall. Anyway, a knowledgeable contributor does not feed the bots. Instead, they judge if the info from the bot can save their life. Will this bot come to my house with food for free and put it into my mouth. Asking the bot to give money first might look a good first thing to do, but it isn't. Even if real coins or paper and not bank transaction.

Ok. This might have been caused by a partial update. Running OMV there is a script to run to update to the latest in that version - in my case v6. Once that completes successfully then I need to run a release update script which will increment the major version to 7. But I never got that far. So maybe if I do the quick workaround to get me onto the latest and then the correct U-Boot and bootscript will then be included as you said in the latest? Hope that all made sense 😁

Hi @wolf7250, The correct U-Boot and bootscript is for sure in the newest release. I built recently and all is there and working without issue on my helios4. Let's unravel what is happening for you and get that sorted out. Gr,

Disk genius in my case reveals there is NO FAT32 boot partition, hidden or otherwise, only a root partition.

(I prepared this spiel before I found this thread, but it still holds) /// Spent the last 2 days on this issue with an ALLWINNER image, not an AMLOGIC image. Back in October I had NO issue configuring this same image (downloaded to my nVME drive) on W11, with the same image, same copy of Balena etcher. PC 1 I flashed an Armbian community image onto an SD card (in a USB SD Card adapter), but was unable to see the FAT32 partition in Windows. I mounted the same USB in a VMware VM, and could only see one partition(!) I reflashed the image using dd (in VMware) and again only one partition was written. The flashed SD card (unconfigured for DTB etc) ran fine on my TV box. The default DTB setup clearly works. I loaded Linux Reader for Windows (LRFW) but had the same result, could not see a FAT32 boot partition. PC 2 I flashed the same image using etcher on a different Windows 11 PC. Same result on that PC, unable to see a FAT32 partition. (Back to) PC1 I Inserted the SD card adapter back into the first computer, and was able to see the root partition, mounted as armbi_root(F:) and also as armbi_root(i), but still no BOOT partition (maybe the LRFW software took a few minutes to start working). It seems to me the only variable is Windows 11 having some driver issue, since that's the only remaining variable I can think of. //// Does any knowledgeable contributor know of any POSSIBLE reason why etcher would now only write ONE partition, whereas previously it would write 2 partitions from the same image? Is anyone having this issue using only Linux as the dev environment? best John

Yes, I did update… not sure why it’s not picking it up. If I go with the quick workaround, will the correct U-Boot get applied in future updates?

Hi @wolf7250, That does not look like the new bootscript. Did you update already? To get it working again, you can try the quick workaround as you pointed to earlier, which should allow more room for U-Boot loading kernel, initrd and the rest. Gr,

Thanks @djurny, Here it is: U-Boot SPL 2019.04_armbian-2019.04-S3c99-Pcd6a-H9530-V0854-Bbf55-R448a (Nov 07 2025 - 04:24:07 +0000) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 6 | SATA0 | | 1 | 5 | USB3 HOST0 | | 2 | 6 | SATA1 | | 3 | 6 | SATA3 | | 4 | 6 | SATA2 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: mv_ddr-armada-18.09.2 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR Training Sequence - Start scrubbing DDR3 Training Sequence - End scrubbing mv_ddr: completed successfully Trying to boot from MMC1 U-Boot 2019.04_armbian-2019.04-S3c99-Pcd6a-H9530-V0854-Bbf55-R448a (Nov 07 2025 - 04:24:07 +0000) SoC: MV88F6828-B0 at 1600 MHz DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled) MMC: mv_sdh: 0 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** Model: Helios4 Board: Helios4 SCSI: MVEBU SATA INIT Target spinup took 0 ms. Target spinup took 0 ms. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Net: Warning: ethernet@70000 (eth1) using random MAC address - 8e:a7:83:0a:8c:60 eth1: ethernet@70000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2967 bytes read in 197 ms (14.6 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc 207 bytes read in 156 ms (1000 Bytes/s) 28834 bytes read in 618 ms (44.9 KiB/s) 13378189 bytes read in 2450 ms (5.2 MiB/s) 8678912 bytes read in 1749 ms (4.7 MiB/s) Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing... starting USB... USB0: MVEBU XHCI INIT controller @ 0xf10f4000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: MVEBU XHCI INIT controller @ 0xf10fc000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: device type unknown ... is now current device ethernet@70000 Waiting for PHY auto negotiation to complete...... done BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 192.168.1.145 (1271 ms) *** ERROR: `serverip' not set Cannot autoload with TFTPGET missing environment variable: pxeuuid missing environment variable: bootfile Retrieving file: pxelinux.cfg/01-06-5c-c4-a0-d4-d3 *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A80191 *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A8019 *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A801 *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A80 *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A8 *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0 *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm-mvebu *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/default *** ERROR: `serverip' not set Config file not found BOOTP broadcast 1 DHCP client bound to address 192.168.1.145 (3 ms) *** ERROR: `serverip' not set Cannot autoload with TFTPGET BOOTP broadcast 1 DHCP client bound to address 192.168.1.145 (5 ms) *** ERROR: `serverip' not set Cannot autoload with TFTPGET => ▒

Hi @wolf7250, Can you post the serial console output? Want to make sure the new U-Boot and bootscript are used. Gr,

Unfortunately I got the same error… Still says the error as below

Hi @wolf7250, Should be, yes. If not, do check back in here 🙂 Gr,

You can try, worse case it won't boot. What's the problem with that ? Only general. Switch to nightly repository and then switch to edge kernel: https://docs.armbian.com/User-Guide_Armbian-Config/System/#rolling https://docs.armbian.com/User-Guide_Armbian-Config/System/#alternative-kernels but if it won't work, you are on your own to find out why it doesn't work. Also some features won't work. We never supported EDGE kernels due to extreme costs associated with such operation.

Thanks @djurny! So the only thing I should need to do after/when upgrading is to run nand-sata-install? The rest of it should be handled by the packages in the update?