y52

Hello to regular contributors and everybody who are interested in this issue! I am late to the thread, as I had to decommission my production setup based on Espressobin V5 before trying everything out. Finally I've completed Physical-to-Virtual migration using QEMU and made board available for this new experience. @bschnei made a great job and his developments are community available. It was also worth for me making my findings accessible for general public thus improving Espressobin support. I forked @bschnei repo https://github.com/bschnei/ebu-bootloader to my Github https://github.com/quiseleve/espressobin-bootloader and made several changes to build bootloaders for Espressobin V5 and V7. Here are the final changes brought to @bschnei repo : root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git remote add upstream https://github.com/bschnei/ebu-bootloader.git root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git fetch upstream From https://github.com/bschnei/ebu-bootloader * [new branch] main -> upstream/main root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git diff --stat upstream/main...main .github/workflows/build.yml | 92 ++++++++++++++++++++++++++++++++++++++++++--------------------------------- Makefile | 2 ++ patches/0001-fix-tfa-fip-build-behavior.patch | 36 +++++++++++++++++++++++++++++ 3 files changed, 90 insertions(+), 40 deletions(-) This allowed building bootload firmware directly in Github's Workflow and trying them out over UART 1st before flashing it to onboard SPi. ./mox-imager -D /dev/ttyUSB0 -b 3000000 -E flash-image-v5_2GB.CPU_1000_DDR_800.bin Although Workflow run builds both v5 and v7 variants, I tested 2Gb RAM v5 board, as my 1Gb v7 is currently in production, but there is a high confidence level, that v7 works as well. DDR_TOPOLOGY variable used for my specific v5 motherboard : Memory Type: DDR3 Total Capacity: 2 GB Bus Width: 16-bit Chip Selects (CS): 2 (Dual CS) It is worth saying that I built initially the 1.2GHz bootloader, but it appeared worthless, as my physical silicon turned out to be limited to 1GHz only. I found it by retrieving a 32-bit hex string for v5 board : => md 0xd0012604 1 d0012604: 19896301 .c.. => This hex string gives us the definitive answers we need. In the Marvell Armada 3720 architecture, this specific register reads from the factory OTP (One-Time Programmable) fuses. The lower bits define the chip's official Speed Bin Index: 0 = 800 MHz Maximum 1 = 1000 MHz (1.0 GHz) Maximum 2 = 1200 MHz (1.2 GHz) Maximum Because my board register ends in 01, my specific SoC is officially rated by the factory for a maximum clock speed of 1000 MHz (1.0 GHz). This completely explains why the WTMI secure firmware threw the invalid voltage error when I forced a 1.2 GHz build. The chip physically lacks the factory-fused voltage calibration profile for the 1.2 GHz tier because it wasn't born as a 1.2 GHz chip. Thus I decided changing the Build Target to 1.0 GHz. More discussions could be found here as well : I've also built Armbian-unofficial 26.5.2 sid image to assess overall compatibility. Here is an excerpt from initial boot logs directly from the bootloader initiation : TIM-1.0 mv_ddr-devel-g7bcb9dc DDR3 16b 2GB 2CS WTMI-devel-18.12.1-f423ac6 WTMI: system early-init SVC REV: 3, CPU VDD voltage: 1.155V Setting clocks: CPU 1000 MHz, DDR 800 MHz CZ.NIC's Armada 3720 Secure Firmware v2024.04.15 (Jul 9 2026 20:33:31) Running on ESPRESSObin NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.14.0(release):sandbox/v2.14 NOTICE: BL1: Built : 20:33:33, Jul 9 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.14.0(release):sandbox/v2.14 NOTICE: BL2: Built : 20:33:35, Jul 9 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.14.0(release):sandbox/v2.14 NOTICE: BL31: Built : 20:33:36, Jul 9 2026 U-Boot 2026.04-dirty (Jul 09 2026 - 20:32:03 +0000) DRAM: 2 GiB Core: 48 devices, 24 uclasses, devicetree: separate WDT: Not starting watchdog@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIe: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: ethernet@30000 Hit any key to stop autoboot: 0 MMC Device 1 not found no mmc device at slot 1 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 1664 bytes read in 25 ms (64.5 KiB/s) ## Executing script at 06d00000 144 bytes read in 19 ms (6.8 KiB/s) 28134196 bytes read in 1702 ms (15.8 MiB/s) Wrong Image Type for bootm command ERROR -91: can't get kernel image! 37059072 bytes read in 2231 ms (15.8 MiB/s) 18537158 bytes read in 1121 ms (15.8 MiB/s) 12062 bytes read in 35 ms (335.9 KiB/s) ## Loading init Ramdisk from Legacy Image at 0a000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 18537094 Bytes = 17.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 Working FDT set to 6f00000 Loading Ramdisk to 7d940000, end 7eaeda86 ... OK Loading Device Tree to 000000007d93a000, end 000000007d93ff1d ... OK Working FDT set to 7d93a000 Starting kernel ... Loading, please wait... Starting systemd-udevd version 261.1-2 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.42.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 armbi_root: clean, 28918/949664 files, 425190/3849216 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Armbian-unofficial 26.5.2 sid! [ OK ] Created slice system-getty.slice - Slice /system/getty. [ OK ] Created slice system-modprobe.slice - Slice /system/modprobe. [ OK ] Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty. [ OK ] Created slice user.slice - User and Session Slice. [ OK ] Started systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch. [ OK ] Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch. [ OK ] Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point. Expecting device dev-ttyMV0.device - /dev/ttyMV0... [ OK ] Reached target imports.target - Image Downloads. [ OK ] Reached target remote-fs.target - Remote File Systems. [ OK ] Reached target slices.target - Slice Units. [ OK ] Reached target swap.target - Swaps. [ OK ] Listening on syslog.socket - Syslog Socket. [ OK ] Listening on systemd-ask-password.socket - Query the User Interactively for a Password. [ OK ] Listening on systemd-creds.socket - Credential Encryption/Decryption. [ OK ] Listening on systemd-factory-reset.socket - Factory Reset Management. [ OK ] Listening on systemd-hostnamed.socket - Hostname Service Socket. -- Boot 3e598d120dc346829e12f836344429a1 -- Jul 11 00:11:05 espressobin kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034] Jul 11 00:11:05 espressobin kernel: Linux version 6.12.95-current-mvebu64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0> Jul 11 00:11:05 espressobin kernel: 5:185m5:185mKASLR disabled due to lack of seed Jul 11 00:11:05 espressobin kernel: Machine model: Globalscale Marvell ESPRESSOBin Board Jul 11 00:11:05 espressobin kernel: efi: UEFI not found. .. Jul 11 00:11:05 espressobin kernel: armada_37xx_wdt d0008300.watchdog: Initial timeout 120 sec Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: host bridge /soc/pcie@d0070000 ranges: Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: MEM 0x00e8000000..0x00efefffff -> 0x00e8000000 Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: IO 0x00efff0000..0x00efffffff -> 0x0000000000 Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: issuing PERST via reset GPIO for 10ms Jul 11 00:11:05 espressobin kernel: mvneta d0030000.ethernet end0: renamed from eth0 .... This bootloader seems to deliver many if not all of its promises to name few of them: cpu frequency scaling is operational : root@espressobin:~# cpupower frequency-info analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 1000 us hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative ondemand userspace powersave performance schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: 250 MHz (asserted by call to kernel) Entropy and random number generation (RNG) issue seems to have been resolved as bschnei's ebu-bootloader fork explicitly includes patches to fix this. The ebu-bootloader patches bypass the OS entirely and tackle the problem before Linux even starts. When Linux kernel boots, it immediately detects this perfect cryptographic seed provided by U-Boot and uses it to instantly initialize the OS-level Cryptographic Random Number Generator (CRNG). Here are my kernel ring buffer timestamps: root@espressobin:~# dmesg | grep -E "crng|random" [ 11.785705] systemd[1]: Starting systemd-random-seed.service - Load/Save OS Random Seed... [ 13.071384] random: crng init done [ 13.398576] systemd[1]: Finished systemd-random-seed.service - Load/Save OS Random Seed. The bootloader and kernel working together fixed the entropy pool in exactly 13.07 seconds from the moment the Linux kernel started executing. Because crng init done happened before the systemd service even finished writing to the disk, it proves the kernel didn't just rely on slow user-space disk jitter. The hardware security engine initialized almost immediately. Because the ebu-bootloader fork compiled correctly patches, the underlying Trusted Firmware-A (TF-A) and the secure processor (WTMI-devel), the hardware crypto mailboxes are wide open and working perfectly the moment Linux asks for them. You don't even need haveged or any software workarounds. Your hardware is resolving its own entropy natively in just over a second from user-space initialization! U-Boot UEFI Support is out of the box as well. I am booting seemlessly both legacy OS (from my old production setup) as well as a new OS build which I used for this testbed root@espressobin:~# cat /etc/debian_version forky/sid root@espressobin:~# uname -a Linux espressobinv5 6.12.95-current-mvebu64 #1 SMP PREEMPT Sat Jul 4 11:43:36 UTC 2026 aarch64 GNU/Linux

It sounds very promising for Espressobin usage and further kernels upgrades. It is yet to discover how could your u-boot port be built and which changes to code should be made for espressobin v5 and v7. I believe, they use the same chip. As you have a working build environment already, it would be worth sharing your pre-built binaries for testing in the 1st run. It could be a big step forward. Probably Armbian could offer them for downloads as well as alternatives in parallel with their own builds.

I've recently encountered when generating rsa keys low entropy available to OS on espressobin. You mention that "The hardware random number generator contained in the Cortex-M3 coprocessor was not available to the OS." It may explain the reason. Which entropy numbers do you reach now with the fixed u-boot ?

I believe you have managed to overcome the majour Espressobin culprits, i.e. frequency scaling resulting in instability. It was a deadlock for me in the kernel choice and uboot frequency build version. At some moment I was compelled flashing uboot with frequency downgraded to 1GHz and 800 MHz in order to get stable setup for production. Good catch! Your use of Arch Linux is also interesting. Which flavor have you installed ? Is it from https://archlinuxarm.org/platforms/armv8/marvell/espressobin ? I routinely out of curiosity try alternative builds for testing and comparison when making new setups despite that Armbian remains a preferred one so far with general score of usability.

Hi! Thanks for mentioning me. I've just noticed your message accidentally. It is indeed an interesting u-boot development. My both ESPRESSObin V5 and V7 are in production now. I can make some testing once I program their replacement. But no schedule has been fixed as yet pending acquiring a new board.

I am trying building image natively on orangepiplus, but the scripts are not designed to complete it. System incompatibility, lack of packages for this distribution etc make it fail. How do you manage building it with this Armbian's official building tool ? I am very curious to discover the right approach as I need adding in-kernel modules, which you can't build as stand alone. At the same time, where can u-boot be downloaded from? I understand, that it was updated in 2024 : [🌿] {u-boot:1} Preparing u-boot targets packaging [ 2024.01 ] [🌿] {u-boot:1} Deploying u-boot binary target [ 2024.01 :: u-boot-sunxi-with-spl.bin ]

When tweaking Armbian’s Build System I understand that it also builds u-boot and updates it when new sources are available. I understand, that the last one was updated on : [🌿] {u-boot:1} Cleaning u-boot tree [ u-boot-worktree/u-boot/v2024.01 for '' ] [🔨] [Mon Aug 25 11:11:25 PM CEST 2025] Running: git --no-pager clean -xfdq [🌱] Calling Python patching script for U-Boot: [ https://github.com/u-boot/u-boot - tag:v2024.01 ] [🌱] Using U-Boot patch dir: [ u-boot-sunxi ] Where is the latest build could be downloaded from and what is its flash procedure and recovery (if necessary) ?

I've now exhausted all practical options. I guess that the 6.15.4-edge-sunxi kernel was built with GCC plugins and BTF settings that cannot be reproduced with out-of-tree module builds. Even using the cross-compiler (arm-linux-gnueabihf-gcc-13) did not help — because the issue is not the compiler binary, but the entire build environment: CONFIG_DEBUG_INFO_BTF_MODULES=y GCC_PLUGIN_RANDSTRUCT or STRUCTLEAK ftrivial-auto-var-init=zero TLS guard offset (-mstack-protector-guard-offset=1464) Kernel symbol versioning These change the binary layout of struct module, making any externally built module incompatible. The question now, how could a missing module be added to a running system ! It is almost improbable, that development path is completely blocked and requires tedious efforts for adding a simple already existing module. In the meantime, while the right approach is being looked for, could somebody point to a "pull request" procedure?

It is already loaded : root@orangepiplus:~# lsmod Module Size Used by cfg80211 618496 2 mac80211,8189es Just one more time again : root@orangepiplus:/mnt/sda2/src/rtw88# sudo modprobe cfg80211 root@orangepiplus:/mnt/sda2/src/rtw88# sudo modprobe rtw_8821au modprobe: ERROR: could not insert 'rtw_8821au': Exec format error root@orangepiplus:/mnt/sda2/src/rtw88# sudo modprobe rtw_core modprobe: ERROR: could not insert 'rtw_core': Exec format error

It has been tried several times with similar results : On stable 6.12.35 The lwfinger/rtl8821au driver causes kernel exceptions (oops/panics) It doesn't survive simple lsmod. On kernel 6.15.4 : It fails inserting : root@orangepiplus:~# sudo cp /var/lib/dkms/rtw88/0.6/build/*.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/rtw88/ root@orangepiplus:~# ls -al /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/rtw88 total 23744 drwxr-xr-x 2 root root 4096 Aug 24 15:13 . drwxr-xr-x 6 root root 4096 Aug 21 21:02 .. -rw-r--r-- 1 root root 961676 Aug 24 15:13 rtw_8703b.ko -rw-r--r-- 1 root root 415924 Aug 24 15:13 rtw_8723cs.ko -rw-r--r-- 1 root root 991580 Aug 24 15:13 rtw_8723d.ko -rw-r--r-- 1 root root 416088 Aug 24 15:13 rtw_8723ds.ko -rw-r--r-- 1 root root 419968 Aug 24 15:13 rtw_8723du.ko -rw-r--r-- 1 root root 492256 Aug 24 15:13 rtw_8723x.ko -rw-r--r-- 1 root root 929420 Aug 24 15:13 rtw_8812a.ko -rw-r--r-- 1 root root 424112 Aug 24 15:13 rtw_8812au.ko -rw-r--r-- 1 root root 1271964 Aug 24 15:13 rtw_8814a.ko -rw-r--r-- 1 root root 420676 Aug 24 15:13 rtw_8814au.ko -rw-r--r-- 1 root root 900128 Aug 24 15:13 rtw_8821a.ko -rw-r--r-- 1 root root 422752 Aug 24 15:13 rtw_8821au.ko -rw-r--r-- 1 root root 1025348 Aug 24 15:13 rtw_8821c.ko -rw-r--r-- 1 root root 415504 Aug 24 15:13 rtw_8821cs.ko -rw-r--r-- 1 root root 421624 Aug 24 15:13 rtw_8821cu.ko -rw-r--r-- 1 root root 1217480 Aug 24 15:13 rtw_8822b.ko -rw-r--r-- 1 root root 415504 Aug 24 15:13 rtw_8822bs.ko -rw-r--r-- 1 root root 425156 Aug 24 15:13 rtw_8822bu.ko -rw-r--r-- 1 root root 1734256 Aug 24 15:13 rtw_8822c.ko -rw-r--r-- 1 root root 415504 Aug 24 15:13 rtw_8822cs.ko -rw-r--r-- 1 root root 420196 Aug 24 15:13 rtw_8822cu.ko -rw-r--r-- 1 root root 666896 Aug 24 15:13 rtw_88xxa.ko -rw-r--r-- 1 root root 7900876 Aug 24 15:13 rtw_core.ko -rw-r--r-- 1 root root 575660 Aug 24 15:13 rtw_sdio.ko -rw-r--r-- 1 root root 560804 Aug 24 15:13 rtw_usb.ko root@orangepiplus:~# sudo depmod -a $(uname -r) root@orangepiplus:~# sudo modprobe rtw_8821au modprobe: ERROR: could not insert 'rtw_8821au': Exec format error Aug 24 15:14:25 orangepiplus kernel: module rtw_core: .gnu.linkonce.this_module section size must match the kernel's built struct module size at run time

In the meantime and in order digging further I've switched to gcc-13 to build module with the same version as the kernel : root@orangepiplus:/mnt/sda2/src/linux-6.15.4# gcc --version gcc (Debian 13.4.0-1) 13.4.0 Then I've downloaded headers with armbian-config to : /usr/src/linux-headers-6.15.4-edge-sunxi and proceeded with rebuild Using Official Headers cd /mnt/sda2/src/linux-6.15.4 make clean cp /usr/src/linux-headers-6.15.4-edge-sunxi/.config .config sed -i 's/^EXTRAVERSION =.*/EXTRAVERSION = -edge-sunxi/' Makefile make olddefconfig 787 make menuconfig 788 grep -E 'CONFIG_RTW88_CORE|CONFIG_RTLWIFI|CONFIG_RTW88_8821AU' .config make modules_prepare cp /usr/src/linux-headers-6.15.4-edge-sunxi/Module.symvers . make M=drivers/net/wireless/realtek/rtw88 modules -j$(nproc) sudo cp /boot/System.map-$(uname -r) /mnt/sda2/src/linux-6.15.4/System.map root@orangepiplus:/mnt/sda2/src/linux-6.15.4# sudo make M=drivers/net/wireless/realtek/rtw88 modules_install make[1]: Entering directory '/mnt/sda2/src/linux-6.15.4/drivers/net/wireless/realtek/rtw88' INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_core.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8822b.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8822bs.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8822bu.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8822c.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8822cs.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8822cu.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8723x.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8723d.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8723ds.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8723du.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8821c.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8821cs.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8821cu.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_88xxa.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8821a.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_8821au.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_sdio.ko INSTALL /lib/modules/6.15.4-edge-sunxi/updates/rtw88_usb.ko DEPMOD /lib/modules/6.15.4-edge-sunxi make[1]: Leaving directory '/mnt/sda2/src/linux-6.15.4/drivers/net/wireless/realtek/rtw88' sudo depmod -a But the resulting module failed loading again : root@orangepiplus:/mnt/sda2/src/linux-6.15.4# sudo modprobe rtw88_8821au modprobe: ERROR: could not insert 'rtw88_8821au': Exec format error Aug 24 12:08:53 orangepiplus kernel: module rtw88_core: .gnu.linkonce.this_module section size must match the kernel's built struct module size at run time It proves a structural mismatch again. Armbian built the 6.15.4-edge-sunxi kernel using Ubuntu's GCC 13 likely with plugins. GCC plugins randomize or instrument the layout of kernel structures — including struct module. It means, that you cannot reproduce the exact struct module layout unless you use the exact same GCC plugin configuration — which is not available to end users! Could it be fixed and what is the right approach to adding missing in-kernel modules from kernel sources or headers ?

Could your team make such a "pull request" ? Could you also drop the github link at the same time ? I shall try making it myself.

What a PR is ? Could you be more specific about your suggestion ? In fact, could this module be included into the next 6.15 EDGE build ? CONFIG_RTW88_8821AU=m I don't know if this module is indeed functional (I want to test it). As it is concurrent with Armbian supplied 88XXau for the same hardware, one of them needs to be disabled in /etc/modprobe.d/ either: # cat blacklist-88XXau.conf blacklist 88XXau or # cat blacklist-RTW88_8821AU.conf blacklist rtw88_8821au

I do agree, that it doesn't. But it looks like Armbian kernel is built with arm-linux-gnueabihf-gcc Taken unalignment problem the same flag was used with which the kernel and headers were built. It doesn't help either.

Hello everybody, I tried building an in-kernel module for USB Dongle Bus 001 Device 003: ID 2357:0120 TP-Link Archer T2U PLUS [RTL8821AU] on my OrangePi Plus. Armbian supplied module from aircrack-ng/rtl8812au has become aging and raises exception errors on modprobe -r. It was deactivated : root@orangepiplus:/etc/modprobe.d# vi blacklist-88XXau.conf #blacklist 88XXau I made a fresh install of Armbian minimal image, then switched to : root@orangepiplus:~# uname -a Linux orangepiplus 6.15.4-edge-sunxi #1 SMP Fri Jun 27 10:13:43 UTC 2025 armv7l GNU/Linux root@orangepiplus:/usr/src# cat /proc/version Linux version 6.15.4-edge-sunxi (build@armbian) (arm-linux-gnueabihf-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #1 SMP Fri Jun 27 10:13:43 UTC 2025 root@orangepiplus:/usr/src# zcat /proc/config.gz | grep CC_VERSION CONFIG_CC_VERSION_TEXT="arm-linux-gnueabihf-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0" CONFIG_GCC_VERSION=130300 root@orangepiplus:/usr/src# zcat /proc/config.gz | grep STACKPROTECTOR CONFIG_CC_HAVE_STACKPROTECTOR_TLS=y CONFIG_STACKPROTECTOR_PER_TASK=y CONFIG_HAVE_STACKPROTECTOR=y CONFIG_STACKPROTECTOR=y CONFIG_STACKPROTECTOR_STRONG=y Headers were downloaded with armbian-config : root@orangepiplus:/mnt/sda2/src/linux-6.15.4# drwxr-xr-x 25 root root 4096 Aug 21 21:40 linux-headers-6.15.4-edge-sunxi Then performed usual build process: root@orangepiplus:/usr/src# sudo git clone --depth 1 --branch linux-6.15.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git root@orangepiplus:/usr/src# sudo ln -s /usr/src/linux /lib/modules/$(uname -r)/build root@orangepiplus:/usr/src# ls -al /lib/modules/$(uname -r)/build lrwxrwxrwx 1 root root 14 Aug 21 22:45 /lib/modules/6.15.4-edge-sunxi/build -> /usr/src/linux cp /boot/config-$(uname -r) /usr/src/linux/.config sudo make olddefconfig sudo make menuconfig Module activated in the following tree : │ Symbol: RTW88 [=m] │ │ Type : tristate │ │ Defined at drivers/net/wireless/realtek/rtw88/Kconfig:2 │ │ Prompt: Realtek 802.11ac wireless chips support │ │ Depends on: NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_REALTEK [=y] && MAC80211 [=m] │ │ Location: │ │ -> Device Drivers │ │ -> Network device support (NETDEVICES [=y]) │ │ -> Wireless LAN (WLAN [=y]) │ │ -> Realtek devices (WLAN_VENDOR_REALTEK [=y]) │ │ (1) -> Realtek 802.11ac wireless chips support (RTW88 [=m]) root@orangepiplus:/usr/src/linux# grep -E 'CONFIG_RTW88_CORE|CONFIG_RTLWIFI|CONFIG_RTW88_8821AU' .config CONFIG_RTLWIFI=m CONFIG_RTLWIFI_USB=m # CONFIG_RTLWIFI_DEBUG is not set CONFIG_RTW88_CORE=m CONFIG_RTW88_8821AU=m cp /usr/src/linux-headers-6.15.4-edge-sunxi/Module.symvers /usr/src/linux/ Then compiled with: root@orangepiplus:/usr/src/linux# sudo make -j$(nproc) ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- M=drivers/net/wireless/realtek/rtw88 make[1]: Entering directory '/usr/src/linux/drivers/net/wireless/realtek/rtw88' MODPOST Module.symvers CC [M] rtw88_core.mod.o CC [M] .module-common.o CC [M] rtw88_8822b.mod.o CC [M] rtw88_8822bs.mod.o CC [M] rtw88_8822bu.mod.o CC [M] rtw88_8822c.mod.o CC [M] rtw88_8822cs.mod.o ... LD [M] rtw88_core.ko LD [M] rtw88_8822b.ko LD [M] rtw88_8822bs.ko LD [M] rtw88_8822bu.ko LD [M] rtw88_8822c.ko LD [M] rtw88_8822cs.ko LD [M] rtw88_8822cu.ko LD [M] rtw88_8723x.ko LD [M] rtw88_8723d.ko LD [M] rtw88_8723ds.ko LD [M] rtw88_8723du.ko LD [M] rtw88_8821c.ko LD [M] rtw88_8821cs.ko LD [M] rtw88_8821cu.ko LD [M] rtw88_88xxa.ko LD [M] rtw88_8821a.ko LD [M] rtw88_8821au.ko LD [M] rtw88_sdio.ko LD [M] rtw88_usb.ko make[1]: Leaving directory '/usr/src/linux/drivers/net/wireless/realtek/rtw88' root@orangepiplus:/usr/src/linux# modinfo /usr/src/linux/drivers/net/wireless/realtek/rtw88/rtw88_8821au.ko filename: /usr/src/linux/drivers/net/wireless/realtek/rtw88/rtw88_8821au.ko license: Dual BSD/GPL description: Realtek 802.11ac wireless 8821au/8811au driver author: Bitterblue Smith <rtl8821cerfe2@gmail.com> ... alias: usb:v0BDAp0811d*dc*dsc*dp*icFFiscFFipFFin* depends: rtw88_usb,rtw88_8821a name: rtw88_8821au vermagic: 6.15.11 SMP mod_unload ARMv7 thumb2 p2v8 sudo make modules_install ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- doesn't work. Needs fixing. So I just copied modules to system location : root@orangepiplus:/usr/src/linux# sudo cp /usr/src/linux/drivers/net/wireless/realtek/rtw88/*.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/rtw88/ root@orangepiplus:/usr/src/linux# sudo depmod -a But loading failed as follows : root@orangepiplus:/usr/src/linux# sudo modprobe rtw88_8821au modprobe: ERROR: could not insert 'rtw88_8821au': Exec format error Aug 22 16:31:52 orangepiplus kernel: module rtw88_88xxa: .gnu.linkonce.this_module section size must match the kernel's built struct module size at run time It appears to be a structural issue, as I also tried building out-of-kernel module from lwfinger/rtw88 I also tried building on Nanopi-r5s. Each time Exec format error was observed despite the module was successfully built. Different analysis point to GCC version mismatch between kernel and build host, ABI incompatibility and subtle build failures, thus causing non-alignment with the kernel buid. Several other build flags were tried to align with the kernel, but in vain. The root cause was not found. I am running out of options now. Could community or development team point to correct approach building an in-kernel module on a running system in native environment ? PS : complementary information : when armbian headers were downloaded with armbian-config, the following build output was observed : /usr/lib/gcc/arm-linux-gnueabihf/12/cc1 -quiet -I ./scripts/include -I ./scripts/dtc/libfdt -imultilib . -imultiarch arm-linux-gnueabihf -D _LARGEFILE_SOURCE -D _FILE_OFFSET_BITS=64 -D NO_YAML -MMD scripts/dtc/.dtc.o.d scripts/dtc/dtc.c -quiet -dumpdir scripts/dtc/ -dumpbase dtc.c -dumpbase-ext .c -mfloat-abi=hard -mtls-dialect=gnu -mthumb -mlibarch=armv7-a+fp -march=armv7-a+fp -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -std=gnu11 -fomit-frame-pointer -o /tmp/ccY6Z3QK.s It may give some clues on the flags used.