0bda:b812 rtl88x2bu kernel module

  • Because CE has a kernel that never changes version (as it's the only one they can use) so they hack the driver to work once, and then never have to touch it again. In LE we bump the kernel constantly, and that means all these shitty out-of-tree Realtek drivers break, constantly. Over time we gave up on them and now simply refuse to add more. Fortunately in recent times Realtek has gotten better at submitting their drivers to the kernel, but they breed new chipsets faster than the process of submitting support to the kernel.

    I took your 88x2bu.ko file from your post above, put it into /lib/modules, and then did "/sbin/depmod -a" inside of /lib/modules.

    My adapter still does not show up.

    Help.

    I wouldn't mind compiling it myself, but I don't know where to start.

  • Kernel modules are compiled for a specific kernel version, and unless you are running exactly that version the 'version magic' doesn't align and the module will not load. If you are using 10.0.3 we've bumped the kernel since I built it, and it won't work. If you're using 10.0.2 (which was latest when I built it) it will probably work. I have no plan/interest in building it again (before people ask/demand).

  • Can you give me instructions on how to build that driver myself?

    I haven't used Linux/Unix since the 90's when I used to do programming for a living.

    I don't mind doing it myself if I have good instructions but at this point I don't know where to begin.

    Thanks.

    Can I download " Use the Ubuntu terminal and run Linux applications on Windows.

    Enable Ubuntu on Windows Subsystem for Linux (WSL) ›"

    and be able to compile the driver that way?

    Edited once, last by dootsie5times (November 11, 2022 at 10:33 PM).

  • Any Realtek vendor driver will NOT be accepted into our codebase (this one has already been submitted and refused). Once the upstream patches I've flagged are accepted into the kernel we will happily backport the driver onto whatever kerrnel we're working with at the time (if technically possible) .. but not before.

  • Probably not for all hardware (e.g. I haven't picked all those changes for AMLGX) and I'm not sure they're present for RPi images either.

    They are not in RPi, but I pulled the rtw88 USB patches + fixups in and tested them. The USB drivers cause lock-ups and performance (~100Mbps via iperf) is worse than out-of-tree modules (~270Mbps). I haven't bothered to attach a serial console to see what is causing the lock-up, if it is a kernel crash or something else.

  • Probably not for all hardware

    They are in default patch set. So yeah, not applicable for RPi and amlogic, but for everyone else.

    They are not in RPi, but I pulled the rtw88 USB patches + fixups in and tested them.

    Where did you pulled them from? You should apply rtw88 patches from https://github.com/LibreELEC/Libr…patches/default

    The USB drivers cause lock-ups and performance (~100Mbps via iperf) is worse than out-of-tree modules (~270Mbps).

    In aforementioned patches is a lot of locking fixes but hard to tell if a additional fix is needed without dmesg output. Performance is lower, since USB (and SDIO) transport part of RTW88 driver is community driven, but you have to start somewhere. In any case, this is best that you'll get, out of tree drivers are rejected for a reason.

  • Where did you pulled them from? You should apply rtw88 patches from https://github.com/LibreELEC/Libr…patches/default

    Same patch for linux-121-rtw88-linux-next-6-2.patch, and a newer version (Jan 8th) of linux-122-rtw88-fix-rcu-lock.patch (4 patches in the series, only noticeable change is a static assert to validate the structure size). Not the SDIO patch series. But I tested with SDIO patches and it was similar with an RTL8822BU dongle.

    In aforementioned patches is a lot of locking fixes but hard to tell if a additional fix is needed without dmesg output.

    I'll have to borrow the dongle and put it in another Pi that is a bit more accessible. This one is in one of those aluminum cases and getting to the GPIO header requires removing the case.

  • jernej This new patch:

    https://patchwork.kernel.org/project/linux-…pengutronix.de/

    Seems to resolve the performance issues with rtw88-usb (RTL8822BU), back to 250Mbit/s now and I suspect the lock-up/crashing will be gone. Running a test build now on Pi4 using these patches:

    https://github.com/wagnerch/LibreELEC.tv/commits/rtw88

    Which actual .ko file are you using for USB Network adapters?

    If you've gotten one to work on a RPI 4, would you please post it somewhere for me? I'm running 10.0.4.

    I'm not as familiar with compiling and patching drivers in Linux as you guys are.

    Or, if you can give me step by step instructions on how to do it myself, I'd be fine with that also since as soon as there is a kernel change, I'm sure that .ko wont work anymore.

    If this option, is there an easy way to load a "portable" environment just to compile the driver as opposed to having to install a full linux OS on a box to do it?

    Thanks.

  • Is anyone going to put the drivers into version 10 for the Pi 4?

    I would just upgrade to LE11, otherwise vendor driver is probably your best bet. In both cases for RPi4 you will have to build your own image, guessing we won't see rtw88 native until LE12 for RPi4. I believe the main reason it is in Allwinner builds is because some of the boards are using the SDIO-based rtw88 chips.

    https://github.com/RinCat/RTL88x2BU-Linux-Driver`

    This is more or less the patch you would need to apply for that vendor driver:

  • I believe the main reason it is in Allwinner builds is because some of the boards are using the SDIO-based rtw88 chips.

    That's true. However, patches are placed in such way, that driver is present in every project, except Amlogic and RPi. They use different kernel source.

  • Amlogic uses the same patches in LE11 now - there are several boards with embedded chips or optional RTL8822CS modules.

    It looks like I still have this driver in my RPi4 tree (from providing build guideance before) so you can use this image:

    https://chewitt.libreelec.tv/testing/LibreELEC-RPi4.arm-11.0.1.tar

    I make no promises that it works (if it does, great. If not, so be it). I also make no promises of future images; I have no need for this driver so the first time it fails to compile I'll drop it from my tree.