aram Posted June 7 Posted June 7 I did a apt upgrade that messed up my set up, so I have recently (as in two hours ago) reinstalled armbian on on my dragon q6a. Unlike the previous set up, I have not been able to connect to my wifi. Did a bit of a dance with AI help and still failed, but it looks like the wifi module is directly not found. nmcli device returns ``` DEVICE TYPE STATE CONNECTION enp1s0 ethernet unmanaged -- lo loopback unmanaged -- ``` lsusb returns Bus 001 Device 005: ID a69c:8d80 aicsemi AIC Wlan So I guess that's the wifi hardware and AI claims my system does not have the drivers. AI then sent me on a search for the drivers, but it was to a repo that does not exist, so kind of looking for help here now! 0 Quote
aram Posted June 7 Author Posted June 7 I did more of a dance with AI and eventually got it working. This was the real repo: https://github.com/radxa-pkg/aic8800 Got the AI to write a summary of the dance. Phase 1: Resolving the Tooling and Environment Dependencies We started with a clean, lightweight system image missing common Linux development tools. We methodically installed the software compilation and packaging toolchain required to handle vendor drivers: Kernel Headers: Replaced the generic linux-headers-$(uname -r) command with the specific architecture branch package (linux-headers-current-arm64) to give the driver access to the Linux kernel API blueprints. Line Ending Conversions: Installed dos2unix to fix internal cross-platform formatting issues within the raw source files. Packaging Toolchain: Installed devscripts, debhelper, and fakeroot to fulfill the minimum environment demands of the dpkg-buildpackage engine. DKMS Engine Helpers: Installed dh-dkms to handle the missing modern virtual package mapping (dh-sequence-dkms). Phase 2: Resolving Kernel Version API Incompatibilities Because the hardware driver code was originally written for older Linux builds, trying to compile it directly against a modern 6.18 kernel threw standard compilation crashes. We bypassed the rigid Debian patch architecture and fixed the source code directly: Signature Alignment: Modified the function argument signature for .get_tx_power in rwnx_main.c to support the newer 5-parameter layout required by the upstream kernel (struct wiphy *wiphy, struct wireless_dev *wdev, int bss_idx, unsigned int link_id, int *mbm). Variable Alignment: Updated the interior variable name pointer within that function definition from dbm to mbm to match modern wireless power unit metrics used in current Linux network subsystems. Phase 3: Bypassing Packaging & Direct Kernel Compilation Rather than battling failing packaging lint tests or restrictive file verification scripts, we pivoted to an elegant, direct implementation: Dropped straight into the target interface folder (src/USB/driver_fw/drivers/aic8800/). Ran a direct raw build command targeting the standalone USB interface module flag: make CONFIG_AIC8800_USB=m. Manually pushed the generated binaries directly into the system kernel storage directory tree using sudo make install and synchronized the dependency layout using depmod -a. Phase 4: Correcting Firmware Pathing & Module Sequence The driver successfully built and registered with the kernel, but the physical USB bus threw initialization timeouts (bus is not up=0). We fixed the underlying hardware communication pipeline: Firmware Relocation: Traced the location of the compiled firmware folder hidden within the repository's package blueprints, and copied the raw firmware files directly into the absolute hardware search path at /lib/firmware/aic8800D80/. Sequential Probing: Cleared out the broken module states and forced the hardware interface modules to load in their structural order—giving the hardware bus loader helper (aic_load_fw) a 2-second sleep window to awaken the USB links before initializing the operational wireless adapter engine (aic8800_fdrv). 0 Quote
li20034 Posted 3 hours ago Posted 3 hours ago (edited) There is supposed to be a package that automatically handles building a (presumably patched) version of the kernel module for this wifi/bt chip, called `aic8800-usb-dkms`, but for some reason, a kernel upgrade doesn't auto-trigger it. During the last kernel upgrade, I was able to get it working by manually doing `sudo dpkg-reconfigure aic8800-usb-dkms`, but that also does not work since 26.5.1, as it gives Deleting module aic8800-usb-4.0+git20250410.b99ca8b6-3 completely from the DKMS tree. Loading new aic8800-usb-4.0+git20250410.b99ca8b6-3 DKMS files... Building for 6.18.2-current-qcs6490 Building initial module for 6.18.2-current-qcs6490 Error! Bad return status for module build on kernel: 6.18.2-current-qcs6490 (aarch64) Consult /var/lib/dkms/aic8800-usb/4.0+git20250410.b99ca8b6-3/build/make.log for more information. And that file basically says (a bunch is redacted for brevity): DKMS make.log for aic8800-usb-4.0+git20250410.b99ca8b6-3 for kernel 6.18.2-current-qcs6490 (aarch64) Sat Jun 20 06:36:14 PM PDT 2026 make: Entering directory '/usr/src/linux-headers-6.18.2-current-qcs6490' make[1]: Entering directory '/var/lib/dkms/aic8800-usb/4.0+git20250410.b99ca8b6-3/build/USB/driver_fw/drivers/aic8800' warning: the compiler differs from the one used to build the kernel The kernel was built by: aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0 You are using: gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 ... gcc: error: unrecognized command-line option ‘-fmin-function-alignment=8’; did you mean ‘-flimit-function-alignment’? gcc: error: unrecognized command-line option ‘-fmin-function-alignment=8’; did you mean ‘-flimit-function-alignment’? make[4]: *** [/usr/src/linux-headers-6.18.2-current-qcs6490/scripts/Makefile.build:287: aic_load_fw/aic_txrxif.o] Error 1 ... Apparently, the kernel is now built with gcc 14 (which matches the default in Debian Trixie images but not Ubuntu Noble images which have gcc 13). Not sure how to resolve that inconsistency. 1. Install & replace gcc 13 with gcc 14 (just installing won't work as this dkms module build doesn't respect CC env vars); not sure if this will break other things in Ubuntu 24.04 2. Rebuild the kernel with gcc 13; same issue will re-occur on the next kernel upgrade 3. Or something else Just out of curiosity, did you have to mess around with gcc versions to get it to compile (or are you using Debian Trixie images)? Edited 3 hours ago by li20034 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.