All Activity
- Past hour
-
thanks. The image has been launched. I will try to test gpio and mipi camera.
- Today
-
Helios64 - Armbian Trixie with linux 6.18 (incl. opp-microvolt patch)
BipBip1981 replied to ebin-dev's topic in Rockchip
Hello, I use with 6.18.15 the two way below. - new way with armbian-config and choses the overlay stabilty file for helios64 - the old way with my old dtb file for 6.18.xx kernel that i downloaded in this forum and work good with all 6.18.xx kernel until 6.18.10 kernel (rk3399-kobol-helios64.dtb-6.18.18-opp.zip) Have a good day -
I already did the apt update & upgrade, it actually seems like the 6.18.35 did solve that issue - or at least, that's how I'd read the newer "armbianmonitor -u" as posted here: https://paste.armbian.com/orawuzawun PS: I didn't test again if it works now without the script for reasons of lack of access to the bananapi + local screen + local keyboard in case it still came up without end0 - bot the output of armbianmonitor at least doesnt show up that failure you pointed at.
-
Added https://github.com/armbian/build/pull/10213
-
does rockpro64 armbian cli come with non free software?
eselarm replied to renky's topic in Pine RockPro64
You should check with: grep non-free /etc/apt/sources.list.d/*.sources And remove the non-free components and also remove/purge all packages that belong to non-free. You probably need some 'man apt-get' to figure out how to select those. -
I see in your log: [ 15.439789] sun7i-dwmac 1c50000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 15.466497] sun7i-dwmac 1c50000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL) [ 15.677165] sun7i-dwmac 1c50000.ethernet end0: Failed to reset the dma [ 15.758481] sun7i-dwmac 1c50000.ethernet end0: stmmac_hw_setup: DMA engine initialization failed [ 15.772254] sun7i-dwmac 1c50000.ethernet end0: __stmmac_open: Hw setup failed If I look at my bpi: root@banlipi:~# dmesg | grep ethernet [ 3.767952] sun7i-dwmac 1c50000.ethernet: IRQ eth_wake_irq not found [ 3.774414] sun7i-dwmac 1c50000.ethernet: IRQ sfty not found [ 3.780287] sun7i-dwmac 1c50000.ethernet: PTP uses main clock [ 3.894850] sun7i-dwmac 1c50000.ethernet: Version ID not available [ 3.902941] sun7i-dwmac 1c50000.ethernet: DWMAC1000 [ 3.907950] sun7i-dwmac 1c50000.ethernet: No HW DMA feature register supported [ 3.915196] sun7i-dwmac 1c50000.ethernet: TX Checksum insertion supported [ 3.922008] sun7i-dwmac 1c50000.ethernet: Normal descriptors [ 3.927689] sun7i-dwmac 1c50000.ethernet: Ring mode enabled [ 5.766296] sun7i-dwmac 1c50000.ethernet end0: renamed from eth0 [ 19.418540] sun7i-dwmac 1c50000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 19.465510] sun7i-dwmac 1c50000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL) [ 19.476982] sun7i-dwmac 1c50000.ethernet end0: No Safety Features support found [ 19.484490] sun7i-dwmac 1c50000.ethernet end0: RX IPC Checksum Offload disabled [ 19.491897] sun7i-dwmac 1c50000.ethernet end0: No MAC Management Counters available [ 19.508289] sun7i-dwmac 1c50000.ethernet end0: PTP not supported by HW [ 19.514967] sun7i-dwmac 1c50000.ethernet end0: configuring for phy/rgmii-id link mode [ 23.717977] sun7i-dwmac 1c50000.ethernet end0: Link is Up - 1Gbps/Full - flow control rx/tx root@banlipi:~# uname -a Linux banlipi 6.18.35-current-sunxi #1 SMP Tue Jun 9 10:28:53 UTC 2026 armv7l GNU/Linux So no DMA related problem. The AI advise is nonsense IMO; There might some (longterm) hidden bug/issue in the sunxi kernel when running on bananapi as mine usually hangs after a few days with a kernel paging issue, root cause I don't now. BUT, now tha I am challenging this with 24/7 kernellogging via serial console, 'it does not wanna crash': root@banlipi:~# uptime 14:32:05 up 7 days, 18:13, 1 user, load average: 0.07, 0.14, 0.12 I must say only thing it does is read out the AXP PMU values every 10s and pushes that into influxDb. Maybe I should hook up a SATA SSD or HDD and see if I can repeat. Maybe doe upgrade, so you get newer kernel (6.18.35): sudo apt update && sudo apt full-upgrade -y
-
Armbian_community_26.8.0-trunk.359_Rockpro64_trixie_current_6.18.38_minimal.img.xz If the image installs non free software on the computer can you tell which packages they are and how to remove them from the computer, such that no piece of non free software stays on the computer? In this post free software should be understood as coined by the fsf.org. Thank you.
-
Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.
-
I Installed this image and it works fine. Sadly the build in WiFi module is not working. I now use an external wifi dongle. What could be the problem here? Ernst-Jan
-
Hi, FYI, there might be an issue with old, slow hardware. Yesterday I installed the minimal Ubuntu 26.04 current 6.18.24 downloaded from https://armbian.com/boards/bananapi on my old Banana Pi on an similar old 8GB SD by sandisk. It runs normaly, but cannot set up the end0 during booting. Doing an "ip link set end0 up" manually on cli afterwards immediately activated end0, so my solution was using an script to do this command after booting. The AI aiding me thinks it's just the slow hardware causing a timeout when it should set up the interface during booting. Just wanted to let you know.
-
Using the KDE image on eMMC storage, this is how far the boot process get. The results or from the serial port. [217]HELLO! BOOT0 is starting! [220]BOOT0 commit : 595900dccf [224]periph0 has been enabled [227]set pll end [229]PL gpio voltage : 3.3V [233][pmu]: bus read error [236]PMU: AXP2202 [241]PMU: AXP1530 [245]power mode:33, sys_vol:920 [249]vaild para:1 select dram para0 [253]dram_para[0]:0x4b0 [255]dram_para[1]:0x8 [258]dram_para[2]:0x7070707 [261]dram_para[3]:0xd0d0d0d [264]dram_para[4]:0xe0e [266]dram_para[5]:0x84848484 [269]dram_para[6]:0x310a [272]dram_para[7]:0x8000000 [275]dram_para[8]:0x0 [277]dram_para[9]:0x34 [280]dram_para[10]:0x1b [282]dram_para[11]:0x33 [285]dram_para[12]:0x3 [287]dram_para[13]:0x0 [290]dram_para[14]:0x0 [292]dram_para[15]:0x4 [295]dram_para[16]:0x72 [297]dram_para[17]:0x0 [300]dram_para[18]:0x8 [302]dram_para[19]:0x0 [305]dram_para[20]:0x0 [307]dram_para[21]:0x26 [310]dram_para[22]:0x80808080 [313]dram_para[23]:0x6060606 [316]dram_para[24]:0x0 [318]dram_para[25]:0x74000000 [322]dram_para[26]:0x38000000 [325]dram_para[27]:0x802f3333 [328]dram_para[28]:0xc7c5c4c2 [331]dram_para[29]:0x3533302f [335]dram_para[30]:0xc60 [337]dram_para[31]:0x48484848 [340]board init ok [363]enable_jtag [365]card no is 0 [367]sdcard 0 line count 4 [370][mmc]: mmc driver ver 2023-03-24 16:23 [380][mmc]: Wrong media type 0x0 [383][mmc]: ***Try SD card 0*** [405][mmc]: HSSDR52/SDR25 4 bit [408][mmc]: 50000000 Hz [411][mmc]: 30436 MB [413][mmc]: ***SD/MMC 0 init OK!!!*** [425]boot param - magic error [428]DRAM BOOT DRIVE INFO: V0.67 [432]DRAM_VCC set to 1160 mv [559]DRAM retraining ten [577][AUTO DEBUG]32bit,2 ranks training success! [606]Soft Training Version: T2.0 [7410][SOFT TRAINING] CLK=1200M Stable memtest pass [7415]DRAM CLK =1200 MHZ [7418]DRAM Type =8 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4) [7428]DRAM SIZE =4096 MBytes, para1 = 310a, para2 = 10001000, tpr13 = 6461 [7459]DRAM simple test OK. [7462]dram size =4096 [7469]nsi init 2023-2-23 [7605]Loading boot-pkg Succeed(index=0). [7609]Entry_name = u-boot [7619]Entry_name = monitor [7623]Entry_name = scp [7626]Entry_name = dtb [7631]mmc not para [7632]Jump to second Boot. NOTICE: BL31: v2.5(debug):20a8ac62a NOTICE: BL31: Built : 17:17:28, Jan 22 2024 NOTICE: BL31: No DTB found. nsi init ok 2022-11-08 ERROR: Error initializing runtime service opteed_fast
- Yesterday
-
-
@AurealNix download the KDE v0.2 again and I was able to write it to SD card . No issues. I am impressed, KDE loads just fine. Took a bit to load the first time. Wifi works just fine, loaded Chromium and launched Youtube. Playback is good, at the moment full screen drops frames. Audio through HDMI just worked, no issue. I also loaded the KDE image on eMMC, it did not boot. I will check what is going on use serial and report back if I see anything.
-
Of course. Kernel upgrade is handled via standard apt get update and upgrade. If you need to change to specific kernel, use https://docs.armbian.com/User-Guide_Armbian-Config/System/#alternative-kernels Make sure to update all packages before going that route, IIRC this problem is related to u-boot. Which is updated after all packages are up2date with armbian-install utility,
-
Hardware video acceleration with recent armbian/mainline kernel (Kodi)
robertoj replied to XXXBold's topic in Orange Pi 5
If you are using the friendlyelec image, can you really say "mpv is vanilla from Debian"? I am really asking, because I haven't used friendlyelec in a long time, and I don't remember if they have their own DEB repository. Can you identify the ffmpeg version and compilation options? Same with mpv. Run $ ffmpeg with no options, and it will print out the version and the libraries that were activated. $ apt list ffmpeg $ apt list mpv $ mpv --version $ cat /etc/issue $ uname -a I do remember that friendlyelec has some extra video abilities, because they maintain their own patches with bleeding edge code, while the official ffmpeg and mpv maintainers are still checking whether to accept the pull requests. Is it even possible to run "armbianmonitor -u" in friendlyelec? Do you see "v4l2-request" or "va-api" (or "vaapi") anywhere in the mpv log? is your gnome desktop running under X11 or Wayland? (last time I used friendlyelec with Kodi, the graphic server was gbm, and there was no desktop, only Kodi). If you run $ mpv --vo=gpu -v my.mp4 , mpv will print a more verbose log, with more details of how its running. -
@Nick_Sl @bickns — the headless build is up (146 MB, pure Debian 13, mainline 6.18.38, SSH from first boot): https://github.com/ut-slayer/orangepi-4a-mainline/releases/tag/v0.2 If either of you gives it a spin, I'd love a short report — what works, what doesn't. No rush and no obligation; even "booted, nothing broke" is useful. @Nick_Sl — you offered to test, so I'm taking you up on it 🙂. Most useful gaps right now: NVMe / M.2 SSD, suspend, and the GPIO header (eMMC and the 4 GB variant were just confirmed by another tester). @bickns — if the board ever leaves the drawer: the analog codec driver works, but mic capture is the one bit I couldn't bench-test (no onboard mic here). With your outdoor-audio project, you'd be the only one who could close that gap. Zero pressure either way. And if you don't mind, I'll add you to the thanks in the repo — testers get named there (JamesCL is already in for confirming the eMMC and the 4 GB variant). Also, early days and no promises: the VPU (hardware video decode) is something I've now started digging into. Thanks both.
-
That sounds good. I'm not using the jack for mic or output but should be able to check the DSP when things are more tied down with this outdoor-audio project. Will let you know and thanks again on a great job with this board!!
-
Software complexity is extreme ... And only x86 I would assume, so there is very little of interests for us. It is enough that packages are assembled at different time, so they will have different (bugs &) fixes. Either Ubuntu will get this bug or xtradebs will be fixed. Soon both wil be fixed or both broken .... unless bug is down to the OS level. Where snap will win with its, presumbly, stabilized OS container.
-
Hardware video acceleration with recent armbian/mainline kernel (Kodi)
Igor replied to XXXBold's topic in Orange Pi 5
On prebuild images we test video acceeleration within Chromium and it works. Both kernels, Ubuntu Noble / Resolute Gnome, same good or bad on all boards. Others userspace combo might not work and other/all video players we don't even try to cover. Our job is done, when at least one method works OOB. It was integrated. This is not needed anymore. For overlay, I don't know. I think its still needed and it that case, its certanly present. On kernel, where this is needed. -
Hardware video acceleration with recent armbian/mainline kernel (Kodi)
MMGen replied to XXXBold's topic in Orange Pi 5
With the official friendlyelec image for Nano Pi M6 (trixie, gnome, 6.1 kernel), I'm getting hardware acceleration with the plain vanilla mpv from Debian: mpv --vo=gpu my.mp4 mpp[2968]: mpp_platform: client 18 driver is not ready! ● Video --vid=1 (h264 1080x1920 59.9998 fps) [default] ● Audio --aid=1 (aac 2ch 44100 Hz 128 kbps) [default] arm_release_ver: g24p0-00eac0, rk_so_ver: 10-616430-r0 mpp[2968]: mpp_info: mpp version: 958803d7 author: Herman Chen 2026-02-26 fix[h265d_rkv]: Fix rkv ref and poc setup overflow Using hardware decoding (rkmpp). AO: [pipewire] 44100Hz stereo 2ch floatp VO: [gpu] 1080x1920 drm_prime[nv12] Everything works wonderfully, and CPU usage is about 25%, compared to 500% for Armbian. Why can't rkmpp be enabled on Armbian to give us harware accel out of the box? @Igor: The overlay link you provided above (mesa-vpu) is broken. And no such overlay exists in the prebuilt images for the Nano Pi M6. Result: still no hardware acceleration for my M6 with Armbian. -
@JamesCL This is a fantastic report — thank you, James. 🙏 You've actually confirmed two things I couldn't test on my own hardware… 1) eMMC works (detection + HS200 + read/write)… booting from eMMC is a separate step I haven't wired up yet. 2) 4GB variant confirmed (free -m shows 3830 MB)… The two warnings — you read it right, secure SRAM for OP-TEE/BL31, harmless, cosmetic DTS cleanup I'll tidy up. …that's the most useful kind of report there is. Thanks again! 🙌
-
I discovered via an only partly working ssh (I thought was WiFi signal strenght issue or so) that a new version of firewalld was installed and also new conf file that had default set to public instead of trusted (what should be fine for LAN only direct traffic). On a typical generic client-only laptop/computer you probably won't notice. Best is to keep that default and add a zone= statement to the NM profile for a specific connection. I have seen the same for systemd-networkd, but not done anything myself with it. Also should not happen on Debian Stable, but rolling distro is another story.
-
Hi, I'm testing your Linux image on an Orange Pi 4B/4A with an eMMC installed and wanted to share the results. The image correctly detects the eMMC. The kernel recognizes the device as: mmcblk2: mmc2:0001 ISOCOM 58.3 GiB Operating mode: HS200 image : aurealnix-opi4a-debian13-cli-v0.2.img.xz @AurealNix Thank you for your work. Update: During boot, the kernel reports two reserved-memory warnings: OF: reserved mem: Reserved memory: failed to reserve memory for node 'sec-sram1@42350000' OF: reserved mem: Reserved memory: failed to reserve memory for node 'sec-sram2@43000000' The system remains fully functional. OP-TEE and BL31 reserved-memory nodes are present in the device tree, and eMMC HS200 operation has been tested successfully. root@orangepi-4a:~# uname -a Linux orangepi-4a 6.18.38-g59eb61929e89 #49 SMP PREEMPT Thu Jul 16 00:46:12 CEST 2026 aarch64 GNU/Linux root@orangepi-4a:~# free -m total used free shared buff/cache available Mem: 3830 330 95 9 3592 3500 Swap: 0 0 0 root@orangepi-4a:~# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 13 (trixie)" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie DEBIAN_VERSION_FULL=13.6 ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" root@orangepi-4a:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk0 179:0 0 7.4G 0 disk └─mmcblk0p1 179:1 0 7.4G 0 part / mmcblk2 179:32 0 58.3G 0 disk ├─mmcblk2p1 179:33 0 1.2G 0 part └─mmcblk2p2 179:34 0 57.1G 0 part /mnt/emmc-test mmcblk2boot0 179:64 0 4M 1 disk mmcblk2boot1 179:96 0 4M 1 disk root@orangepi-4a:~# fastfetch _,met$$$$$gg. root@orangepi-4a ,g$$$$$$$$$$$$$$$P. ---------------- ,g$$P"" """Y$$.". OS: Debian GNU/Linux 13 (trixie) aarch64 ,$$P' `$$$. Host: OrangePi 4A ',$$P ,ggs. `$$b: Kernel: Linux 6.18.38-g59eb61929e89 `d$$' ,$P"' . $$$ Uptime: 38 mins $$P d$' , $$P Packages: 299 (dpkg) $$: $$. - ,d$$' Shell: bash 5.2.37 $$; Y$b._ _,d$P' Terminal: /dev/pts/2 Y$$. `.`"Y$$$$P"' CPU: sun55i-t527 (8) @ 1.80 GHz `$$b "-.__ GPU: Allwinner sun55i-a523-mali [Integrated] `Y$$b Memory: 331.41 MiB / 3.74 GiB (9%) `Y$$. Swap: Disabled `$$b. Disk (/): 744.36 MiB / 7.19 GiB (10%) - ext4 `Y$$b. Disk (/mnt/emmc-test): 24.49 GiB / 55.91 GiB (44%) - ext4 `"Y$b._ Local IP (eth0): 192.168.7.12/27 `"""" Locale: en_US.UTF-8 root@orangepi-4a:~#
-
RADXA Cubie A5E 1GB RAM Armbian CLI stucks while uboot via sdcard
Guation replied to chapeaufer's topic in Allwinner sunxi
Hi xaja34, The patches and all code modifications used to build the 1 GB Cubie A5E images are already present in my repository. I pushed the complete Git commits alongside the prebuilt images that I published in the Releases section. You can find the changes here: radxa-cubie-a5e-armbian-build@202f1bf Best regards, Guation - Last week
-
@L. Jorge Soares Thanks a lot for testing both — genuinely, this is the most useful thing anyone can do for the project. 🙏 CLI: great to hear it boots and HDMI works on your setup — that's the first confirmation from hardware other than mine, so it means a lot. If you get time, I'd love to hear how it holds up (networking, USB, and the 4 GB variant if that's what you have). Root password: that's by design, not a bug. Root login is locked on purpose — the image ships with a default user / user account and SSH enabled, so an open root account would be a security hole. Use the user account with sudo: root shell: sudo -i (or sudo su) to set a root password if you really want one: sudo passwd root KDE image + Etcher error: let's pin it down. Full disclosure — I flash with dd myself, so I haven't actually run these images through BalenaEtcher; I'll test the Etcher path on my end to try to reproduce it. In the meantime, two quick checks: Verify the download — a truncated/corrupt download is the #1 cause of Etcher errors. The desktop image sha256 is: 63b0019423d2a320aaa5fe58df97db68823b353a30510ffa863fec475904e0ba Check yours: sha256sum on Linux/Mac, or certutil -hashfile <file> SHA256 on Windows. If it doesn't match, re-download. And thanks for the heads up — I'll also double-check on my end that the file on the release didn't get corrupted during upload. Card size — the desktop image is ~5.3 GB when written (bigger than the CLI one), so it needs an 8 GB or larger card. A smaller/oddly-sized card makes Etcher fail. If the checksum matches and the card is 8 GB+ but it still errors, it's most likely Etcher choking on the .xz — try Raspberry Pi Imager (Use custom → pick the .img.xz), Rufus (it writes in DD Image mode and takes the .xz directly), or on Linux just dd: xz -dc aurealnix-opi4a-debian13-v0.2.img.xz | sudo dd of=/dev/sdX bs=4M status=progress And if you can, paste the exact Etcher error text — that tells me straight away whether it's a size, decompression, or validation issue. Thanks again for digging in! 🙌
