Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

T2U on Jetson Nano not working without modifications #325

Open
octavio2895 opened this issue Jan 5, 2020 · 6 comments
Open

T2U on Jetson Nano not working without modifications #325

octavio2895 opened this issue Jan 5, 2020 · 6 comments

Comments

@octavio2895
Copy link

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 4235b0e with similar results.

After reading the last comment on this thread I followed the advice and checkout d277c36. I manually implemented the changes done in 4235b0e, 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 981899f 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
Copy link
Contributor

toolboc commented Jan 20, 2020

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
Copy link
Author

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

@toolboc
Copy link
Contributor

toolboc commented Jan 20, 2020

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
Copy link
Author

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
Copy link
Contributor

toolboc commented Jan 21, 2020

It worked because you indicated that you manually included the working changeset that enables T2U support in 4235b0e. 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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants