All Activity
- Past hour
-
data corruption can always happen when there is a power outage. Could be by chance that one device suffered while the other didn't. Best way to prevent is as guessed a small PSU which ideally tells the device 'there is an outtage, please shut down before I run out of battery". Having OS or data or microSD, eMMC or NVMe does not make a difference since the OS decides when and how often data is written. NVMe are even more fragile since they often come with an internal cache themselves that is emptied onto the actual flash asynchronously. Disabling write caches may lower chances for data corruption but for once can decrease performance a lot and for the other significantly decreases the lifetime of microSD cards.
-
I'm not sure what you're asking. I'm requesting information because I am seeing information stating that there is a working linux kernel that exists, but I don't know how to bridge that into a form where that kernel could be built or compiled into an image. Can what is on that github page be input into the build process? I've looked at what it takes to build Armbian from source and I understand the instructions when the board being built fits the categories in the instructions, but I'm not sure if that github kernel is useable or can be applied in that buidl process.
- Yesterday
-
Hi everyone, Two Questions: 1) I have two Orange Pi 3 LTS boards at home. I installed AdGuard Home on one, serving as DHCP (I'll call it OP1), and on the other, I left a Docker with other apps (qbittorrent, omv6, samba, etc. - I'll call it OP2). Both are installed via SD card. But if there's a power outage, OP1 works normally again after, without any problems. But OP2, on the other hand, has experienced data corruption several times. Does anyone know why OP1 works fine and OP2 runs the risk of having to reinstall the system in such a case? 2) If I used a board with EMMC memory and unified all the systems on it, would the chances of this decrease, or is it unrelated? I see other people with same problem. Only using a UPS to prevent the OP2 problem? Thanks
-
@Randlin have you tried adding secure boot to @sicxnull build. If that doesn’t work you’ll need to play with the dram code. I don’t have time or a 1.5g board. https://github.com/sicXnull/armbian-build/tree/X96Q-TVBOX-LPDDR3
-
For the Orange Pi Zero v1, it might be recommended to upgrade U-Boot to version v2025.4. I remember having similar problems with the Orange Pi Zero 3, and after the U-Boot update, the reboot works correctly and doesn't shut down the computer.
- 9 replies
-
- Orange Pi Zero
- Orange Pi Zero 2
-
(and 1 more)
Tagged with:
-
I see that the reported problem was raised in another topic:
-
There is certainly nothing planned. In general most of the open source community has moved away from working on amlogic based devices as the support from amlogic if lacking (and given the arm cpu space where all arm cpu vendors don't really support main line linux very much, amlogic is significantly even less supportive). So these days around armbian in particular most developers choose to invest there volunteer time in Rockchip cpus (and more recently some in allwinner cpus). But this is open source and community driven. So anyone is welcome to pitch in and do the heavy lifting to support it if they want. That is how most boards get support, is that someone with an interest volunteers to do the work.
-
Okay that detects 1.5gb at spl, but then detects 2gb at uboot, just like the first patch I tried. Maybe something to do with me currently using the U-Boot DTB from X96-q, a 2gb device? I did try a different config for a different tv box as well (transpeed), but that had the same result. U-Boot SPL 2025.01-armbian-2025.01-S6d41-P37d4-H8869-V004f-Bb703-R448a-dirty (Aug 13 2025 - 17:14:56 +0000) DRAM base address is defined as 0x40000000 DRAM has 15 b/raw, 10 b/col, 4 B/width, 2 #rank and 8 #bank DRAM top address must be less than 0x80000000 DRAM top address must be less than 0x60000000 DRAM: 1536 MiB Trying to boot from MMC1 NOTICE: BL31: v2.10.14(debug):armbian NOTICE: BL31: Built : 15:34:29, Aug 13 2025 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b2520, model: hechuang,x96-q LPDDR3 INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: PMIC: Probing AXP305 on RSB ERROR: RSB: set run-time address: 0x10003 INFO: Could not init RSB: -65539 INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied INFO: PSCI: Suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 INFO: Changed devicetree. ns16550_serial serial@5000000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2025.01-armbian-2025.01-S6d41-P37d4-H8869-V004f-Bb703-R448a-dirty (Aug 13 2025 - 17:14:56 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: hechuang,x96-q LPDDR3 DRAM: 2 GiB (effective 0 Bytes)
-
Thanks for putting all this together — it’s a fantastic resource for anyone still trying to get the most out of these cheap RK3318 boxes. Fully agree on avoiding them for anything critical, but for tinkering and learning, this thread is gold.
-
Yep, I’ve been testing the 1.5GB version with Armbian. Images are still rough—some issues with AdGuard Home not starting properly after reboot, and a few quirks with networking. Promising board though, especially for the price.
-
Adguard Home not running after reboot.
subhan replied to Nathan Warawa's topic in Software, Applications, Userspace
Check if AdGuard is binding to the correct IP after reboot. You can verify this in the AdGuardHome.yaml file—make sure bind_host is set to 0.0.0.0 or your static IP. Also confirm the service is listening with sudo netstat -tulnp | grep 3000 and check logs with journalctl -u AdGuardHome. -
Another phenomenon is also observed on the Orange Pi Zero v1. Issuing the reboot command causes the computer to not restart, requiring the power supply to be turned off and on again.
-
@RandlinTry removing 110,111,113 patches in my uboot. Then add https://github.com/armbian/build/blob/main/patch/u-boot/v2025-sunxi/0009-sunxi-h616-dram-support-1.5GB-RAM-size.patch
-
So I copied the patches from Minimyth2 to your Armbian and it built, however it is now detecting 2gb ram lol.... Will try to see if I can find a way to hardcode 1.5gb
-
The Mesa 25.2 release introduces support for AFBC compressed YUV textures in the Panfrost driver for ARM Mali GPUs, enabling more efficient memory bandwidth and power usage in video playback and real-time texture processing. View the full article
-
“This DRAM setup is currently not supported. resetting “ You need to extract your boot0 and use sunxi-fw to read your dram settings. sunxi-fw info -v boot0.bin Go back one page.
-
https://github.com/NickAlilovic/build/releases/ [01.296]secure enable bit: 1 I see this in your android log so I believe you have to enable secure boot. If the images don’t boot. These are the steps to enable secure boot for tanix_tx6s_axp313. (Link below) [01.303]PMU: AXP1530 You have a axp313a so transpeed, x98h and tanix might work for you. [359]DRAM Type =3 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4) Transpeed, x98h and tanix use ddr3 If emmc or wifi do not work. You can use your android dts to find the gpio numbers. You might also need to take a picture of your wifi chip.
-
@Nick A I wonder why android loading stops when the sd card with linux is in the tv box. And when loading the sd card, as I wrote earlier, I see the message "U-Boot SPL 2024.01-armbian-2024.01-S866c-P6135-Ha9af-V6d37-Bda0a-R448a (Sep 19 2024 - 19:48:11 -0400) This DRAM setup is currently not supported. resetting ... ". I am not a super pro user and I don’t know some things. I was looking for the usual answer myself, but after 7 days of searching and popping up I decided to write here. Maybe this will help me in my situation. All the answers I found are for TV boxes v1.3, v5.1 v3.0. No one with v4.0 has seen how I felt about the version and how the boxes and components can differ greatly.
-
Thank you, will try asap. How can I do? Do you think is useful also 01_dtbdump_,sun50iw9.dtb that I have extracted through adb shell?
-
@mdidis try the transpeed or x98h image. You might need to enable secure boot.
-
@jdie both of those are android logs
-
I am using Orange Pi Zero2 / Zero2W / Zero3 boards with the Allwinner H618 SoC and I am encountering an issue with I2C3 (mv64xxx_i2c). Board Details: Board: Orange Pi Zero2 / Zero2W / Zero3 SoC: Allwinner H616 Kernel: 6.12.35-current-sunxi64 (Armbian) Overlay: i2c3-ph (/boot/armbianEnv.txt: overlays=i2c3-ph) Pinout: PH4 = SDA, PH5 = SCL Problem: After boot, /dev/i2c-2 is created, but the bus is locked dmesg shows: [ 0.846937] i2c_dev: i2c /dev entries driver [ 1.479459] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver [ 1.484185] /soc/i2c@7081400/pmic@36: Fixed dependency cycle(s) with /soc/pinctrl@300b000 [ 1.501006] mv64xxx_i2c 5002c00.i2c: Error applying setting, reverse things back [ 1.501095] axp20x-i2c 1-0036: AXP20x variant AXP313a found [ 1.502779] axp20x-i2c 1-0036: AXP20X driver loaded [ 53.381005] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 55.429017] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 Attempting rmmod: sudo rmmod mv64xxx_i2c rmmod: ERROR: Module mv64xxx_i2c is not currently loaded Bus /dev/i2c-2 remains locked System Information: Full system info collected via https://paste.armbian.com/vezeminihu What I have tried: Created a new overlay i2c3-ph for PH4/PH5 Configured /boot/armbianEnv.txt to load the overlay Rebooted multiple times, but the bus remains locked Verified pull-up resistors (PH4/PH5 connected to 3.3V) Questions: Has anyone encountered mv64xxx_i2c bus lock on H618? How should DTS / pinctrl / PMIC be adjusted to get the bus working? Is there a working example overlay for I2C3 on Orange Pi Zero3 / H618?
-
Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.
-
sudo rmmod mv64xxx_i2c rmmod: ERROR: Module mv64xxx_i2c is not currently loaded root@WiPLUX-M040230BBQIGU:~# dmesg | grep -i i2c [ 0.846937] i2c_dev: i2c /dev entries driver [ 1.479459] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver [ 1.484185] /soc/i2c@7081400/pmic@36: Fixed dependency cycle(s) with /soc/pinctrl@300b000 [ 1.501006] mv64xxx_i2c 5002c00.i2c: Error applying setting, reverse things back [ 1.501095] axp20x-i2c 1-0036: AXP20x variant AXP313a found [ 1.502779] axp20x-i2c 1-0036: AXP20X driver loaded [ 53.381005] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 55.429017] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 154.821986] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0
-
Is an Armbian image for the C5 planned for the future?