Jump to content

Recommended Posts

Posted

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!
 

Posted

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

 

 

 

Posted (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 by li20034

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines