Active threads

Thanks! Just run upgrade to 6.12.30 - and sounds works! (on 6.12.20 was no sound card in aplay -l )

I set up an Ubuntu VM on my Mac to do linux stuff. With that I edited the ambianEnv.txt as you said. Behavior is the same. I should also add that there is a regular double-blink of the System LED after the initial fans (of about 2-3 seconds). I now remember that back when I set up the Helios, I was told to use PuTTY on Windows instead of my mac. Maybe there's an incompatibility of some sort? I checked and they recommend a set of drivers for Mac that I hadn't installed. I did and after playing around -- and only occasionally while playing around with connecting, disconnecting, rebooting -- did I sometimes get some garbled output in the serial window: posting it because it's the longest and least garbled output I've gotten so far. The command was exactly as on the Helios64 website, i.e. the baud rate was correct. Not sure where to go from here and what to blame.

Replying to my own again...UEFI doesn't seem to boot from SD if you don't modify the HW, it does boot from the internal MMC, though! All you need to do is flash the EDK2/UEFI bios (1.1 at the point of writing) to the internal MMC and then fix the GPT (I just run GParted or KDE Partition Manager - that asks you a couple of questions and fixes the parition table). After that you can just run the e.g. Fedora Rawhide ARM64 iso and install to the same SD (just have the installer "add the OS"). After that you can boot from USB, SD, NVME and even a SATA with a m2 sata adapter.

Replying to my own post. ... EDK2 has an UEFI BIOS which runs mainline linux - no custom builds. It supports ACPI and device tree. I run this now with Fedora Rawhide 43 with KDE (6.4 Beta) which runs ACPI out of the box, older kernels work with device tree. I haven't used the latest mainline Armbian but that should work, too (at least the latest mainline image). Rawhide runs mainline kernel 6.15/6.16 (latest build) which supports the SOC + GPU out of the box.

Testing the M2 16G with trunk 90 (Kernel 61.15) & trunk 38 (Kern 6.14.8) and the USB-C OTG port isn't working. [ +0.245948] usb 7-1: new full-speed USB device number 2 using xhci-hcd [ +0.124258] usb 7-1: device descriptor read/64, error -71 [ +0.227984] usb 7-1: device descriptor read/64, error -71 [ +0.223715] usb 7-1: new full-speed USB device number 3 using xhci-hcd [ +0.124295] usb 7-1: device descriptor read/64, error -71 [ +0.223803] usb 7-1: device descriptor read/64, error -71 [ +0.104107] usb usb7-port1: attempt power cycle [ +0.395844] usb 7-1: new full-speed USB device number 4 using xhci-hcd [ +0.000112] usb 7-1: Device not responding to setup address. [ +0.203891] usb 7-1: Device not responding to setup address. [ +0.203946] usb 7-1: device not accepting address 4, error -71 [ +0.000609] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.119353] usb 7-1: new full-speed USB device number 5 using xhci-hcd [ +0.000118] usb 7-1: Device not responding to setup address. [ +0.204373] usb 7-1: Device not responding to setup address. [ +0.207473] usb 7-1: device not accepting address 5, error -71 [ +0.000613] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.000109] usb usb7-port1: unable to enumerate USB device [ +30.217458] usb 7-1: new full-speed USB device number 6 using xhci-hcd [ +0.123993] usb 7-1: device descriptor read/64, error -71 [ +0.231951] usb 7-1: device descriptor read/64, error -71 [ +0.223935] usb 7-1: new full-speed USB device number 7 using xhci-hcd [ +0.120028] usb 7-1: device descriptor read/64, error -71 [ +0.224108] usb 7-1: device descriptor read/64, error -71 [ +0.103939] usb usb7-port1: attempt power cycle [ +0.396008] usb 7-1: new full-speed USB device number 8 using xhci-hcd [ +0.000139] usb 7-1: Device not responding to setup address. [ +0.203807] usb 7-1: Device not responding to setup address. [ +0.207853] usb 7-1: device not accepting address 8, error -71 [ +0.000608] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.119394] usb 7-1: new full-speed USB device number 9 using xhci-hcd [ +0.000140] usb 7-1: Device not responding to setup address. [ +0.204031] usb 7-1: Device not responding to setup address. [ +0.203926] usb 7-1: device not accepting address 9, error -71 [ +0.000796] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.000293] usb usb7-port1: unable to enumerate USB device [Jun 2 19:50] usb 7-1: new full-speed USB device number 10 using xhci-hcd [ +0.123926] usb 7-1: device descriptor read/64, error -71 [ +0.116517] xhci-hcd xhci-hcd.7.auto: remove, state 4 [ +0.000011] usb usb8: USB disconnect, device number 1 [ +0.000280] xhci-hcd xhci-hcd.7.auto: USB bus 8 deregistered [ +0.000009] xhci-hcd xhci-hcd.7.auto: remove, state 1 [ +0.000004] usb usb7: USB disconnect, device number 1 [ +0.055430] usb usb7-port1: attempt power cycle Same USB-C device (CCD camera) tested and working in the USB-3 port.

First of all, I would like to thank the developers for making this possible. I have two MXQs, one with OMV and the other running raspotify with a DAC. Thank you very much, it was a great addition to my homelab. I noticed that docker container support for armhf has been discontinued over time. Does anyone have a list of docker images for armhf?

The 25.5.1 kernels seem to have landed in the APT repos. I can confirm that at least the `current` kernel now has networking working as intended. I haven't checked the legacy kernel whether it works enough for a semi reasonable upgrade path. But I'll see that once I get to upgrade the other CB1 boards I have.

I haven't tested these functions, I don't know if it works or not. https://docs.armbian.com/User-Guide_Getting-Started/#first-login

@Werner NVME, sorry...

https://docs.armbian.com/User-Guide_Board-Support-Rules/ support a whole soc family would be impossible. For example a vendor could do a poor implementation of something which could never work but we "support" it and people complain why it doesn't but there would be literally nothing we could do about.

Upgrade to 25.5.1 successful (straight-forward).

https://askubuntu.com/questions/1371732/what-is-the-purpose-of-cgroup-enable-cpuset-cgroup-enable-memory-cgroup-memory-1 Without further research the answer here mentions that the flags in question may be specific for RaspberryPi, hence won't work on other kernels/boards.

All images are specifically made for the board. Some share the same kernel package since they are from the same soc family (for example, there are a lot of boards using the rk3588/s soc so they can have the same kernel package. Board's components are defined in device tree). Sample board config: https://github.com/armbian/build/blob/main/config/boards/orangepi5pro.csc BOARD_FAMILY is rockchip-r3588 The sources config: https://github.com/armbian/build/blob/main/config/sources/families/rockchip-rk3588.conf Pro, max and ultra are community contributions and for now entirely unsupported since there is also no support from the vendor for us for these whatsoever to make its software better.

Right to clarify what I described earlier was the patch creation process, where you would modify an existing file or if the file does not exist you would create in the relevant. After running for a bit the build process will pause. At this point you would need to open a new tab and navigate to cache/sources/linux-kernel-worktree/6.12__sunxi__armhf/arch/arm/boot/dts/allwinner. Here you would need to amend the sun4i-a10-topwise-a721.dts. According to the dts it already has the panel node so the on board display should at least work unless the driver is broken or device tree bindings have changed. Unfortunately I havent worked with panels so cannot provide much further assistance for other than confirming that an entry exist in the simple panel driver. sudo modinfo panel-simple | grep starry [sudo] password for ryan: alias: of:N*T*Cstarry,kr070pe2tC* alias: of:N*T*Cstarry,kr070pe2t ryan@pcduino2-1:~$ Normally to get hdmi to work you simply have to enable the hdmi nodes plus create a hdmi connector node. I have attached the patch that I use on my pcduino2, applying the same alterations to the dts of the topwise's dts should work. I have had issues with hdmi display in 6.12 which I found a work around for but not perfect as we have to modify the hdmi driver. From What I can tell the problem is related to atomic check function: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241130-hdmi-mode-valid-v5-10-742644ec3b1f@linaro.org/ It may be fixed in kernel 6.14 but I havent tested it yet. save the changes in your text editor and exit. Return to the tab running the build script, hit enter and it will generate a preview of the changes and ask if you are happy with the changes or not. type 'y' to accept. Luckily the build process will helpfully walk you through these steps. Once the build process has finished go to output/patch/. and rename the newly generated patch something useful so that you remember its purpose. Then move it into patches or userpatches. Which is up to you but personally, I prefer to have my patches in userpatches unless it is something I plan to merge in future. whenever you run git pull to fetch the latest version of armbian build, the patch directory is likely to be updated whereas userpatches is not affected. A caveat with userpatches is that full directory structure is not pre-existing so you have to manually create it, mirroring the patches directory. Also note that userpatches are applied after patches in the patch directory. Did you clone Armbian build directly or are you work off your own fork? Now what i tend to do is rerun the build process to check that the patch was applied successful. So rerun ./compile.sh BOARD=topwise-A721 (Replace with the name used in your config file) BRANCH=current RELEASE=bookworm kernel-patch. if successful it should appear in the list of patches and if applied under usepatches it will helpful be the last entry on the list. Unless you have any further patches to apply you can then go on to running a full build. I am suprised no one has yet done a video on the patching process yet Have you attempted disassembling the tablet to check for any solder pads present which could be the serial console? If there is then it may be possible to hook up a usb to serial converter. This could at least be a solid indicator to confirm that the device is at least booting. best of luck Ryzer pcduino2-hdmi-enable.patch

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.

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

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...

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 ... Correct me if I’m wrong…

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.

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!