Active threads

They certainly did fork armbian, apparently at tag v24.11.1 AKA dd379da888f7d114f9f954d94a7ebcf261d179e5 $ git merge-base dd379da888f7d114f9f954d94a7ebcf261d179e5 main 017549347bb8c278a067d1be14c2f1b3538690c2 Add the Olimex repo as a remote and then rebase the latest armbian/build HEAD to their HEAD.

Following is the output of "mount|grep ro" root@rock-5-itx:~# mount|grep ro proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) /dev/sda2 on / type ext4 (ro,relatime) cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=19056) ramfs on /run/credentials/systemd-resolved.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700) ramfs on /run/credentials/systemd-networkd.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700) /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) ramfs on /run/credentials/systemd-journald.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700) ramfs on /run/credentials/getty@tty1.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700) ramfs on /run/credentials/serial-getty@ttyFIQ0.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700) Following is the output of "lsblk" root@rock-5-itx:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 1 7.5G 0 disk ├─sda1 8:1 1 256M 0 part /boot/efi ├─sda2 8:2 1 7.2G 0 part / └─sda3 8:3 1 8M 0 part sdb 8:16 0 465.8G 0 disk ├─sdb1 8:17 0 1M 0 part ├─sdb2 8:18 0 512M 0 part ├─sdb3 8:19 0 16G 0 part └─sdb4 8:20 0 449.3G 0 part mtdblock0 31:0 0 16M 0 disk mmcblk0 179:0 0 29.1G 0 disk mmcblk0boot0 179:32 0 4M 1 disk mmcblk0boot1 179:64 0 4M 1 disk zram0 253:0 0 11.6G 0 disk [SWAP] zram1 253:1 0 50M 0 disk zram2 253:2 0 0B 0 disk nvme0n1 259:0 0 1.9T 0 disk ├─nvme0n1p1 259:1 0 1G 0 part └─nvme0n1p2 259:2 0 1.9T 0 part

I uploaded an updated version of the package bundle, with MPV and a few other updates that I found laying around: https://mega.nz/file/ZmwDBL6b#pGgXVRnoC0jU6dwFJebBcLDXyTNqdkmw3qvsOLz5qUI

@Dann https://dl.armbian.com/rock-5b-plus/Noble_vendor_gnome verifies fine for me. Try https://netcup-03.armbian.com/dl/rock-5b-plus/archive/Armbian_25.5.1_Rock-5b-plus_noble_vendor_6.1.115_gnome_desktop.img.xz and https://netcup-03.armbian.com/dl/rock-5b-plus/archive/Armbian_25.5.1_Rock-5b-plus_noble_vendor_6.1.115_gnome_desktop.img.xz.sha

An update. I suspect that the issue (or at least 1 issue) is a regression in the handling of MMC (SD card driver in the kernel). I suspect this is a regression as this issue did not hit me on earlier builds. I set up a netconsole, and received the following stack trace: [ 216.236507] I/O error, dev mmcblk0, sector 849688 op 0x0:(READ) flags 0x84700 phys_seg 1 prio class 2 [ 216.524566] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 131108 starting block 323201) [ 216.534718] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 131109 starting block 323202) [ 216.544920] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 131110 starting block 323203) [ 216.560591] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 131111 starting block 323204) [ 216.575914] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss! (inode 131108, error -5) [ 216.587187] Buffer I/O error on device mmcblk0p2, logical block 270977 [ 216.601434] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss! (inode 131109, error -5) [ 216.601564] ------------[ cut here ]------------ [ 216.608348] Buffer I/O error on device mmcblk0p2, logical block 270978 [ 216.608383] WARNING: CPU: 0 PID: 129 at drivers/mmc/host/meson-mx-sdio.c:446 meson_mx_mmc_irq_thread+0x168/0x174 [ 216.608467] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss! (inode 131110, error -5) [ 216.608485] Buffer I/O error on device mmcblk0p2, logical block 270979 [ 216.612894] Modules linked in: rpcsec_gss_krb5 [ 216.619667] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss! (inode 131111, error -5) [ 216.629626] auth_rpcgss [ 216.629674] Buffer I/O error on device mmcblk0p2, logical block 270980 [ 216.629700] zram [ 216.632164] Aborting journal on device mmcblk0p2-8. [ 216.641941] zsmalloc [ 216.642033] JBD2: I/O error when updating journal superblock for mmcblk0p2-8. [ 216.648457] binfmt_misc [ 216.676718] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1639: inode #598: comm dpkg-reconfigur: reading directory lblock 0 [ 216.680959] evdev [ 216.681075] EXT4-fs (mmcblk0p2): I/O error while writing superblock [ 216.683223] snd_soc_meson_aiu snd_soc_meson_gx_sound_card snd_soc_hdmi_codec snd_soc_meson_card_utils snd_soc_meson_codec_glue snd_soc_core snd_pcm meson_ir snd_timer rc_core [ 216.683268] EXT4-fs (mmcblk0p2): Remounting filesystem read-only [ 216.683278] thermal_generic_adc snd meson_saradc soundcore cfg80211 rfkill efi_pstore pstore netconsole [ 216.744185] CPU: 0 UID: 0 PID: 129 Comm: irq/35-c1108c20 Not tainted 6.12.47-current-meson #3 [ 216.744207] Hardware name: Amlogic Meson platform [ 216.744212] Call trace: [ 216.744225] unwind_backtrace from show_stack+0x10/0x14 [ 216.744259] show_stack from dump_stack_lvl+0x50/0x64 [ 216.744275] dump_stack_lvl from __warn+0x80/0x11c [ 216.744294] __warn from warn_slowpath_fmt+0x17c/0x188 [ 216.744311] warn_slowpath_fmt from meson_mx_mmc_irq_thread+0x168/0x174 [ 216.744337] meson_mx_mmc_irq_thread from irq_thread_fn+0x1c/0x7c [ 216.744364] irq_thread_fn from irq_thread+0x134/0x224 [ 216.744378] irq_thread from kthread+0xe0/0xfc [ 216.744396] kthread from ret_from_fork+0x14/0x28 [ 216.744411] Exception stack(0xf1075fb0 to 0xf1075ff8) [ 216.744420] 5fa0: 00000000 00000000 00000000 00000000 [ 216.744428] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 216.744435] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 216.744458] ---[ end trace 0000000000000000 ]--- [ 217.163204] mmc0: new high speed SDHC card at address 0002 [ 217.163907] mmcblk0: mmc0:0002 Which suggests the SD card was connected and disconnected. I have already ruled out faulty SD card (happens on any SD card I use, as well as a thorough stress test on the current card prior to use). Further research tells me "The Amlogic Meson8b (S805) SoC’s MMC controller has known quirks." I switched to USB rootfs (external HDD), and I still get the same failure, but as it is just the boot partition being unmounted and remounted the system remains up. Ideally I would propose a patch to fix this, but I am not a kernel developer, and the changes between 3.10 and 6.12 are huge (as to be expected) so identifying what is required and where is non-trivial for me. For now, I am sticking with rootfs on USB as my interim fix, but I am going to keep netconsole up and monitor over the next couple of weeks to see if we hit another issue (when I tested this in the past, I was also getting failures with rootfs on an external USB stick, so I am not convinced I am completely out of the woods yet).

AFBC support has been merged to PanVK and will be available in the Mesa 25.3 release! This new enablement reduces memory bandwidth and boosts performance. View the full article

@remolaan "...Hey i have a SDMC DV8040 stb ,SoC-Amlogic S805X,CPU-Quad-core 1.2 GHz,GPU-ARM Mali-450,RAM-1GB,Storage-8GB it currently runs custom made android 9..." Please @remolaan, could you send me a working download link for the custom Android 9 system you made?

You can add APA to your system and as one of the benefits get a managed GPG key so you should not run into this issue again in the future.

Armbian 25.8.1 Noble XFCE (mainline Kernel: 6.16.6-edge-rockchip64) + PanVk - mesa 23.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + box64 3.7 (https://ryanfortner.github.io/box64-debs/) + wine-10.15-staging-tkg-ntsync-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/10.15) + DXVK-stripped v2.7.1 ~60fps@720p Hades

Hello @Ian Coelho, have you ever got any solution? I got the same issue

As long as you keep the discussion about this at their place... ophub is (ab)using the name Armbian without permission and they do not contribute to the core development process. Rather they trick users into thinking they get support here and therefore (ab)using our resources.

zero2w != zero2 moved

@Rodrigo Campos @kazekami_him I think @nitrolack and @afiftyp had the same Transpeed M98-8k board. It booted fine with my transpeed image. (other than wifi) They didn't have a board that had secure boot. Check if your board is the same. Maybe you could try my older images. It could be the newer u-boot and patches broke the ram detection? Maybe your board is using a different ram?

Hi and Thank @jock That's what I thought. I used ledconf-3 because that's the configuration you made specifically for my MX10 box. I ran a memtest, which went smoothly. The system is working, and I was able to compile rockchip mpp without any problems. The system is running Bookworm. Would it be better to update to Trixie or revert to a previous version? What do you think? I think the problem comes either from rk3318-box.dtb or from the overlays. Thanks again. 🤜🤛

@jock well thanks but I already figured that part out 😊 my problem right now is that i can't find a single distro that works with my box . almost every one (even multitool) goes to a black screen and freezes excatly after 60 seconds . the best thing i could find was a android rom that have the same problem but in excatly 30 minute after booting up ! i did this stupid thing that did not backed up my original rom before writing to internal emcp flash 🤦‍♂️ if i can find any version that doesn't have this problem , i know how to merge armbian rootfs with it ! thank you again !

Have you tried your python script with your Linux PC? If it happens again, you can tell that the problem is within the ESP32 program. I generally prefer having the most complex system (Armbian) poll the simplest device (ESP32), instead of the ESP32 interrupting the Armbian system. I found it more stable that way. Stay with wifi, and use the ESP32 serial port just for debugging. Program the ESP32 print an acknowledgement of data requests, and an alarm if it gets stuck in an unexpected state. I have also found ESP32 circuit or micro python very stable for serial port communications.

@Hqnicolas would it be possible to have the driver @guenter pointed out in the base image?

I think the core problem is that headers were compiled with Ubuntu compiler / userspace and you try to use it on Debian. I used this on Ubuntu, which is the reason why it worked. We are aware of this problem - headers should be distro specific. Which adds complexity on our side ...

Feel free to pr any missing overlay here: https://github.com/armbian/linux-rockchip

moved to csc https://docs.armbian.com/User-Guide_FAQ/#why-no-universal-image tl;dr: You are using the wrong image. Get/build one for your board

I don't see it as the very latest bleeding edge kernel version. I see it as a newish Linux, which already has the armbian patches updated for. Some CPUs end up with newer or older Linux versions, due to varying levels of development success. For example, sunxi's armbian edge is 6.15.4 today, but the linux trunk is up to 6.17-rc6 ... (not available in Armbian)

I tried it on 6.16.7, and the log started working: [ 4.838111] rockchip-drm display-subsystem: [drm] fb0: rockchipdrmfb frame buffer device Error again after initialization: [ 5.118148] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes [ 5.637839] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes

Has anyone ever gotten the Radxa Zero 3w working in gadget mode? I bought a Zero 3w about a week ago and have been beating this horse most of the time. I can't get the device to connect via USB. A or C. When I try to connect (radxa.local) it will always go through wifi. If I have wlan0 disabled or even my internet off it just will NOT connect. It clearly is using wifi to connect even if I use the hostname. Maybe this is something simple but I and another engineer I work with have been scratching our heads about it. The obligatory AI search was an endless loop of everything we had already tried. Anybody have any advice?

I was considering rebuilding the initrd image for orange pi 5 as I think there was an issue in what was put on the image file. But now I have an a system settup with 6.1.115 - I should be good.

Hello, I am selling a working unit of Kobol Helios64 with the fix done, without drives. Based in Czech Republic, able to send within EU. Please DM me if interested.