Active threads

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

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,

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

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!

Rockchip devices generally cannot be bricked. Short the maskrom pin i showed you and reflash. You can build the image from source or from here https://github.com/armbian/community/releases

I have T95Z Plus w/ H618 and my TV box new revision. It has another wifi chip YC8800D. tried to run this build https://github.com/LYU4662/t95zplus-h618-build It work fine but no wifi and Bluetooth. Looks like it made already with 8800 driver, but system does recognize any wireless interfaces. Also try to run community build Armbian-unofficial_25.05.0-trunk_Vontar-h618_bookworm_edge_6.12.11_server Its running good, but still no wifi and Bluetooth. In android /vendor/lib/modules found attached modules. Can i use them to get work wifi? aic8800_bsp.ko aic8800_btlpm.ko aic8800_fdrv.ko

Try looking for hints here: https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/rockchip/ They use mali blobs for hw en-/decoding.

seems like the config should be distinguishing by models, not by .. idk even what it is. let say config->OrangePi2->hardware->peripherals->i2c->i2's enumerate.

All the kernel panic options that you have shown here occur on v6.12.23. It all happens randomly. I suspect that this may be due to the presence of broken (faulty) blocks on the memory device. It's easy to check this.If you connect the SD card via an adapter to a Linux computer: sudo fsck.ext4 /dev/sdX1

does anyone know how to get maskrom and uart on this rk3228a board from mxq pro 4k 5G since pushing the little button shows up as armlogic devices on device manager but the actual chip is rockchip and sorry for bad quality images

Seems it is an option for timer resolution in the measurement of duration. But the topic is about CPU usage precision returned by getrusage function. it is hardcoded interval of time when kernel updates CPU usage of particular thread/process.

All Armbian board configurations files live in build/config/board/ Besides the Pcduino2 Cubieboard and OlinuXino-lime board, I don't know what other A10 boards still have some level of support. After that the next step would probably be to confirm that it works with uboot. Here you have another config file and dts. For any tweaks to uboot you will need to pass uboot-patch when running compile.sh. Note that when you do this you will need to open a new tab and navigate to cache/sources/u-boot-worktree/ Similiarly for the kernel you would navigate to cache/sources/kernel/ currently 6.12 is "current" while 6.14 is "edge" Hope this helps Ryzer

For production, boxes are much more interesting than boards. We just need to deal with a honest manufacturer. The last dtb from @mmie4jbcu worked very well for me in a x88 pro 20.

That solves it thank you very much for your time! If I want to change between boards like Rockpro64, Raspberry Pi4, etc. is there anything that needs to be considered as far as "reset" to a fresh state. For the guide I am writing I would like to make sure there is no lingering configuration that could cause problems when switching between builds for different boards.

All things being equal....... steve@fedora43:~$ uname -a Linux fedora43 6.16.0-0.rc0.250528gfeacb1774bd5.5.fc43.aarch64 #1 SMP PREEMPT_DYNAMIC Wed May 28 19:45:02 UTC 2025 aarch64 GNU/Linux kernel-6.16.0-0.rc0.250529g90b83efa6701.6.fc43. created by jforbes 6 hours ago for Fedora 43 .

Hello. I wonder if this issue is connected to my issue - to show something on i2c, while there is nothing, and not be able to communicate on it ?