Libre Computer Renegade (ROC-RK3328-CC) Wifi dongle

    I'm on 20221130104423-e014594 (LE 11 nightly) unofficial build for my board and am having trouble getting the WiFi dongle to work. If I use the Ubuntu image you can get for the board (22.04) it works and is recognized. I've thought this was a Linux kernel module missing thing but since Ubuntu's kernel in their image is 6.0.11 and the one in the build of LE I'm using is 6.0.10, I would assume they are very similar.

    I've been messing around with trying to figure out the chipset of said device which is shown below.

    Code: lsusb.txt
    Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 07d1:3303 D-Link System DWA-131 802.11n Wireless N Nano Adapter(rev.A1) [Realtek RTL8192SU]
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 099a:7202 Zippy Technology Corp. Wireless Keyboard/Mouse
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 13fe:4100 Kingston Technology Company Inc. Flash drive
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    It's RTL8192SU. Well the driver used in Ubuntu is r8712u which I've read on a little and that is ok as it supports this device. I ran dmesg and that's how I figured out its using that driver in the build I'm using. I also tried grabbing the firmware.bin file which was this on Ubuntu and loading per the guide on the wiki under /storage/.cache/firmware/. Not sure this was necessary as I am not as experienced with dealing with Linux kernel modules and firmware This is necessary to get it to be recognized on reboot for this build.

    Even with doing this, the dongle isn't fully recognized in Kodi, so I rebooted into textmode. Still sees it but doesn't turn on to use. I ran ip a command and showed wlan0 device but if I ran ifconfig it wouldn't show it. It wasn't until I ran ifconfig wlan0 up it finally shows up with ifconfig. Also when I did this, the dongle started blinking like it did on Ubuntu so I figured something was working or getting closer to working.

    But with it blinking, I still can't use it. Tried connmanctl to search for the device but didn't work. I'm not familiar with that tool either and therefore not sure how to force it to search for the device or enable it. This is where I'm at right now and I'm not sure where to go. I tried connmactl  then ran agent on and scan wifi which gave an error of

    /net/connman/technology/wifi: Method "Scan" with signature "" on interface "net.connman.Technology" doesn't exist

    I've tried other things to no avail, but with a stripped down Linux that I'm not 100% used to versus a debian based system it's proving more difficult. Any guidance or help would be appreciated. I know I read on here that enabling modules is fairly easy but couldn't find anything on here or the wiki or even just google searching.

    Attached dmesg.txt for reference.

    EDIT: I have tried LibreELEC-RK3328.arm-11.0-nightly-20221207-cfd7db5-roc-cc.img.gz and

    LibreELEC-RK3328.arm-11.0-nightly-20221201-732acb2-roc-cc.img.gz with no luck. Even if I load the firmware in through the method described above and from the wiki, it won't even load. At least with the other unofficial build I get to where it loads it but still can't use it.

    The kernel in the Ubuntu 22.04 VMs that I have running is Linux 5.15.x and although I haven't checked, I would expect the distro to package the Realtek vendor drivers. We avoid those because they are a pain in the arse to maintain over time; they break with every major kernel bump (something we do more often than most distros) and need constant patching. Ubuntu has more people contributing to their sources and puts up with crap like that.

    The kernel in LE master (nightlies) is currently Linux 6.0.x which has a staging (testing/development) driver for that NIC, but the module is not enabled in our kernel defconfig so the driver will not be built and thus the card should not work in our nightlies.

    See: https://github.com/LibreELEC/Libr…ch64.conf#L4917

    The kernel version and defconfig used in balbes150 images is unknown to me and these days I have no idea where Oleg publishes sources to check. It's possible his images have the module enabled and it's possible the staging-quality driver doesn't work (or work great). It's possible he has added the out-of-tree vendor driver /shrug

    If you're confident with Debian etc. perhaps self-build your own LE master nightly image with the staging driver enabled. It might then be missing firwmware, but dmesg will reveal which file you need to pick from the upstream linux-firmware repo to test/prove it. That file might be the same filename as older vendor firmware, but there's probably alignment between driver and specific firmware versions.

    The single log that you shared only shows a booting kernel where a driver loads without errors - it's not hinting there's a problem.

    NB: Please keep the convo in this thread instead of scatter posting over several.

    Hey chewitt, thanks for the reply and all the information. Yeah I noticed my Ubuntu VM also had same kernel. But the one for the Renegade ROC-CC image I got off Libre computer site had 6.0.11. I guess it's different devs maintaining it or something.

    Is there any documentation on the GitHub repo on how to build? I've never built an OS from source before. Mainly just do software dev stuff and OS config for running stuff. I searched around and saw that you mentioned something about enabling module's isn't too hard but couldnt find any documentation on how.

    Yeah I have a few more logs but they don't look too different. But doesn't matter if no errors. Thanks for clarifying though what I was missing. Learned something today haha.

    Sorry wasn't trying to scatter post. I had an issue with usb3 when not using the nightly builds and had a LE10 latest stable off the site. Can delete that one thread if needed.

    As a general rule support for ARM boards is best on the latest kernel so LibreComputer are probably bumping to something newer than the stock 5.15 one. It means the driver in the image is more likely to be the staging driver we're interested to prove, but there's only one way to really find out.

    https://wiki.libreelec.tv/development-1/build-basics has some instructions for building. There are build-in-container options in the wiki too if that's easier on your current setup. It's quite a simple process.

    chewitt How do I go about enabling it to not be in staging but actually built into the system? I tried editing the config you linked to me for the Rockchip build for my board, uncommenting it and setting equal firs to "m" then "y" but no dice. I'm sure its probably a simple thing. After some more reading, I can gather that if its in staging it should be allowed to be used and tested with correct?

    Connmanctl doesn't see it but again,ip a command does. If I bring it up with ip, then ifconfig sees it and back to where I first posted, it blinks but can't do anything with it. Again, probably missing something or its something simple since I'm new to building kernels/OSes from source. Still cool though. Thanks for the help so far.

    Didn't take too long with a 12 core xeon running compiling it haha.

    Edited once, last by FurmanSK (December 9, 2022 at 11:53 PM).

    Staging means the driver is still in development (this one for many years) so the driver code is located in a specific separate area of the kernel tree (filesystem) but otherwise the process for enabling the module is the same as any other; uncomment and setting CONFIG_R8712U=m or =y should be the only thing required to build the driver. In LE buildystem, make the change to https://github.com/LibreELEC/Libr…ch64.conf#L4917 then build the image again; the kernel defconfig change will be detected and only the kernel (and any packages depending on it) will be rebuilt so it's normally quick to respin the image. I can see that the USB IDs for your card are present https://cateee.net/lkddb/web-lkddb/R8712U.html so in theory it should probe and be active automatically. If it doesn't, there's an issue to be investigated.

    Ah ok so what I did was correct way to enable. Well where do I go from here? Do I need to enable debug on compile for the kernel? I tried reading up on connman to see if there's a reason why it doesn't see it but the other commands do but didn't really see much. Any thoughts? Planning on messing with it some today.

    Code
    rmmod r8712u
insmod /usr/lib/kernel-overlays/base/lib/modules/6.1.0-rc8/kernel/drivers/staging/rtl8712/r8712u.ko debug=0x1416

    Mind the line wrap ^ above; remove and reinsert the driver with a debug option and then see if anything more was printed to dmesg? - If yes, run "dmesg | paste" and share the URL. If nothing.. I'm out of ideas, other than removing the staging driver and digging up an older vendor driver. The TODO file in staging points to https://github.com/chunkeey/rtl8192su as an alternative; you can probably cp -R an existing realtek driver package.mk and swap the URLs/GitHash details to build it; if it builds.