T2U on Jetson Nano not working without modifications

[octavio2895]

I've finally made it work after some modifications.

Using the head doesn't seem to work. It compiles but DKMS shows some errors related to the kernel. I believe that the kernel I have (after a clean install of the OS) already had some drivers for 8812AU. I modified the Makefile.dkms to force DKMS to install it regardless (using the --force flag). That didnt work. I checkout 4235b0ec7d7220a6364586d8e25b1e8cb99c36f1 with similar results.

After reading the last comment on this thread I followed the advice and checkout d277c3681ead3ff35169d19fbf119c2d4956b275. I manually implemented the changes done in 4235b0ec7d7220a6364586d8e25b1e8cb99c36f1, modified the Makefile.dkms, ran# sudo make -f Makefile.dkms install and rebooted. Surprisingly it worked!

This whole experiment implies that the changes done in 981899f422fb25a95218a146619c7cda3ed5297c caused these issues.

Anyways, I'm not competent enough to make a pull so I decided to write this to guide many Jetson Nano with T2U adapters users browsing this. Hopefully you guys can find the issue and fix it? Perhaps I should make a fork in the meantime?

[toolboc]

T2U chipset works fine if you rollback to 4235b0e as there is something completely broken in the current head fa68771

The steps below take this into account and result in a working driver. Depending on changes to the L4T kernel, you may need to force installation due to presence of a conflicting rtl8812au module, this is also accounted for.

sudo apt install dkms
git clone https://github.com/abperiasamy/rtl8812AU_8821AU_linux
cd rtl8812AU_8821AU_linux
git checkout 4235b0e
sed -i 's/CONFIG_PLATFORM_I386_PC = y/CONFIG_PLATFORM_I386_PC = n/g' Makefile
sed -i 's/CONFIG_PLATFORM_ARM_JET_NANO = n/CONFIG_PLATFORM_ARM_JET_NANO = y/g' Makefile
sed -i 's/install -m/install --force -m/g' Makefile.dkms
sudo make -f Makefile.dkms install

@abperiasamy can we get an official audit or otherwise remove fa68771? The issue was initially reported back in October in #312 and it's still here breaking things.

[octavio2895]

@toolboc wierdly enough I tried using 4235b0e to no avail. It wasnt until I rollback into d277c3681ead3ff35169d19fbf119c2d4956b275 and manually implemented 4235b0e (bypassing 981899f) that it finally worked for me. Are you using a Jetson Nano?

[toolboc]

Yes, I am using a Jetson Nano. The steps you are describing are essentially the same thing as rolling back to 4235b0e , however, there is one additional step I had to perform.

The latest kernel seems to ship with a conflicting rtl8812AU driver, so any installation will seem to go well but there will be a message that there is a conflict. If you install in this state, it is required that you remove the module from DKMS with dkms uninstall -m rtl8812au -v 4.3.14 as subsequent attempts to modify the rtl88a12au source will instead use the cache from the original attempt. Your attempt to rollback may have not accounted for this, and so the kernel would still load the pre-existing (non-T2U compatible) module rather than the new one from DKMS with T2U support.

To get around the issue of the conflicting driver, I just enabled force installation in the install target of Makefile.dkms and it works without issue. This is accounted for with: sed -i 's/install -m/install --force -m/g' Makefile.dkms

[octavio2895]

I did uninstall the previous driver with DKMS and I did force the installation on the Makefile on every attempt. I cant really retry these steps you pointed out since my jetson is being used ATM. And even if I didnt uninstall using DKMS and/or forced the install, why did it worked when I tried installing the version that did work for me?

[toolboc]

It worked because you indicated that you manually included the working changeset that enables T2U support in 4235b0ec. All change sets before and up to that change were working at the time I made the pull request so it is highly doubtful that 981899f is the root cause. In fact, I flashed 30 devices with that revision without issue.

The reason that skipping 981899f aided you is likely due to the side effect that it reverts the Makefile to compile for the nano architecture without additional changes. If you were not manually modifying the Makefile prior to that, you would be targeting an incompatible architecture.

When you get your device back, try out the steps I've included, it should work without issue.

[octavio2895]

Yes I did change the target system on the Makefile. Would dkms allow the installation of an i386 module on an arm machine anyways?

Anyhow, I will try your steps once I get ahold of a board.