All Activity

That's great. Thanks for sharing.

@PH Ph bootloader -> /dev/block/mmcblk0p1 Maybe this is the boot.bin we are looking for? Try extracting it with Android_boot_image_editor.

Hi @Nick A, I think I'm doing something wrong, but here goes. cat /proc/partitions major minor #blocks name 1 0 8192 ram0 1 1 8192 ram1 1 2 8192 ram2 1 3 8192 ram3 1 4 8192 ram4 1 5 8192 ram5 1 6 8192 ram6 1 7 8192 ram7 1 8 8192 ram8 1 9 8192 ram9 1 10 8192 ram10 1 11 8192 ram11 1 12 8192 ram12 1 13 8192 ram13 1 14 8192 ram14 1 15 8192 ram15 254 0 745120 zram0 179 0 31166976 mmcblk0 179 1 32768 mmcblk0p1 179 2 16384 mmcblk0p2 179 3 32768 mmcblk0p3 179 4 2097152 mmcblk0p4 179 5 16384 mmcblk0p5 179 6 32768 mmcblk0p6 179 7 911360 mmcblk0p7 179 8 16384 mmcblk0p8 179 9 16384 mmcblk0p9 179 10 16384 mmcblk0p10 179 11 16384 mmcblk0p11 179 12 16384 mmcblk0p12 179 13 512 mmcblk0p13 179 14 15872 mmcblk0p14 179 15 16384 mmcblk0p15 259 0 16384 mmcblk0p16 259 1 27858432 mmcblk0p17 253 0 1241204 dm-0 253 1 146376 dm-1 253 2 113948 dm-2 ls -al /dev/block/platform/soc/sdc0/by-name/ total 0 drwxr-xr-x 2 root root 380 1969-12-31 21:00 . drwxr-xr-x 3 root root 420 1969-12-31 21:00 .. lrwxrwxrwx 1 root root 21 1969-12-31 21:00 Reserve0 -> /dev/block/mmcblk0p16 lrwxrwxrwx 1 root root 21 1969-12-31 21:00 UDISK -> /dev/block/mmcblk0p17 lrwxrwxrwx 1 root root 20 1969-12-31 21:00 boot -> /dev/block/mmcblk0p3 lrwxrwxrwx 1 root root 20 1969-12-31 21:00 bootloader -> /dev/block/mmcblk0p1 lrwxrwxrwx 1 root root 20 1969-12-31 21:00 cache -> /dev/block/mmcblk0p7 lrwxrwxrwx 1 root root 21 1969-12-31 21:00 empty -> /dev/block/mmcblk0p14 lrwxrwxrwx 1 root root 20 1969-12-31 21:00 env -> /dev/block/mmcblk0p2 lrwxrwxrwx 1 root root 21 1969-12-31 21:00 frp -> /dev/block/mmcblk0p13 lrwxrwxrwx 1 root root 21 1969-12-31 21:00 media_data -> /dev/block/mmcblk0p15 lrwxrwxrwx 1 root root 21 1969-12-31 21:00 metadata -> /dev/block/mmcblk0p11 lrwxrwxrwx 1 root root 20 1969-12-31 21:00 misc -> /dev/block/mmcblk0p5 lrwxrwxrwx 1 root root 21 1969-12-31 21:00 private -> /dev/block/mmcblk0p12 lrwxrwxrwx 1 root root 20 1969-12-31 21:00 recovery -> /dev/block/mmcblk0p6 lrwxrwxrwx 1 root root 20 1969-12-31 21:00 super -> /dev/block/mmcblk0p4 lrwxrwxrwx 1 root root 20 1969-12-31 21:00 vbmeta -> /dev/block/mmcblk0p8 lrwxrwxrwx 1 root root 20 1969-12-31 21:00 vbmeta_system -> /dev/block/mmcblk0p9 lrwxrwxrwx 1 root root 21 1969-12-31 21:00 vbmeta_vendor -> /dev/block/mmcblk0p10 I couldn't open vendor.img boot.img i do.However, I couldn't find the dts file, only fstab, initd, and a few other empty folders. I posted the images below on 4shared. boot = boot.img vbmeta_vendor = vendor.img boot.img (32.0MB) Image type: Boot image Header version: 2 Command line arguments: selinux=1 androidboot.selinux=permissive androidboot.dtbo_idx=0,1,2 buildvariant=userdebug files avp folder s-gsi.avbpubkeyq-gsi.avbpubkeyr-gsi.avbpubkey fstab.sun50iw9p1 initrd.gz If you can check, I would appreciate it; I await further instructions. !off I tried mounting the partitions by inserting the burned SD card into the PC, but it's not possible to mount them. Except for a few... The SD card made by Phoenixcard is quite interesting. Could it be that the scheme on the SD card is not the same as when installed in the internal memory? The Udisk partition, for example. It's like shared memory, expanding all remaining space on both the memory card and the datauser partition. Similar to using a formatted SD card as internal memory on cell phones with that option.

Thank you ill go look

See my recent posts in the 64gb thread. You'll need to build an image with MAE0621A-02C support. The same thread will also give you dinner hints for to make the WiFi work with aic8800.

Thank you all guys. I tried another way, and finally successfuly boot from NVMe. For others whoever might have this situation, I leave a note here. Get the official Radxa OS for rock (5c|5c lite). Get the vendor Armbian for rock (5c|5c lite). Make a sd card with Radxa image. Plug sd card into PC(not Rock 5c), and copy Armbian img file(ex. Armbian_25.11.1_Rock-5c_trixie_vendor_6.1.115_minimal.img) to the sd card(to /home/radxa or wherever). Boot Rock 5C(lite) with the sd card. Login to Radxa OS, run rsetup and set overlay with SPI boot loader. Reboot. run rsetup again, and update the SPI Bootloader. There are 2 bootloader options, rock 5c and rock 5c SPI bootloader, and I chose SPI bootloader. Then, dd Armbian Image to NVMe device. There's a Instructions. (dd if=Armbian_xxx.img of=/dev/nvme0n1 bs=1M status=progress) Power off, remove SD card and Power On! You can boot from NVMe!

yeah, this is quite helpful, although the best solution is to wait at least until 6.19. But now I can see that the board was not abandoned, which I was a bit worried about. It seems to be a nice entry-level option and compatibility of both boards with rpi5 HATs due to the exposed PCIe is a great feature. I found the A53 cores quite speedy on Rock 2F and also not to produce much heat. That's why I might have been a bit impatient (I want to be able to use the pcie with mainline fixes).

Hey! Got it up and running - I have an Armbian SD card image based on the source trees found on https://github.com/orangepi-xunlong. Since I am a newbie to Armbian, please accept my apologies for beginner errors. Here's what I currently got on my UART: root@orangepirv2:~# uname -a Linux orangepirv2 6.6.63-current-ky #1 SMP PREEMPT Tue Mar 18 02:29:27 UTC 2025 riscv64 GNU/Linux root@orangepirv2:~# cat /etc/os-release PRETTY_NAME="Armbian-unofficial 26.02.0-trunk trixie" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie DEBIAN_VERSION_FULL=13.2 ID=debian HOME_URL="https://www.armbian.com/" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" ARMBIAN_PRETTY_NAME="Armbian-unofficial 26.02.0-trunk trixie" This is not ready for prime time now. Needs a bit cleanup b/c I pulled in binaries and private project stuff not meant for armbian-build. Currently resides in this fork https://github.com/sven-ola/armbian-build/tree/orangepi-rv2. If you want to give it a try: it's compile.sh opirv2 after checkout. I've also managed to boot from the top 2230 M.2 SSD but this is also handmade (I'm pretty sure there is a script in here that copies the SD card boot blobs to SPI flash, will try before doing the MR). Best // Sven-Ola

The rock-5b SPI uBoot compile config suggested by Werner is for the mainline uBoot and it didn't work with the uBoot on rock-5c although I thought it might. I tried to build you an unsupported image using the uBoot config from rock-5b, but unfortunately the build failed. Rock 5b is heavily hacked for uBoot to use a hybrid mainline uBoot with bits of Rockchip stuff. The function pre_config_uboot_target__rock5b_patch_uboot_dtsi_for_ums() won't work because the rock-5c dtsi doesn't have the same stuff, but this won't matter for vendor build. I will spend a bit of time trying to get it to build with all of the relevant rock-5b conf mods, but that is about the limit of what I can do because I don't have an NVME hat or a SPI flash module or the lite version of the radxa rock 5c or experience with the SPI subsystem. The NVME hat may not have the same device tree overlay as the built in NVME on the rock-5a. There is no reason to believe that the rock-5a-spi-nor-flash device tree overlay for the rock-5a will work correctly for the rock-5c. However you seem to indicate that the SPI module and NVME is working/accessible using the vendor kernel. This does not mean that they will work with uBoot. This may be relevant https://forum.armbian.com/topic/47090-radxa-rock5c-pentahat-and-emmc Building Armbian yourself is pretty easy if you want to experiment with current and edge mainline kernels. https://docs.armbian.com/Developer-Guide_Overview/

Hello, fellow H96 musers. I've just acquired a 4G/32G H96 Max V56, and tried to flash an image that works on an earlier 8G/64G H96 Max V56, using the appropriate 4G booloader rather than the one I used for the 8G. The HAOS image boots fine, but everything about the Ethernet and WiFi must be wrong, as I have no networking hardware configured. I'm curious to know if there are differences between the 4G/32G board and the 8G/64G, other than eMMC size, that might account for the above outcome? There was some early mention of 'type 1' and 'type 2' 4G/32G boards early on in this thread. Could I be using an inappropriate device tree source configuration for my 4G/32G board? If that's not it, then the only other thing I can think of, is that the 4G/32G board I recently acquired has different WiFi/Bluetooth and Ethernet chips fitted, and the drivers from my 8G/64G build aren't suited? 8G/64G H96 Max V56 PCB: LP6E27116A0 Wifi/BT: HC16335, S3144335 Ethernet: Realtek, RTL8211 4G/32G H96 Max V56 PCB: LS6E28533A0 Wifi/BT: SKI.WB800D80S.1_D40, 2023AP20230(M) Ethernet: Maxio, MAE0621A-02C Thoughts, board type clarification, or driver suggestions, anyone? GBEM 👽 p.s. If anyone has the stock rom for this box I'd be entirely grateful. Through absent mindedness, I foolishly didn't preserve mine.

Hi, Board: Radxa ROCK 5T SoC: RK3588 Armbian image: Armbian 25.11.2 for Rock 5T Kernel: 6.1.115-vendor-rk35xx Userspace: Debian stable (trixie) U-Boot package: linux-u-boot-rock-5t-vendor 25.11.2 (arm64) u-boot-tools: 2025.01-3 Boot device: NVMe (/dev/nvme0n1), Armbian 25.11.2 for Rock 5T https://paste.armbian.com/opokufetux Summary On ROCK 5T, a normal reboot performs a clean shutdown (all services stopped, filesystems unmounted) but the board does not restart. After reaching Reached target reboot.target - System Reboot., the system hangs for some time and then repeatedly prints an interrupt/IRQ table (GICv3/ITS) on the console. A hardware power cycle is required to recover. Reboot is therefore unreliable / effectively broken. Poweroff hangs in the same way as reboot (clean shutdown, then IRQ table on screen, board does not actually power down). Configuration details Relevant /boot/armbianEnv.txt (current state): verbosity=1 bootlogo=false console=both extraargs=cma=256M reboot=warm sysrq_always_enabled=1 overlay_prefix=rockchip-rk3588 fdtfile=rockchip/rk3588-rock-5t.dtb rootdev=UUID=fbf76c4c-167a-49b2-81a4-e1b0220e8cac rootfstype=ext4 overlays= usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u /proc/cmdline confirms the kernel parameters are applied: root=UUID=fbf76c4c-167a-49b2-81a4-e1b0220e8cac rootwait rootfstype=ext4 splash=verbose console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart= usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cma=256M reboot=warm sysrq_always_enabled=1 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory androidboot.fwver=ddr-v1.18-9fa84341ce,bl31-v1.48,uboot-rmbian-201-09/01/2025 Observed behavior Run sudo reboot. Systemd performs an orderly shutdown: services are stopped, all filesystems (including NVMe root) are unmounted or remounted ro, shutdown target is reached: Reached target reboot.target - System Reboot Instead of resetting and returning to U‑Boot, the board hangs. After some time, the HDMI console repeatedly prints a tall table of interrupts (GICv3/ITS entries, many zeros, some counters for PCIe/NVMe, USB, etc.), and never actually reboots. Only cutting power recovers the board. The system otherwise runs stably under load; NVMe, PCIe, network, and filesystem are all healthy. Workaround As a workaround, the reboot target was overridden to trigger a SysRq hard reset after a brief delay, so that services can shut down cleanly first: /etc/systemd/system/systemd-reboot.service.d/override.conf: [Service] ExecStart= ExecStart=/bin/sh -c 'sleep 5; echo 1 > /proc/sys/kernel/sysrq; echo b > /proc/sysrq-trigger' TimeoutStartSec=0 With this override in place: sudo reboot now: does a normal orderly shutdown, waits ~5 seconds at the end, then does SysRq + b to force a full reset, the board reliably returns to U‑Boot and boots again. This confirms that: clean shutdown works, a forced hardware reset works, but the normal reboot path used by the vendor RK3588 stack on ROCK 5T leaves the SoC in a bad state (seen as GIC/interrupt dump on screen) instead of performing a full reset. What I think is wrong It looks like the firmware/bootloader + vendor kernel combination on ROCK 5T does not properly implement the reboot sequence (PSCIs / PMIC / reset controller), so after Linux hands control over, the hardware stays in some half‑reset state and keeps generating spurious interrupts instead of resetting GIC/PCIe/etc. completely. The fact that SysRq + b from a fully running system does give a clean hardware reset suggests there is a working reset path, but the normal reboot path used by systemd / kernel is not using it correctly. Could you: Confirm whether this is a known issue for: Rock 5T specifically, or the 6.1.115-vendor-rk35xx kernel / current U‑Boot/BL31 bundle for rk3588 on Armbian? Advise whether there is: a newer U‑Boot / ATF / device‑tree combination that fixes reboot on Rock 5T, or a recommended kernel parameter / DT change (e.g. different PSCI reset mode, watchdog reset, etc.) to get a reliable soft reboot without the hard SysRq fallback? If needed, provide debug instructions (extra bootargs, specific logs around PSCI/reset) so the issue can be characterized better. I can provide: full dmesg from a normal boot, photos or serial logs of the IRQ table that appears after reboot hangs (GICv3/ITS dump on HDMI), U‑Boot version / environment if required. Thanks in advance for looking into this.

In fact, image boot very well with minimal change. (dtb change and something about virtual console) It' s after 🥲

They are not empty. You need to go one level deeper: https://armbian.nardol.ovh/dl/tinkerboard/archive/ BTW, try https://github.com/armbian/imager It will be much easier.

I though some older images worked ... here you are on your own. Compare device tree from cubox and this hardware and repeate this on modern kernel, and apply difference. Just an idea. Sadly, no simple solution such as download and play.

https://fi.mirror.armbian.de/archive/tinkerboard/archive/

Hi Igor, Thanks for the link But i think I have already tried all proposed kernels without any luck so far. There is no error in logs, just it doesn't work at all. Interface doesn't bring up with or without dhcp.

If you need older images for cubox-i, archive and oldarchieve at https://fi.mirror.armbian.de/

Hello, Using the last image for cubox-i (bookworn) , I m unable to get an access to internet using the default interface. eth0 is détected but non functionnal, no eth1 card and no wifi card detected This is a known problem : Does someone has a recent kernel for this device ? I've an old defconfig for kernel 5.2.1 that works (eth0 , eth1 and wifi too) I'm slowly using this defconfig to build a more recent one (5.4.302 is ok but EOL...) Many thanks

Ok, fair enough, but all the mirros all seem empty, regardless of board type....

3b is not a supported board, therefore mirror does not have up-to-date images. Check 2nd link I provided

Hi All, It seems like all boards are missing current images, at least on the mirrors I checked.... @Werner even in the links you are mentioning, only the archive folder has older images.

Well, I finally used some disk drives to move the btrfs data live, repartition with GPT using a vFAT and btrfs partition with 16MB offset of u-boot before the first partition, so with this boots automatically, and I guess more mainline. Thanks @eselarm for your comments, I'll these variables later.

This is NOT a support request, more of a brag. Needing a backup system, I was enamored of the low power requirements to run the bpi-m5. But they have no sata ports to drive bigger SSD's. But I bought a 5 stack of 4Tb TMSC built SSD drives at $200/copy, figuring on using a USB3.2 hub and startech's usb3.2 to sata adaptors, a big drive cage and a 50 watt 5 volt psu. More than 3 drives plugged in was too much current for the hub, itgot hot & shut down, so I bought another hub & glued it to the otherside of the drive cage. Problem solved. Printed the shelves to hold the drives and a BPI-m5. I configured the 5 SSD's into a software raid6 of 11TB. A friend that is really good at shell scripts knocked up an rsync based thing that could go thru the user trees of all my machines, currently itself, this box, and all my cnc stuff in the garage, several 3d printers, a total of 8 machines, soon to be 9, making a backup of /home/gene or /home/cnc since cnc is first user on the pi running my big but old Sheldon lathe. This draws around 15 watts idling, up to 19 watts running, and does it all in 28 or 29 minutes. So that is something else these pi clones can do, and do very well. I've run it 7 or 8 times in two weeks, adding another 3d printer to the $systems list each time. Its used 4% of the 11TB so far. Using rsync the only expansion in storage is the backup copy of any file thats been changed since the last run. I love doing odd stuff like this just to see if it can be done. And it has succeeded beyond my expectations. That rpi4b running that lathe was another such "project". Started with an rpi3b which wasn't quite fast enough but its been running for over a decade, almost a decade since I switched it to a rpi4b. There, when the lathe is off, linuxcnc controls that too, the pi and monitor show as a 23 watt load. Whats not to like?

I had an error when installing armbian on my M96H androidtv S950L3. Anyone any idea to resolve this?

The holes are visible in the 4. Image of fedes_gl's first message. The holes are right to the display. The pins are connected to the AIP1628. This images are from the first layout version. I now have a second Board with V1.4 marked in the Layout. The holes are no longer present in this version. It has also has a different Wi-Fi chip, therefore Wi-Fi doesn't work in my current Armbian release with this v 1.4. box.