All Activity

OK, as I thought, not enough 'headroom' rock5b:/local/ssdata/nocow # btrfs inspect-internal list-chunks 2 btrfs inspect-internal list-chunks 2 Devid PNumber Type/profile PStart Length PEnd LNumber LStart Usage% ----- ------- ----------------- -------- --------- -------- ------- -------- ------ 1 1 System/single 1.00MiB 4.00MiB 5.00MiB 4 2.30GiB 0.39 1 2 Metadata/single 5.00MiB 8.00MiB 13.00MiB 1 5.00MiB 35.74 1 3 Data/single 13.00MiB 8.00MiB 21.00MiB 2 13.00MiB 100.00 1 4 Data/single 21.00MiB 1.00GiB 1.02GiB 3 21.00MiB 53.20 1 5 Metadata/single 1.02GiB 208.00MiB 1.22GiB 5 2.31GiB 23.51 1 6 Data/single 1.22GiB 512.00MiB 1.72GiB 6 2.51GiB 84.35 1 7 Data/single 1.72GiB 512.00MiB 2.22GiB 7 3.01GiB 86.48 1 8 Metadata/single 2.22GiB 256.00MiB 2.47GiB 8 3.51GiB 33.67 1 9 Metadata/single 2.47GiB 256.00MiB 2.72GiB 9 3.76GiB 14.43 1 10 Data/single 2.72GiB 1.00GiB 3.72GiB 10 4.01GiB 83.88 1 11 Data/single 3.72GiB 1.00GiB 4.72GiB 11 5.01GiB 97.23 1 12 Data/single 4.72GiB 1.00GiB 5.72GiB 12 6.01GiB 55.02 1 13 Data/single 5.72GiB 1.00GiB 6.72GiB 13 7.01GiB 85.21 1 14 Data/single 6.72GiB 1.00GiB 7.72GiB 14 8.01GiB 58.04 1 15 Data/single 7.72GiB 1.00GiB 8.72GiB 15 9.01GiB 82.03 1 16 Data/single 8.72GiB 1.00GiB 9.72GiB 16 10.01GiB 28.15 1 17 Metadata/single 9.72GiB 256.00MiB 9.97GiB 17 11.01GiB 10.30 1 18 Data/single 9.97GiB 1.00GiB 10.97GiB 18 11.26GiB 99.83 1 19 Metadata/single 10.97GiB 256.00MiB 11.22GiB 19 12.26GiB 0.58 1 20 Metadata/single 11.22GiB 256.00MiB 11.47GiB 20 12.51GiB 5.22 1 21 Metadata/single 11.47GiB 256.00MiB 11.72GiB 21 12.76GiB 0.49 1 22 Metadata/single 11.72GiB 256.00MiB 11.97GiB 22 13.01GiB 0.27 1 23 Metadata/single 11.97GiB 27.00MiB 12.00GiB 23 13.26GiB 0.06 Then doing various balance actions, then again replace action, see result below: [334356.515225] [ T207531] BTRFS info (device loop0p2): balance: start -mlimit=3 -slimit=3 [334356.516261] [ T207531] BTRFS info (device loop0p2): relocating block group 14236516352 flags metadata [334356.608520] [ T207531] BTRFS info (device loop0p2): found 1 extents, stage: move data extents [334356.655369] [ T207531] BTRFS info (device loop0p2): relocating block group 13968080896 flags metadata [334356.882397] [ T207531] BTRFS info (device loop0p2): found 44 extents, stage: move data extents [334356.974962] [ T207531] BTRFS info (device loop0p2): relocating block group 13699645440 flags metadata [334357.145812] [ T207531] BTRFS info (device loop0p2): found 77 extents, stage: move data extents [334357.223337] [ T207531] BTRFS info (device loop0p2): balance: ended with status: 0 [334402.346978] [ T207580] BTRFS info (device loop0p2): balance: start -mlimit=6 -slimit=6 [334402.347912] [ T207580] BTRFS info (device loop0p2): relocating block group 13431209984 flags metadata [334403.120645] [ T207580] BTRFS info (device loop0p2): found 841 extents, stage: move data extents [334403.372968] [ T207580] BTRFS info (device loop0p2): relocating block group 13162774528 flags metadata [334403.613848] [ T207580] BTRFS info (device loop0p2): found 94 extents, stage: move data extents [334403.743610] [ T207580] BTRFS info (device loop0p2): relocating block group 11820597248 flags metadata [334404.526435] [ T207580] BTRFS info (device loop0p2): found 1666 extents, stage: move data extents [334404.798554] [ T207580] BTRFS info (device loop0p2): relocating block group 4035969024 flags metadata [334406.059117] [ T207580] BTRFS info (device loop0p2): found 2363 extents, stage: move data extents [334406.374011] [ T207580] BTRFS info (device loop0p2): relocating block group 3767533568 flags metadata [334407.879438] [ T207580] BTRFS info (device loop0p2): found 5433 extents, stage: move data extents [334408.284506] [ T207580] BTRFS info (device loop0p2): relocating block group 2475687936 flags metadata [334413.884083] [ T207580] BTRFS info (device loop0p2): found 9463 extents, stage: move data extents [334414.690177] [ T207580] BTRFS info (device loop0p2): balance: ended with status: 0 [334530.694011] [ T207693] BTRFS info (device loop0p2): balance: start -dlimit=2 [334530.694839] [ T207693] BTRFS info (device loop0p2): relocating block group 12089032704 flags data [334534.205097] [ T207693] BTRFS info (device loop0p2): found 1897 extents, stage: move data extents [334534.491352] [ T207693] BTRFS info (device loop0p2): found 1897 extents, stage: update data pointers [334534.625126] [ T207693] BTRFS info (device loop0p2): relocating block group 10746855424 flags data [334536.605759] [ T207693] BTRFS info (device loop0p2): found 16316 extents, stage: move data extents [334537.056028] [ T207693] BTRFS info (device loop0p2): found 16316 extents, stage: update data pointers [334537.361629] [ T207693] BTRFS info (device loop0p2): balance: ended with status: 0 [334614.951029] [ T207803] BTRFS info (device loop0p2): dev_replace from /dev/loop0p2 (devid 1) to /dev/loop1p2 started [334654.572435] [ T207803] BTRFS info (device loop0p2): dev_replace from /dev/loop0p2 (devid 1) to /dev/loop1p2 finished So vendor I would need to do the same with vendor kernel on same images, I made exact copies, so can be done, however starting with vendor kernel requires system reboot (and other bootloader), so not sure when I can do this.

I could not reproduce it on a vanilla OpenSuse Tumbleweed installation (EDK2-UEFI in SPI-flash on ROCK5B) when using a rather newly created filesystem that is only used for 15 minutes or so. However, I can reproduce if the image is my virtual machine armbian64 machine/test/template and between 1 to 2 years old and has had many operations, like resize shrink extend etc. So it seems some complex out-of-space issue for a certain part: rock5b:/local/ssdata/nocow # uname -a ; grep VERSION_ID /etc/os-release Linux rock5b 6.15.1-1-default #1 SMP PREEMPT_DYNAMIC Thu Jun 5 14:29:05 UTC 2025 (75961ad) aarch64 aarch64 aarch64 GNU/Linux VERSION_ID="20250610" - so depends on image as rather fresh image newly constructed serv.img no problem - -28 is no space error AFAIK, check internal of image rock5b:/local/ssdata/nocow # df | grep loop0p2 /dev/loop0p2 12582912 7904480 2852032 74% /local/ssdata/nocow/2 rock5b:/local/ssdata/nocow # btrfs fi df 2 Data, single: total=10.01GiB, used=7.29GiB System, single: total=4.00MiB, used=16.00KiB Metadata, single: total=1.99GiB, used=218.05MiB GlobalReserve, single: total=26.95MiB, used=0.00B rock5b:/local/ssdata/nocow # btrfs de us 2 /dev/loop0p2, ID: 1 Device size: 12.00GiB Device slack: 0.00B Data,single: 10.01GiB Metadata,single: 1.99GiB System,single: 4.00MiB Unallocated: 1.00MiB rock5b:/local/ssdata/nocow # btrfs fi us 2 Overall: Device size: 12.00GiB Device allocated: 12.00GiB Device unallocated: 1.00MiB Device missing: 0.00B Device slack: 0.00B Used: 7.51GiB Free (estimated): 2.72GiB (min: 2.72GiB) Free (statfs, df): 2.72GiB Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 26.95MiB (used: 0.00B) Multiple profiles: no Data,single: Size:10.01GiB, Used:7.29GiB (72.82%) /dev/loop0p2 10.01GiB Metadata,single: Size:1.99GiB, Used:229.44MiB (11.27%) /dev/loop0p2 1.99GiB System,single: Size:4.00MiB, Used:16.00KiB (0.39%) /dev/loop0p2 4.00MiB Unallocated: /dev/loop0p2 1.00MiB From 10+ years Btrfs usage and a quick look at those numbers, I think the problem occurs because it is not possible to easily/directly create a new chunk. The filesystem is still mounted. If I unmount, a new mount fails because of undefined state (replace ongoing but no mounted filesystem and target device has temp ID 0 and cannot be found ?). So will see if balancing first with the proper options gets it done.

sorry for the typo, it is Kernel 6.12.30 that still doesn't support usb

I think now for the 3rd time this happens. OS is Armbian Bookworm with vendor ,current, edge kernels installed. it turns out that with vendor kenel there is no issue. But fails for mainline based rockchip64 kernels, at least edge. I am not sure about current (6.6 or 6.12) as I am not really using those. I discovered first time with 6.13.0-rc* kernel, I assumed something else might have been wrong, so more or les ignored and rebooted with vendor kernel. That happened both with nanopi-r6c and rock-3a. I also already rebooted the rock-3a on a later occasion just t make sure problem would not occur. Yesterday was on nanopi-r6c with kernel 6.15.1-edge-rockchip64. I booted with this kernel but Opensuse Tumbleweed userspace (VERSION_ID="20250610"). Following command run-as-root should move Armbian Bookworm rootfs from eMMC to NVMe: btrfs replace start /dev/mmcblk1p2 /dev/nvme0n1p2 /local/armbid Then in dmesg: Jun 19 18:44:38 ranc kernel: BTRFS info (device mmcblk1p2): dev_replace from /dev/mmcblk1p2 (devid 1) to /dev/nvme0n1p2 started Jun 19 18:45:49 ranc kernel: BTRFS warning (device mmcblk1p2): failed setting block group ro: -28 Jun 19 18:45:49 ranc kernel: BTRFS error (device mmcblk1p2): btrfs_scrub_dev(/dev/mmcblk1p2, 1, /dev/nvme0n1p2) failed -28 After 5 minutes or so I discovered that the filesystem was corrupted, would not open: open_ctree failed: -5 As I do (very) frequent backups (differential send|receive to NAS) recreate and play back the latest single subvolume snapshot is easy, but it would become quite a drama if large multi-TB with hundreds of snapshots/subvolumes. As the OS userspace was rolling release Tumbleweed, the btrfs-progs is very new, not the 6.2 from Bookworm. So it seems something mainline kernel rockchip64. I will try to further pinpoint. The NanoPi-R6C is a bit DUT ATM, but I could test as well with various other combinations, ROCK3A or ROCK5B, although those have a dedicated task/use-case in my home. The 5B has 16G RAM, so easy to run VMs and loopdevs etc. I think this is not HW related, but whos knows, maybe some detailed RK35xx optimization or so.

Sorry for late reply Currently i only use this display to show content which already in the board The touch is not so reliable and it seem with the same config it still not working the same for each flash new image, i still need to change the touch matrix value. But for now i think i can accept it Actually I now wonder that maybe color is reversed because of speed of SPI. Because when i set in init command 0x1000036 0x08 or 0x48 or 0x28 it already have BGR bit 3 (as i share the image in document above. ) is 1. Also can i ask you about How to build armbian image for this board Orange pi zero 2w, i want to improve security for this project, so i want to have configure more about init boot, kernel, ... I heard someone use buildroot, someone use https://github.com/orangepi-xunlong/orangepi-build in here for H616, someone use OS Manjiro..., Have you ever try one, which do you suggest most ?

@KrzyPacu it seems there is an issue with your kernel source code (or minimal headers). Ensure to install kernel headers for your distribution/version first If it still doesn't point to your headers/source path, you can pass it as a variable when executing make. Something like: sudo make module-install KDIR=/path/to/your/headers/build

I managed to build "meson-sm1-x96-air-gbit.dtb" using the method described by @Jean-Francois Lessard but I haven't added anything to the "extlinux.conf" file yet. Then I issued the command "$ make module" and it seems to me that the compilation went correctly. Then I did "$ sudo make module-install" and here are the errors: $ sudo make module-install make -C /lib/modules/6.12.33-current-meson64/build M= modules_install INSTALL_MOD_PATH=/ make[1]: Enter the directory '/usr/src/linux-headers-6.12.33-current-meson64' SYMLINK //lib/modules/6.12.33/build make[3]: *** No rules to make an object 'modules.order', required by '//lib/modules/6.12.33/modules.order'. Stop. make[2]: *** [/usr/src/linux-headers-6.12.33-current-meson64/Makefile:1853: modules_install] Error 2 make[1]: *** [Makefile:224: __sub-make] Error 2 make[1]: Leaving the directory '/usr/src/linux-headers-6.12.33-current-meson64' make: *** [Makefile:35: module-install] Error 2

It is Allwinner H618, Quad-core ARM Cortex™-A53 processor. Yes it is external USB network card, which I used just to be able to send logs made via armbianmonitor to the internet. The state You see in the logs is just latest stage of many different attempts: with custom overlays and/or fixes on the sun50i-h618-bananapi-m4-zero.dtb (decompile, fix, compile, boot). In addition have tried some patches using H616 files. I also found problem is due to, PHY isn't properly powered on, based on topic: https://github.com/armbian/build/pull/6617 but after plenty of tries didnt manage to make it work ;(

@KrzyPacu The Amlogic TV Box builds use extlinux.conf. So you should add your overlay info in that file (/boot/extlinux/extlinux.conf). I believe the syntax for extlinux is: OVERLAYS /dtb/amlogic/overlay/... (I'd recommend placing it just below the FDT line) (Note: I've never tried to load an overlay through extlinux, but have been intending to try it some day. Let us know how it goes)

Hello everyone, I'm currently working on a custom firmware project for the Allwinner V851S/V851SS SoC (e.g., dash cam or smart camera). I've reached the stage where I need to modify and re-sign the firmware images (TOC0/TOC1) for use with tools like PhoenixCard. Unfortunately, the tools found on GitHub (e.g., dragonsecboot, pack_tools, boot0, etc.) are often incomplete or fail to build due to missing references (e.g., rsa_sign_main, GetFullPath, etc.). 🔍 I'm looking for a complete and working version of the following tools: dragonsecboot pack boot0 sunxi_tools Full config files such as dragon_toc.cfg, sys_config.fex Working pack_tools with all required source files Full Tina SDK for V851S or V851SS 🎯 My goal is to properly sign and rebuild TOC0/TOC1 and PACKAGE images, and build a customized embedded Linux system. 📤 If anyone has the official SDK or a working toolchain, I’d really appreciate it if you could share it via Google Drive, Mega, Transfer.sh, or any other file host. Thank you in advance to anyone who can help 🙏

J

> sunxi-gmac 5030000.ethernet end0: No PHY found! The first question. What brand of chip is used in your case? The second question. Is this an external device? [ 341.101053] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 341.257994] usb 2-1: New USB device found, idVendor=0b95, idProduct=772b, bcdDevice= 0.01 [ 341.258024] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 341.258033] usb 2-1: Product: AX88772B [ 341.258039] usb 2-1: Manufacturer: ASIX Elec. Corp. [ 341.258045] usb 2-1: SerialNumber: E5A1DD [ 341.902647] asix 2-1:1.0 (unnamed net_device) (uninitialized): PHY [usb-002:002:10] driver [Asix Electronics AX88772C] (irq=POLL) [ 341.905987] Asix Electronics AX88772C usb-002:002:10: attached PHY driver (mii_bus:phy_addr=usb-002:002:10, irq=POLL) In order for the ethernet-phy to work, it is necessary to turn on the PWM on the internal pin of the processor. As example see: arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts and arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts#L521-L539

Building on our Open Source strengths in AI and data-driven solutions, Collabora's ML team, led by Marcus Edel, Vineet Suryan, & Aaron Boxer, has taken first place in Track 3 of the ICME 2025 Grand Challenge on Video Super-Resolution for Video Conferencing. View the full article

@KrzyPacu Start by copying your original dtb into tm16xx-display folder: cd tm16xx-display cp meson-sm1-x96-air-gbit.dtb original.dtb # or alternatively run: make extract-dtb Then, assuming the corresponding device tree source overlay in the "devices" subfolder is "x96-max-1gbit.dtso", build the updated dtb: make x96-max-1gbit.dtb # <-- same name as the dtso file in devices subfolder but with dtb extension Finally, replace the original dtb of your boot path with the updated one (first keep a copy of your original dtb somewhere else, just in case) and reboot: cp release/x96-max-1gbit.dtb /boot/dtb/{YOUR_DTB_PATH}.dtb reboot

$ make meson-sm1-x96-air-gbit_mod.dtb ORIGINAL_DTB=meson-sm1-x96-air-gbit.dtb make: *** No rules for object execution 'meson-sm1-x96-air-gbit_mod.dtb'. Stop. https://github.com/jefflessard/tm16xx-display/blob/main/README.md#configure-the-device-tree I can't do option 1 because I don't have the "/boot/armbianEnv.txt" file . Where do I add the entry "user_overlays=tm16xx"

Hi @KrzyPacu I can only provide basic instructions without any support regarding loading overlays. It's not supported on every device (and I personally don't own a device which supports this). You can always search for other posts on device tree overlay for your device if you absolutely want to use overlays. Though, you can easily embed the device tree overlay into your dtb instead. This is what I do personally. You can check instructions of Option 2: Create an updated dtb at : https://github.com/jefflessard/tm16xx-display/blob/main/README.md#configure-the-device-tree

I am trying to run this driver on Vontar X3 Armbian 25.8.0-trunk.163 bookworm. I stopped at the point "Edit /boot/armbianEnv.txt to load the overlay" because I do not have the armbianEnv.txt file. What should I do next to add the generated file "hk1-x3.dtbo" to my device tree file "meson-sm1-x96-air-gbit.dtb"?

armbianmonitor logs: https://paste.armbian.com/rolisaboru I’m running Armbian 25.2 on a Banana Pi BPI-M4-Zero (Allwinner sun50i-h618). EMAC1 (ethernet@5030000) with its internal PHY never comes up: sunxi-gmac 5030000.ethernet end0: renamed from eth0 … No PHY found! … phy init again… No PHY found! … phy init failed So far I have tried: 1. Directly patching full.dts Enabled /soc/ethernet@5030000 (status = “okay”) Added phy-mode = "rmii", pinctrl-0 = <&rmii_pins>, phy-handle, phy-supply etc. Defined a simple ethernet-phy@0 under MDIO. Recompiled to sun50i-h618-bananapi-m4-zero.dtb and rebooted. 2. User overlay (.dts → .dtbo) Created fragments to: Turn on /soc/ethernet@5030000/mdio Inject an ethernet-phy@0 node Enable EMAC1, assign RMII pins, MDIO and PHY handle Compiled with dtc -@ and loaded via user_overlays=bpi-m4z-eth in armbianEnv.txt. 3. Following Armbian build PR #6617 Tried the patch for H618’s internal AC300 PHY from https://github.com/armbian/build/pull/6617 No change: PHY still not detected, no power-up. 4. Troubleshooting notes Overlay apply errors: FDT_ERR_NOTFOUND dtc compile errors on duplicate or missing phandle references Verified pinctrl entries (rmii-pins) and alias names match base DTS I’ve collected a full hardware/software report via armbianmonitor—see the logs here: https://paste.armbian.com/rolisaboru What I’m looking for A known-good snippet of device-tree (base DTS or overlay) that brings up the internal EMAC1 PHY on sun50i-h618 Advice on any missing power-or-clock settings or MFD nodes required for the AC300 PHY Confirmation whether additional kernel/config patches are needed Thanks in advance for any pointers!

It sounds like you're in a tough spot with your x88 box, but there are definitely a few things you can try to unbrick it. Check Power Supply: As you mentioned, the power supply might be outputting 13V, which is not ideal. It's crucial to have a stable 5V supply for the device to boot properly. If you can, try using a different power adapter (5V, 2A) and see if that helps stabilize the boot process. Use a Correct Recovery Image: Make sure you're using the correct image for the box. It seems like you were trying to burn the image directly, but if the process was interrupted, it could leave your internal storage in an inconsistent state. Try downloading the official firmware for your box model from the manufacturer's site (if available) or from trusted forums where users with similar devices share their files. Try the USB Burning Tool: Some boxes like this one can be recovered using a tool like the USB Burning Tool (if it's based on Rockchip). You can try flashing the firmware through USB using the tool while the box is in recovery mode. Here’s a general approach: Download and install the USB Burning Tool. Put your box into MaskROM Mode (this usually involves shorting specific pins or pressing a button while plugging the box into your computer via USB). Connect your device to the PC and use the USB Burning Tool to flash the firmware. Serial Console Output: If you're comfortable with it, connecting a serial console to the box can give you a lot of insight into where things are failing. This could help identify whether it's a hardware or software issue. The serial output could give you error messages that could point to a specific issue (e.g., faulty bootloader or file system corruption). SD Card Recovery: If you can't get it to boot from the internal flash, continue using the SD card with a stable Armbian image. If the internal storage is corrupt, you might still be able to boot and recover your box through the SD card by reinstalling the firmware on the internal storage via the system running off the SD card. If you haven't already, you could also try reaching out to the manufacturer or seller for support, as they might be able to help you with the recovery process. But if that’s not an option, digging into the serial console is definitely your best bet. Good luck! Hopefully, you'll be able to get your device back up and running soon.

Good day, respected Balbes150. Please advise an Armbian build for the Roc-rk3588s-pc v1.1, with support for an M.2 NVMe SSD, intended to be used as a "smart home" server. The image will be installed on an SD card. The single-board computer is connected to the home router via Ethernet cable. HDMI is only used temporarily to connect to a TV for initial setup (further configuration will be done via SSH). The board will run Docker containers. Thank you so much in advance!

Hello! I try to flash my H96Max on RK3318 but i cannot load armbian. After success flash armbian to emmc i remove sd and nothing, nothing load and nothing in uart port, only red led light and thats all. Здравствуйте! Я пытаюсь прошить свой H96Max на RK3318, но не могу загрузить armbian. После успешной прошивки armbian на emmc я извлекаю SD-карту, и ничего, ничего не загружается и ничего не отображается в последовательном порту, только красный светодиод и всё. when i'm load from sd multitool i get this log from uart i'm try to find u-boot on my h96max emmc and nothing, first 100bytes empty. Where i can get u-boot? LoadLog.txt

Hello, Any update of this?

They will provide you new drivers only if you will pay them to do that for you. End users, including this project, can do nothing about - we have negative budget and can only do best-effort work to keep those drivers at least operational with recent kernels: https://github.com/armbian/build/tree/main/patch/misc while bulk of the patches goes directly to the Git of specific driver. What you are hoping exceeds ability of amateur maintainers, those few people that are actually looking into the code and fix bugs that are made by kernel API changes. HW vendor is usually long gone from there - their development capacity is also limited and they are focused into current products. FYI

A10 / A20 hdmi support was reported as broken and bug was recorded https://armbian.atlassian.net/browse/AR-2674 some time ago.

https://debug.armbian.de