https://forum.armbian.com/discover/14/Armbian Community Forums - Active threadsenThu, 08 Oct 2026 20:43:09 +0000Until someone dares sending PR for Current …Thu, 08 Oct 2026 17:20:38 +0000What I mean here is that (from what I saw in the bootloader logs) it searches the SD card and can't find a valid UEFI or kernel to boot, just felt like clarifying.Thu, 08 Oct 2026 16:27:44 +0000Deleted accidental postThu, 08 Oct 2026 16:14:02 +0000While doing some testing of multiple things I decided to build 2 images, fresh/new for my nanopineo's also trying to have the resulting image as close as possible to what I have running on the nanopineo's for years since 2022 or so. That was originally Armbian Buster and I have been tweaking the installations to match other computer installations. Main thing is split the root partitions into a rootfs (Btrfs) and a bootfs (Ext4). More recently, I did more changes, such that I can run the whole image as KVM and/or systemd-nspawn container. The 1st image was adding extension 'u-boot-menu'; build ended in success, but have not tested it on HW. I saw in extlinux.conf that there was no 'FDT' line (with sun8i-h3-nanopi-neo.dtb), which I did ad myself in own extlinux testting/semi-automatic .conf generation, but as BOARD=nanopineo, the U-Boot can know a default to be loaded, or nothing at all as the DT in the U-Boot is likely good enough or almost the same as th eone from kernel, but maybe I test/challenge that later. The 2nd image build was just 'u-boot-menu' replaced by 'grub-with-dtb': cd /local/s0/armbuild/ sudo btrfs subvolume create nanopineo sudo chown 1000:1000 nanopineo cd nanopineo git clone https://github.com/armbian/build cd build ./compile.sh \ BOARD=nanopineo \ RELEASE=trixie \ BRANCH=edge \ BUILD_DESKTOP=no \ BUILD_MINIMAL=yes \ NETWORKING_STACK=systemd-networkd \ FIXED_IMAGE_SIZE=2G \ IMAGE_PARTITION_TABLE=gpt \ BOOTPART_REQUIRED=yes \ BOOTSIZE=256 \ BOOTFS_TYPE=fat \ ROOTFS_TYPE=btrfs \ BTRFS_COMPRESSION=zstd \ COMPRESS_OUTPUTIMAGE=sha \ EXTRAWIFI=no \ KERNEL_CONFIGURE=no \ KERNEL_BTF=no \ KERNEL_GIT=shallow \ ENABLE_EXTENSIONS=watchdog,net-systemd-networkd,uboot-btrfs,grub-with-dtb It then fails with: [🔨] E: Unable to locate package grub-efi-armhf-bin [🔨] E: Unable to locate package grub-efi-armhf The issue here is that the Debian package must be: grub-efi-arm Also I now remember an issue from years ago when I made a non-EFI system UEFI bootable, must have been RPi thing or so, but also did it several times for x86. AFAIR if only grub-efi-arm and grub-efi-arm-bin, you get into trouble later on, can be years later when dist-upgrading in-place. So I just do 'apt install grub-efi' which then works fine as is pulls in also some dependencies. Not 'efibootmgr', that is just recommended, and I add that manually as most systems allow storing boot URL's in SPI-flash or so, certainly the KVM ones where machine is using EDK2 UEFI, which I use extensively. So it seems to me that this is an architecture naming or aliasing issue, like we have amd64 vs. x86-64 vs. x86_64 and arm64 vs. aarch64 If just 'grub-efi' that also works for riscv I guess, so avoiding this naming/aliasing issue and also better future proof. It might be that dependencies are not supported in image building, I don't know enough about that to judge. I have also not looked in detail at size impact, but it is relative I would say. There is plenty of other issues that claim more space or can reduce way more. There were more issues, but I solved those via trial-error, no show-stoppers. Although topic tag NanoPi-NEO, this is more like an Armbian Build issue, but for me it is about my 5 NanoPi-NEO's that are still great (and still overkill for their 4x Cortex-A7), but they are still Debian 32-bit ARMv7, not like unsupported RPi0/1 single-core ARMv6 (arm11* or older). A reason for wanting EFI bootloader is that upgrading/testing can by done in a KVM running on RPi4 (fast USB3-SSD) or ROCK3A (fast PCI-Ev3x2 NVMe) while using (differential) btrfs send|receive, which is way faster than on SD-cards en real HW. The other option is via U-Boot (QEMU -enable-kvm option), is supported for 64-bit in Armbian by BOARD=qemu-uboot-arm64, not for 32-bit.Thu, 08 Oct 2026 08:58:31 +0000Thu, 08 Oct 2026 07:38:02 +0000unreadable walls of barfed ai stuffThu, 08 Oct 2026 07:21:56 +0000I recommend using "caveman ultra" skill to reduce the barfed out walls of slopThu, 08 Oct 2026 07:19:34 +0000@Nick A I updated the latest patches from jernejsk and added support for x98h. https://github.com/bk3a12/build/tree/sunxi-7.2Thu, 08 Oct 2026 05:46:18 +0000Thu, 08 Oct 2026 03:56:57 +0000Also to me it looks strange, but it works (in the configuration without the backslash)Wed, 07 Oct 2026 17:35:27 +0000Now this issue has been fixed on Odin2 edge 7.2 kernel branchWed, 07 Oct 2026 04:02:04 +0000I had em build the damn thing. I think it was 39 lines of code: Cool having first https://bugzilla.mozilla.org/show_bug.cgi?id=2078820Tue, 06 Oct 2026 23:33:51 +0000A look at the USB-PD, PHY, hotplug, and DRM changes involved in making USB-C DisplayPort Alternate Mode work on RK3588/RK3576, and where they stand on the way to mainline Linux. View the full articleTue, 06 Oct 2026 20:32:03 +0000Its a purely cosmetic issue, but we will look into it when possible. Check if your kernel is upgraded - BSP package carries low important updates.Tue, 06 Oct 2026 16:54:20 +0000Tue, 06 Oct 2026 12:59:29 +0000Tue, 06 Oct 2026 12:59:29 +0000Tue, 06 Oct 2026 06:08:00 +0000Hm. It MAY not work because the upper layer (patches/u-boot) to say has no patching config for this particular board, but just guessing. Try this way: https://github.com/armbian/build/compare/main...EvilOlaf:build:sunxi-uboot-config-sample patching config ensures recognition of plain dts and defconfigs and copies them into the source tree before compilation. The defconfig I put in there is just a sample.Tue, 06 Oct 2026 04:45:22 +0000Tue, 06 Oct 2026 00:44:40 +0000So I bought a soldering air gun and removed the SSD chip. So I have MaskROM all the time I booted up with SD card (with Multitool on it) but symptoms are quite the same - in UART I can see the system is still complaining on memory: user@x1:~$ picocom -b 115200 /dev/ttyUSB0 picocom v3.1 port is : /dev/ttyUSB0 flowcontrol : none baudrate is : 115200 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no hangup is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, logfile is : none initstring : none exit_after is : not set exit is : no Type [C-a] [C-h] to see available commands Terminal ready DDR version 1.15 20190428 ID:0xFFF In col error ERR My current guesses are: - either there's something wrong with the memory initialization blobs, that are coming with Multitool. I need to find a way to replace them or configure them to use different clock speed / timings / whatever - or my memory chips (or their power supply) are bustedMon, 05 Oct 2026 14:14:18 +0000Hi everyone, I’m sharing an engineering paper about getting a PP-OCRv6-based RapidOCR pipeline running on the Orange Pi Zero 3W’s Allwinner A733 / Vivante VIP9000 NPU, integrated into Visual AI. Full paper: https://github.com/sog777/orange-pi-zero-3w-rapidocr-npu The tests used the Orange Pi Debian 12 Bookworm image and its vendor NPU stack, not Armbian. This is an engineering case study, not an Armbian support request or a claim that the same binaries work on an Armbian image. The paper covers the ONNX → ACUITY → NBG → VIPLite conversion path, static model shapes, targeted convolution and LayerNorm graph rewrites, quantization, simulator-versus-hardware checks, and physical-board validation. The selected system remains hybrid: text detection and eligible recognition attempts run on the NPU, while canonical ONNX Runtime CPU recognition checks every crop and supplies the final text and confidence scores. Wide lines, orientation classification, preprocessing, and post-processing also use CPU execution. A repeated reference recognizer test passed 100 runs, with a median call of 13.36 ms. A CPU-verified 18-line page took approximately 1.64–1.66 seconds, including 18 NPU recognition attempts and 18 CPU checks. These are different benchmark scopes; reference agreement does not establish perfect transcription, and no matched CPU-only speed advantage has been established. The paper also describes higher-resolution tiled detection and rejected full-NPU experiments. One candidate reduced aggregate CPU consumption by approximately 77.65%, but increased processing time by approximately 79.34% and regressed accuracy, so it was not promoted. I’m posting this for SBC developers interested in the practical limits of accelerator conversion and validation. This is a paper-only publication, without commands, a source-code release, or model downloads. Feedback on the methodology is welcome.Mon, 05 Oct 2026 01:15:52 +0000@normanherms I was able to boot and ping the a7s board. I'm unable to ssh though. I don't have a TTL-bridge to setup the password! PS the build took around 50mins. EDIT: I was able to hook up a UART TTL bridge and login! bootlog here: https://pastebin.com/9H0gyYAJSun, 04 Oct 2026 23:32:28 +0000Hmm, after I learned more about the UAC and other things, I realized that there might be cheaper solutions (and I did actually really hands on it), but they are not Armbian related. Anyhow, I'll just share here if anyone is interested: TL;DR A much cheaper solution is to have a UAC 1.0 to I2S component connect to the PS5, then have another MCU acting as an UAC 2.0 host, do the DSP conversion, then send these audio packets to the speaker. The UAC 1.0 to I2S component could be any existing modules, such as PCM2706. You can also use a RP2040/RP2350 to build a UAC 1.0 device to I2S component. I actually partially done that work, see the long store below. The UAC 2.0 host MCU has some restrictions. The main restrictions are: The MCU must has the USB controller component that can be a USB host, and also supports at least USB Full Speed (FS, 12 Mb/s) The USB controller must support isochronous OUT transmission. That is the last step I failed in the attempt, see the long story below. STM32F401, ESP32-S3 are good candidates. Long story: I actually tried to use waveshre RP2350 USB A board to build a UAC 1.0 to 2.0 converter, because it looks very neat, and already has 2 USB receptacles on the board. I managed to use the PIO as a UAC 1.0 device, getting all the audio packets from my macbook (which requires another fix here). However, I failed at properly playing the sound from the Edifier speaker. Considering it is a timing and latency critical task, I actually utilized the dual core on the RP2350. There is one dedicated core for handling the DSP, and the other core is dedicated for the USB tasks (UAC 1.0 device and UAC 2.0 host). In the end, I did successfully forward the sound from macbook to the speaker, but the sound is incorrect and not listenable. The sound is always skipping. In the end, I tried to generate a 750Hz sine tone from the RP2350 itself to completely rule out the possibility of sound distortion from UAC 1.0 communication. The sine tone still has the same issue, and turns out it is because the USB controller on the RP2350 does not include the logic unit for handling the isochronous transmission. I tried to work around it, but seems to be impossible.Sun, 04 Oct 2026 20:08:29 +0000i got the same problem as @code-dev. in the preinstalled android os it shows that i have the rk322x board but inside is a rk3128. with the official rk322x images it takes a hella long time to boot and when it does it goes directly to the preinstalled os. when i try your images it doesn't boot, just stays blank screen. any ideas or tips to try? thanks for contributing.Sun, 04 Oct 2026 16:42:34 +0000