All Activity

Hello @Malay! Same for you: cannot reproduce. Can you rebuild with SKIP_ARMBIAN_REPO=yes? This builds a little longer but skips cached stuff. Alternatively, rm -r ./cache from the build dir. To help with this, I will start the following commands on my PC and upload the results later to https://privat-in.de/ (Download section). LG // Sven-Ola

Hello @maxsub, we are talking about git log --oneline -1 which says 613737fab. The post_family_tweaks_bsp__orangepirv2_wifi() from above is exactly what's in there. If you run you should get on the board Can you please elaborate on the "got it"? TIA // Sven-Ola

Was running Ubuntu Noble and mpv-0.37 is from Noble-repo. On Trixie the mpv is version 0.40 (Debian Trixie repo) which somehow does not seem work with the ffmpeg-v4l2request. Are you running Trixie or Bookworn? Is your device Opi5-Plus or RK3588? So far on my Opi5-Plus no luck with 10Bit Hevc or any 10Bit video on mpv with mainline kernel.

I confirm that when building an image with the Edge 6.18 kernel, WiFi does not work. Also, when building an image with the Xfce desktop, the image is approximately 3 GB (it should be more than 4 GB), but it is not there, only the command line works.

Hi everyone, I have rock 5c with PWM fan. I want to control the fan speed manually. Running on Armbian 25.11.1 Noble. Sorry if its obvious I am newbie to this

I was surprised when mine played H265 10 bit. I thought I'd read somewhere v4l2 was limited to 8 bit. Obviously that was incorrect.

I'm very new to Armbian so I could be off track here but I noticed your running MPV version 37. When I ran the instructions for the first time I already had mpv installed (version 40 or something) so it didn't get updated. I ended up uninstalling MPV and running the instructions again. Now I have version 35.1 which fixed the drm_prime errors for me. The version difference could be because you are on 26.2 of Armbian and I'm on 25.05, I haven't got my head around all the different versions of things yet. Maybe try uninstalling MPV and trying the commands again and see what version it gives you.

This video should give you the information you need for setting up a usb debug uart connection:

@Nick A I am not sure whether you can help release some versions of image with ufs supported, as I tried to compile from source with @chainsx git, but not once successful. If you can release the relevant versions of ufs support image? Thanks

Got it! But this DKMS should be loaded by the build: function post_family_tweaks_bsp__orangepirv2_wifi() { display_alert "$BOARD" "Force load bmcdhd wireless" "info" run_host_command_logged mkdir -pv "${destination}"/etc/modules-load.d run_host_command_logged echo "bcmdhd" > "${destination}"/etc/modules-load.d/${BOARD}.conf }

I record a video of the board to see if with this info I don't need to read the outputs via uart. Can't find how to up images. What uart cable I need ? Can you post one from aliexpress. Thanks.

Hu? In difference to Spacemit 6.6.99, the 6.18 kernel has no bcmdhd included. For that reason I put in an adapted version of bcmdhd in a DKMS, installed via a source deb from my repo on codeberg.org/sven-ola. B/c DKMS needs a compiler on the board, the edge image is larger than current image. Code quality of bcmdhd is questionable so it probably never make it into the official Linux tree, but it works (at least on my board with my image). HTH // Sven-Ola

@Nick A Hi Nick, how are you? I have a motherboard identical to the one in the photo you posted, with an AXP313A. I tried the image you recommended, but the Wi-Fi didn't work. Could you give me any advice?

I don't have the usb that you mention. I open the console to clean the fan and I did photos of board but I don' t remember where I place the photos. Give me five minutes to put here photos I need to unmount the box.

Update on NanoPi M4v2 ... I pulled the most recent Armbian build, and manually ran the build for the M4v2, and it fails on kernel patch "general-gpio-driver-no-sleep". See pastebin at https://paste.armbian.com/puvorasuco for failed build. Checking upstream at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git, it looks like branch 6.18.y already has the subject patch, and was pushed today. Since both the rockchip and rockchip64 families use mainline kernel, I just submitted a PR that kills that patch for both. See https://github.com/armbian/build/pull/9368.

Hi, It seems that the Odroid N2 armbian builds do not support using armbianEnv.txt AT ALL. See this forum entry from 2021: I am facing the same issue with Armbian 26.2.1 Minimal dmesg shows the following: [ 0.000000] Kernel command line: root=UUID=c8906fe5-129c-4388-840c-58c43c541176 rootwait rootfstype=ext4 splash=verbose console=ttyAML0,115200 console=tty1 consoleblank=0 coherent_pool=2M loglevel=1 ubootpart=001c9d62-01 libata.force=noncq usb-storage.quirks= cgroup_enable=memory with the following in /boot/armbianEnv.txt: verbosity=1 console=both overlay_prefix=meson rootdev=UUID=c8906fe5-129c-4388-840c-58c43c541176 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I also tried adding extraargs= but nothing ends up in the command line. The old forum entry does mention editing the boot.ini to manually append it to bootargs, however I am not sure where that is located in the image and how to modify it. I tried both booting with petitboot and without, both show the same issue.

On RV2 with the edge branch WiFi does not work.

Armbian_26.2.1_Rock-3a_trixie_current_6.18.8_minimal.img.xz (ROCK3A) - system has NVME inserted and SATA M.2 E-key adaptor where HDD is connected to - SPI has Armbian legacy U-Boot, but that is skipped as SD-card with new image is inserted - further only power, ethernet and serial console cable connected: 1st boot and user creation all fine - network up, WAN IP shown - NVME is available (but OS is running from SD-card for the test) - SATA is not available as not supported mainline based kernel (and needs adding overlay manually when vendor kernel) - reboot does not reboot (but 'echo 1 > /proc/sys/kernel/sysrq ; echo b > /proc/sysrq-trigger' works) - also poweroff is only shutdown, no powerdown (and HDD keeps also spinning)

At this point you seem to have done everything properly. The next step would be to find the uart connection point on you board and hook up a usb-uart reader so you can see the debug output from uboot to see what is happening.

That is enabling multiboot (what enabled either Armbian or android to boot. I'm going through with you all the basics that you didn't mention in your original post (and that others often forget to do), to eliminate all the basic things. You say "maintain it", but you shouldn't hold that button too long, a few seconds (10 at most is all you need). Holding too long will not work.

Armbian_26.2.1_Bananapi_trixie_current_6.12.68_minimal.img.xz (Bananapi M1) - only power, ethernet and serial console cable connected: 1st boot and user creation all fine - network up, WAN IP shown - then connecting a SATA SSD ('hotplug'), pops up in dmesg, so recognized OK

I follow this instructions The reset button in the case of my box is inside Av connection, I already boot the images with press the button and maintain IT. The result is a screen with HKSERIES screen, I can wait one hour nothing happens only the image. A video to you see that I press the reset multiboot button. Thanks.

some things are happening at the bleeding edge https://lore.kernel.org/u-boot/?q=a733 pay attention to u-boot, the most important thing are dram controller, pmic, mmc/sd etc then of course kernel as well https://lore.kernel.org/linux-sunxi/?q=a733

Take some time but I was able to identify the CLK pin. Shorting the marked pins (CLK and GND in this case) was able to switch MaskRom mode. Note: in early boot stages the eMMC CLK only working in legacy mode (24Mhz).

Sorry in advance, but this is a bit of a dive. But, I haven't seen this fully captured and explained anywhere, and think this would be a useful thing to know for anyone who's doing arm64 development on a PC, which seems very relevant here ... I started pulling this thread when moving some software from Ubuntu Jammy to Noble, where the arm64 build process went from 20 mins to 50 mins. When I was done, it below to 15 min, and all I did was poke some flags for qemu's emulated CPU. The TL;DR version is that setting the environment variable QEMU_CPU to something like "cortex-a53" or "max,pauth-impdef=on" or even what I settled on, "max,pauth=off" saves massive amounts of time, and should be used anywhere you are running debootstrap, apt, or python in an emulated environment. However, you can't blindly set it everywhere because these flags are not defined for other architectures and will cause a hard stop when emulating PC or RISC-V. This has also shown up in the Armbian Build System. If you want to see this first hand, use the example here. Just save the following in test.sh: echo -n "testing... " for i in $(seq 2 10000); do is_prime=1 j=2 while ((j*j <= i)); do if (( i % j == 0)); then is_prime=0 break fi ((j++)) done if (( is_prime == 1 )); then echo $i > /dev/null fi done echo "done" And then run it in docker after ensuring a few things are installed ... ~ $ sudo apt install binfmt-support qemu-user-static ~ $ time docker run --rm -it --platform linux/arm64 -v .:/test ubuntu:noble /test/test.sh testing... done real 0m37.620s user 0m0.013s sys 0m0.022s ~ $ time docker run --rm -it --platform linux/arm64 -v .:/test ubuntu:jammy /test/test.sh testing... done real 0m4.700s user 0m0.011s sys 0m0.023s And we can wrestle that performance back by fiddling with QEMU flags ... ~ $ time docker run --rm -it --platform linux/arm64 -v .:/test --env QEMU_CPU=max,pauth=off ubuntu:noble /test/test.sh testing... done real 0m4.694s user 0m0.011s sys 0m0.024s So qemu bug? Not quite. The qemu emulator is a host application, and is the same both jammy and noble docker images, and I think the root cause was found here, and first appears in Ubuntu Lunar (23.10). The short version looks like gcc's stack protection logic wasn't operating as expected as the stack layout is a little different than it is on PC, a CVE was filed, and the "fix" is now stressing a slow code path in qemu. For the record, my heart goes out to "steev" and his slow, hours-per-bisect march to the answer. Pulling that thread a bit more, the QEMU Documentation has the following to say on the subject of arm64 pointer authentication: The qemu docs also suggest that the qemu impdef algorithm is the default, but I've not seen this on my version. It's possible this may be addressed in a much newer version of qemu, but that's not available in the Noble repos. It could be overridden via tonistiigi/binfmt (but I've not yet tested that). For what it's worth, it's not possible to just add a simple wrapper to qemu fix this either, as seen in this Github Example, and that's due to the Linux Kernel Binfmt Interface. The 'F' flag forces the kernel to store a handle to the specified emulator, and make it available in chroot and Docker contexts, and that doesn't help if it's only the wrapper it grabs and not the emulator binary. Similarly, it's not possible to pass additional flags via this interface, so without a change to the qemu binary, the QEMU_CPU environment variable may be the only way to work around this immediately. The other curious bit is what does QEMU_CPU=cortex-a53 enable to recover qemu speed? The answer is absolutely nothing. it just turns CPU features off. At a glance, I'm not sure if that something qemu is doing indirectly, or glibc conditionally enables at runtime. If anyone knows better than I here, please drop a comment. The curious can check can via: ~ $ docker run --rm -it --platform linux/arm64 ubuntu:noble cat /proc/cpuinfo processor : 0 model name : ARMv8 Processor rev 0 (v8l) BogoMIPS : 100.00 Features : fp asimd aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svef32mm svef64mm svebf16 i8mm bf16 rng bti mte mte3 sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 smefa64 mops hbc CPU implementer : 0x00 CPU architecture: 8 CPU variant : 0x0 CPU part : 0x051 CPU revision : 0 ~ $ docker run --rm -it --platform linux/arm64 --env QEMU_CPU=cortex-a53 ubuntu:noble cat /proc/cpuinfo processor : 0 model name : ARMv8 Processor rev 4 (v8l) BogoMIPS : 100.00 Features : fp asimd aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4