All Activity

Hi, Just to baseline some stuff: The baudrate you use in screen, it's set to 1.500.000 ? Did the serial cable work before? Or is this the first time you use a C-C cable? I know too little about the differences of C-C vs A-C cables, but if this is the first time using the C-C cable, please try to use A-C with some Mac-to-A hub. I can only confirm an A-C cable works here. Are you sure that the connector of the C end at the Helios64 side is making proper contact? In my (and other's case) the actual plug part did not fully pass through the case. I had to cut some of the plastic away of the C side to expose more of the actual connector. This way it fully entered the case and made better contact with the board. Not sure if I'm explaining this well or not, let me know if this is not clear. Is there anything on your Mac side that is trying to automatically mount the card while you are writing the image? Are you sure the entire image was written to the SDcard? e.g. Did you use conv=fsync for dd ? Or a sync before removing the SDcard? (There is no umounting happening as the card could not be mounted you mentioned.) Did you try and sha256 sum the SDcard contents as well? You should be able to do that (slowly) with dd if=/dev/sdcard bs=1 count=$(stat -c '%s' Bookworm_current_minimal) | sha256sum Make sure to remove the card first and reinsert it to avoid dd is reading cache. Grt,

Just a short update to say that I also tried the balena Etcher with no changed behavior.

Hi, The output of `parted [.img file] unit s print` is: I'm on macOS, which isn't able to read ext4. Mounting didn't work at all. I also tried with a Debian image via docker but the mount command was not permitted (even with using sudo). The only other Linux machine I have is a Steam Deck, which I might be able to use in Desktop mode for this. I did run sha256sum on the downloaded file and checked with the hash on the Armbian page. Afterwards just ran `xz` and `dd`. I repeated this on a different machine (also macOS) and the outcome still the same. EDIT: Oh you meant for me to run sha256sum on the unxz'd file, so the .img file directly. The checksum is indeed the same as what you posted. I do agree that it seems like the SDcard and/or image are at fault. I tested two different power cables on two different Helios64 machines, it kind of has to be this. But what else could I try? The USB-C cable I use to get access via `screen` is USB-C to USB-C and is confirmed to be for data&charge. I saw that the Helios64 documentation says to use USB-C to USB-A but I doubt that this is the reason for the flaky connection. It does seem like an issue with the Helios64.

Great, so I used the config file provided in the previous post that I quoted, with a small change: I replaced "LINUXFAMILY" with "BOARDFAMILY". Am I to place patches to the kernel and u-boot inside userpatches? When in the build process should I do that? U-boot does work currently, and the original problem when I try to boot is that after "Starting Kernel..." I have nothing visible over HDMI or on the on board display (Or no way to check that I know of if anything is working). What I understand currently is that since U-boot works, I need to first provide a dts file that makes the display work, and then configure armbian build script to use that dts file, is that the way to go? On linux-sunxi mailing list I was told that the display on this works with the simple panel driver using the "starry kr070pe2t" entry. At this point I am not sure what the immediate next step should be. Thank you!

I have having the same issue as discussed here & it also provided solution for it https://github.com/IceWhaleTech/CasaOS/issues/1136 I have added cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1 to armbianEnv.txt The dmesg logs indicate that these arguments are failing [ 15.630904] Kernel command line: root=UUID=eb6a27ef-3932-431f-92fd-e61fea75356c rootwait rootfstype=ext4 splash=verbose console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=f3aeb909-d11b-ec42-a52c-4507e474335c usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u,0x1058:0x25a2:u cma=256M cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory [ 15.631910] Unknown kernel command line parameters "splash=verbose ubootpart=f3aeb909-d11b-ec42-a52c-4507e474335c cgroup_enable=memory cgroup_memory=1", will be passed to user space. . . . [ 18.261976] Run /init as init process [ 18.262019] with arguments: [ 18.262028] /init [ 18.262034] with environment: [ 18.262039] HOME=/ [ 18.262044] TERM=linux [ 18.262049] splash=verbose [ 18.262054] ubootpart=f3aeb909-d11b-ec42-a52c-4507e474335c [ 18.262060] cgroup_enable=memory [ 18.262065] cgroup_memory=1 [ 18.263469] mmcblk1: p1 p2 The bug still haunts me, any ideas how should I approach this problem

I have questions about 1 building a full image that supports the Orange Pi 5 Pro. From my understanding of building the kernel - the supported modules for the chipset need to be built for the specific SBC card. I can easily access the correct kernel I would like. What I am lacking is an understanding of what source images to install on my build platform for the modules and what the the configuration settings specific to the SBC. Can someone clue me in? I haven't built a kernel in 20 years. I can try to make a case for Armbian to support the OPI 5 Pro or Max. But this isn't the right forum for that, I prefer the Pro or Max over the Plus as I do not need all those HDMI ports. My goal is to build two kernels - one on SMB Pre-emptive and one RT PREEMPTIVE - specifically for the Orange Pi 5 PRO and two images with all the I/O functional. Evidently the Armbian official builds are for the Orange Pi 5B and the Plus. I haven't exhaustively gone through all of the community supported offerings.

DKMS is 'quite complicated' , in an attempt to understand all that 'cryptic' stuff, I went googling around https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support https://www.linuxjournal.com/article/6896 https://github.com/dell/dkms https://wiki.gentoo.org/wiki/DKMS https://www.collabora.com/news-and-blog/blog/2021/05/05/quick-hack-patching-kernel-module-using-dkms/ https://www.baeldung.com/linux/dynamic-kernel-module-support https://nilrt-docs.ni.com/opkg/dkms_opkg.html ^ surprisingly I found this guide/tutorial from national instruments 'quite intuitive' and I dug further into how to make a kernel module, well at least a 'hello world' https://tldp.org/LDP/lkmpg/2.6/html/ https://tldp.org/LDP/lkmpg/2.6/lkmpg.pdf The Linux Kernel Module Programming Guide Peter Jay Salzman Michael Burian Ori Pomerantz Copyright © 2001 Peter Jay Salzman --- ok I actually tried building that 'hello world' kernel module and *it works*, for practically 'ancient' 2001 instructions. so it turns out that to compile a kernel module, you do not need to build it in the kernel source tree itself and that is *without* DKMS, read that last 2 tldp guides: The Linux Kernel Module Programming Guide you can try building and inserting the 'hello world' module into your kernel, no DKMS, whatever, after you build your module ! in short is it not necessary to build a kernel module within the kernel source tree itself, but that there are some procedures as spelled out in that 2 tldp docs. (but fast forward to today, this same instruction may not work if you are using secure boot, then a lot more complicated things like module signing gets involved, review that dkms link from dell) ------- now back to DKMS , where does that fit in? so it turns out that DKMS is a utility / tool / system / automation tool, to help you *rebuild the kernel module* - out of linux kernel source tree (i.e. as like the hello world module above), *without building the kernel from source itself* ! but that you need to ***rebuild the kernel module from source***(e.g. using DKMS), then all the other links above are guides that may be relevant ---- now add more complications / complexities, normally what you wanted is a *driver* , not simply a kernel module the driver often has several parts - the kernel module itself (this is the 'easy' part, you need to build it - from source), and that does not mean having to build the kernel itself from source, but you need to build the *kernel *** module *** *. after you build the kernel module successfully, say, then there are more blows and pitfall these days wifi and many network hardware requires *firmware files* , these *firmware files* can consist of 'bin' (firmware binary) and configuration (some of them text files) some of these firmware stuff lives in /lib/firmware. then that you need your kernel module, you can deem that the 'driver core' that interface the OS and interface those firmware. those firmware do not necessary run on the (host) cpu (i.e. your pc) but instead in the wifi chip itself. this is the part that is *highly opaque*, there are so many wifi chips that are *undocumented*, the firmware is *undocumented* and if you do not have any source for your kernel module which interface the firmware to the os, you are out-of-luck. ----- to summarise - normally, one cannot hope to take a binary kernel module install it in your current kernel and hope it 'just works'. if that works, a lot of things such as module versions and various constraints imposed by the kernel matches that in the kernel module itself, i.e. that module is compiled specifically for that specific kernel itself ! DKMS do not solve this, DKMS only *helps you rebuild the (kernel) module *** from source *** *, (and install it optionally). the idea is this, you have the *source* to your out of kernel source *kernel modules*, when you upgrade the kernel, e.g. such as an apt-upgrade etc, DKMS can be triggered to *rebuild the kernel module from source* (and install it) in the new kernel (binary) tree e.g. copy that into /lib/modules/{kernel version}/xxx --- if the kernel module is part of the kernel source tree itself, it actually do not need DKMS. But that if the errors occurs after building that *kernel module* (i.e. driver) , then congrats - you found a 'bug' in the *kernel module (driver)*, and that is true even if it is out of kernel source as a DKMS build. i.e. the driver sources need to be patched to work in the new kernel.

Hi, Curious what the result is of "parted u s pr" on the unxz'd image? As for the tools you mentioned, the basics like dd or even unxz'ing directly onto your device are a safe bet. I like to see what's going on and add sauce myself when needed. In addition to that, can you share the sha256sum of the unxz'd image file? I'm getting: djurny@ekspiees:~/Downloads$ sha256sum Bookworm_current_minimal 6a28d5e6af0eb3ab3f534a14f2f2092633397092e7032bf0f82621fea58194d7 Bookworm_current_minimal Also, try to loop-mount the image file to check if the contents are readable: First check the offset of the first partition in amount of sectors: djurny@ekspiees:~/Downloads$ parted Bookworm_current_minimal u s pr WARNING: You are not superuser. Watch out for permissions. Model: (file) Disk /home/djurny/Downloads/Bookworm_current_minimal: 2646016s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 32768s 2646015s 2613248s primary ext4 Mount the image: djurny@ekspiees:~/Downloads$ mkdir /tmp/image djurny@ekspiees:~/Downloads$ sudo mount -o loop,offset=$((512 * 32768)) Bookworm_current_minimal /tmp/image [sudo] password for djurny: 2444666666 djurny@ekspiees:~/Downloads$ ls -Failh /tmp/image/boot/ total 63M 32709 drwxr-xr-x 3 root root 4.0K Nov 24 2024 ./ 2 drwxr-xr-x 19 root root 4.0K Nov 24 2024 ../ 29474 -rw-r--r-- 1 root root 0 Nov 24 2024 .next 29472 lrwxrwxrwx 1 root root 33 Nov 24 2024 Image -> vmlinuz-6.6.62-current-rockchip64 29475 -rw-r--r-- 1 root root 4.9M Nov 17 2024 System.map-6.6.62-current-rockchip64 29476 -rw-r--r-- 1 1005 1005 130 Nov 24 2024 armbianEnv.txt 29477 -rw-r--r-- 1 root root 38K Nov 24 2024 boot.bmp 29478 -rw-r--r-- 1 1005 1005 3.8K Nov 24 2024 boot.cmd 29479 -rw-rw-r-- 1 root root 3.9K Nov 24 2024 boot.scr 29480 -rw-r--r-- 1 root root 243K Nov 17 2024 config-6.6.62-current-rockchip64 29473 lrwxrwxrwx 1 root root 29 Nov 24 2024 dtb -> dtb-6.6.62-current-rockchip64/ 32710 drwxr-xr-x 3 root root 4.0K Nov 24 2024 dtb-6.6.62-current-rockchip64/ 29669 -rw-r--r-- 1 root root 15M Nov 24 2024 initrd.img-6.6.62-current-rockchip64 29672 lrwxrwxrwx 1 root root 33 Nov 24 2024 uInitrd -> uInitrd-6.6.62-current-rockchip64 29671 -rw-r--r-- 1 root root 15M Nov 24 2024 uInitrd-6.6.62-current-rockchip64 29481 -rw-r--r-- 1 root root 29M Nov 17 2024 vmlinuz-6.6.62-current-rockchip64 djurny@ekspiees:~/Downloads$ After dd'ing the image to an SDcard, I was able to boot my Helios64 successfully: djurny@ekspiees:~/Downloads$ sudo dd if=Bookworm_current_minimal of=/dev/mmcblk0 conv=fsync status=progress It all seems to work? So my guess is something is going wrong with either the image file you have downloaded or the writing to the SDcard... Grt,

Hi there, appreciate you answering! I downloaded via the browser and manually ran xz -d Armbian_24.8.1_Helios64_bookworm_current_6.6.47_minimal.img.xz I then ran the dd command using the resulting .img file. However, diskutil does not show a partition called ambi_root. Relevant part of diskutil list: /dev/disk4 (external, physical): #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *31.3 GB disk4 1: Linux 31.0 GB disk4s1 (free space) 325.1 MB - Not sure if this points to something being out of order. Also, I should mention I tried USBImager but it will not even start as macOS says it is "damaged". The balena Etcher is not recommended according to the Armbian documentation. On that documentation page I saw that they recommend specific microSD cards. Comparing with the ones I bought I think I may need to buy one that is actually recommended. Even if it's not the cause of the issues, I saw somewhere that the wrong SD card can be a headache in the long run. As for the drives, I had a full stack of 5 drives in my main Helios, and 4 non-configured ones in the spare Helios (was just using it as cold storage really). I transported the spare Helios without any drives to my place now and verified that the behavior remains the same. So, in short: same behavior with and empty, full, and 4/5 Helios.

Hi there, Some things you might want to check or confirm: I would expect that your OS would detect a new disk with one partition called armbi_root. Are you confident that you have used the correct image? If you are using wget to download an image from the main site's download area (https://www.armbian.com/helios64/) https://dl.armbian.com/helios64/Bookworm_current_minimal, do note that this will download Bookworm_current_minimal, which is actually an .xz image! You need to rename it to .xz and then unxz it to your SDcard. You cannot just dd that as that won't work. djurny@ekspiees:~/Downloads$ wget https://dl.armbian.com/helios64/Bookworm_current_minimal --2025-06-01 08:12:51-- https://dl.armbian.com/helios64/Bookworm_current_minimal Resolving dl.armbian.com (dl.armbian.com)... 152.53.81.238 Connecting to dl.armbian.com (dl.armbian.com)|152.53.81.238|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://armbian.chi.auroradev.org/dl/helios64/archive/Armbian_24.11.1_Helios64_bookworm_current_6.6.62_minimal.img.xz [following] --2025-06-01 08:12:52-- https://armbian.chi.auroradev.org/dl/helios64/archive/Armbian_24.11.1_Helios64_bookworm_current_6.6.62_minimal.img.xz Resolving armbian.chi.auroradev.org (armbian.chi.auroradev.org)... 23.186.112.5, 2602:fc41::5 Connecting to armbian.chi.auroradev.org (armbian.chi.auroradev.org)|23.186.112.5|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 251530384 (240M) [application/x-xz] Saving to: 'Bookworm_current_minimal' Bookworm_current_minimal 100%[==========================================================================>] 239.88M 24.2MB/s in 10s 2025-06-01 08:13:02 (23.6 MB/s) - 'Bookworm_current_minimal' saved [251530384/251530384] djurny@ekspiees:~/Downloads$ ls -l Bookworm_current_minimal -rw-rw-r-- 1 djurny djurny 251530384 Nov 24 2024 Bookworm_current_minimal djurny@ekspiees:~/Downloads$ file Bookworm_current_minimal Bookworm_current_minimal: XZ compressed data, checksum CRC64 djurny@ekspiees:~/Downloads$ Are you running any disks in your Helios64? When I was testing/playing around with my Helios64 and rebooting a lot, I decided to take out some disks to prevent them from being stopped/started all the time. This led to random stalls in the OS reaching console login. After reinserting all disks this went away. Also, just to be clear where I'm coming from: I'm also still running Buster (5.9.13-rockchip64 #trunk.16) on my Helios64. Did not yet spend any time to go for Bookworm fully. Groetjes,

my current timezone is PST (suppose to be PH starndard time) configured via raspi-config, im guessing it is confusing itself with PST (Pacific standard time US). it really messing with my TZ. For my part the only workaround is to set it manually before i can upgrade the system $ TZ=':UTC'; export TZ

Quick preface: I'm a noob in many ways, though I'm trying to learn. I may make obvious mistakes and may need clearer instructions than most. Would really appreciate someone working with me here! So I realized earlier this year that I was still on Buster and that there were two newer OSs that I could upgrade to. I upgraded to Bullseye with support from ChatGPT which worked nicely. The upgrade to Bookworm hosed my system and it now fails to reboot. System Info (prior to failure): - Helios64 board - Armbian with OMV - Originally running Buster, then upgraded in sequence: first to Bullseye (worked fine), then to Bookworm - System was always booted from an SD card, not eMMC - Upgrade was done via `apt` commands, no manual flashing of U-Boot Current Symptoms: - After Bookworm upgrade, the system fails to boot. - Via USB-C serial connection (using `screen`), I get mostly garbled output like: �`���x�f������������f�������f��~�怘����怘� Or: ZZ���B>��^�������������N��f�&F�goFFWFWGGG�oo{{q�{{{{z{{����_G_�#g�_WN�o.���wgG�WwwwWw�NWN�W�_ow_fW�Wo�v�oNogoWffOgFGFONNfFOW^Wf_G�~gg� - Occasionally, I saw more verbose output including: SetTTY (fd 5): ioctl failed: Invalid argument Sorry, could not find a PTY - No SSH access; connection refused (network stack never comes up). - The fans spin up for a few seconds and the Ethernet LED blinks briefly, then stalls. What I've Tried: - Reflashed several SD cards (Verbatim Premium and Sandisk Extreme Pro) with the latest Armbian Bookworm images (Minimal, OMV, and Noble). - I still have my old SD card that was Buster and got upgraded to Bullseye and then Bookworm, also made a backup image of it. - Repeated all tests on my second, so-far unused Helios64 — same symptoms. - Changed power cables and tried both UPS and direct plugging to wall socket. - Verified serial setup with `screen /dev/tty.usbserial 1500000`. SD Card Behavior: - After flashing via `dd`, macOS warns “Cannot initialize disk” — I believe this is expected. - On insertion and power-up: usually fans spin and LEDs blink, but no consistent or successful boot. Desired Outcome: - I'd like to use Bookworm on Helios 64. If not possible, then I'd like to use Bullseye I guess, but I wasn't able to find an image online. Only Bookworm, Jammy, and Noble. - I'm aware of firmware and DTB tweaks recommended on here to make Bookworm stable — but I can’t try these yet because I never reach a usable system. Questions: 1. Is there any place where I can download an official or community-maintained Bullseye image for Helios64? Should I even try to use Bullseye? 2. Is the serial output I’m seeing a sign of a bootloader issue (U-Boot or DDR init)? 3. Can the Bookworm image be made to boot reliably with certain tweaks *before* boot (e.g. editing partitions manually)? ChatGPT suggested to boot the system without eMMC and this is certainly territory where I don't trust AI anymore. I think I need to try fixing the server with help from you and understanding the process myself. Since my main Helios64 is offsite, I took my second Helios64 home with me until I figure out what the issue is and I'm able to boot it up and get it running. Then I'll hopefully be able to fix my offsite machine during one of my visits there. I should also say that it would occasionally get "stuck" on a reboot attempt and I needed to physically turn it off and an again to boot successfully. This never happened twice in a row, i.e. the manual reboot always fixed it. Regular reboots worked with roughly a 80-90% success rate but it didn't have to reboot very often at all. Still, this makes me believe that maaaybe there is some hardware issue present. Then again, the second Helios experiencing the same issues makes this more unlikely I suppose.

CRDA is deprecated, not needed since Linux 4.15, hence the package removed with Debian Bookworm. Problem is the default regulatory database on Debian works with Debian kernel only, not with Armbian kernel. But wireless-regdb provides the upstream database as well, so you only need to switch: sudo update-alternatives --set regulatory.db /lib/firmware/regulatory.db-upstream

You could try to create chromium.conf yourself. Here's what I have here: cat /etc/armbian/chromium.conf # Default settings for chromium-browser. This file is sourced by /bin/sh from # /usr/bin/chromium-browser # Options to pass to chromium-browser CHROMIUM_FLAGS="--disable-smooth-scrolling \ --disable-low-res-tiling \ --enable-low-end-device-mode \ --num-raster-threads=$(grep -c processor /proc/cpuinfo) \ --profiler-timing=0 \ --disable-composited-antialiasing \ --disk-cache-dir=/tmp/${USER}-cache \ --disk-cache-size=$(findmnt --target /tmp -n -o AVAIL -b | awk '{printf ("%0.0f",$1*0.3); }') \ --no-sandbox \ --test-type"

Armbian already is! uname -a Linux orangepi5-plus 6.15.0-edge-rockchip64 #1 SMP PREEMPT Sun May 25 23:09:23 UTC 2025 aarch64 GNU/Linux Itś on edge, but it's working fine here, apart from the analog audio...

Its 64bit, but support quality (tl;dr;) of Allwinner is behind Rockchip.

Created another standalone version of script for this ... https://gist.github.com/avatar21/e0deca347665bd620d0ea3f9f299028e I believe we need to compile our own armbian/ Kernel 6.13 (or above? because as @elvis claimed user driver is only 1/2 of the equation) before running this script ya? all copy/ flatten to a temp/fake root folder (where I understand the chroot sdcard means, build to a fakeroot not patching existing OS) and repackage as an img file ya? Or better still, can someone compile the whole thing? start from burning image ...

That RK356x would not be much faster than the H618 I think and "sunxi kernel" is 32-bit, I assume you use and mean 64-bit. DKMS always needs attention (in my experience), so I am happy I made/have my computers/boards such that I do not need it. actually, this topic made me do: apt purge dkms -y, as last week dist-upgrade from Bookworm to Trixie/Testing also had some issue (only a warning, not fatal) regarding DKMS. In the past I used it for some SDR hardware module, but for WiFi USB dongles I simply have a red line: If no mainline kernel integrated code, I do not use is. Also what Igor points to, that stick you have is just very low wireless performance. Use RJ45 or buy good WiFi module I would say. zfs-dkms has no hardware/vendor origin, so that is less of a problem, but note that for cheap low end SBC hardware, Btrfs also works fine and is in the Linux kernel so no special care needed. Also works fine on old ARMv6 Raspberry Pi0/1 including Zstd on-the-fly compression etc. You could create an 2-parttiton image (and U-Boot blob will be between partition table and 1st partition). Use Btrfs as rootfs and also install vanilla Debian kernel and GRUB EFI. Tag 1st as 0xEF00 (ESP) type. Then that image can run as Virtual Machine (hardware accelerated) on all ARM64 SoCs and also emulated on fast x86-64 PCs. Run armbian build inside that VM. I did that for 32-bit Allwinner as I have NanoPi-NEOs, don't have 64-bit Allwinner SoCs. So then easier experiementing and developing and you also have kernel log via virtual tty. Still make sure you have real serial cable/console for that H618.

Thanks for your help, and I found the official image not support NPU, only Joshua-Riek image support? @Hqnicolas root@h96-tvbox-3566:~# ls /dev/dri/ by-path card0 card1 renderD128

During the first few boots on my Orange Pi Zero 3 1GB, RAM size seemed to be detected correctly. Yesterday I saw RAM size being reported as 2GB, also after a reboot. As soon as the fixed U-Boot is available to install I am happy to provide test results or other test procedures when needed!

Glade to see you back @sicxnull. Thanks for the shoutout! Tried my best while you were gone. I don’t own one of these boxes. But I guess it doesn’t matter which one I get because theirs so many variations of the same box.

@Igor I have been using uboot V2025.04(2025-snuxi) on orangepi zero2w since 19 April and everything is works as it should no problems. https://github.com/ZjemCiKolege/build/commit/b3eaeb7d2059c3429951da7e6022c9528237c0e7

And I have ruled out that this is Armbian OS problem.

I try your prebuild image, and no luck with wifi/Bluetooth. My tv box new revision and have YC8800D wifi chip. Can i do something to get work WiFi?

Thanks for this!