Support for RTL8189FTV on orange pi zero+

Any plan to add wifi support on Orange pi zero+?
Hauke started the work:
but is not completed.

Thank you

I've actually tried to do this for both the Orange Pi Zero Plus and the Orange Pi Zero (the xr819 drivers). In both cases they compile but then kernel panic when I try to insmod them.

Example Crash of the XR819

I'm working on porting over to the 4.19 kernel to see if that helps in any way right now. So far 4.19 is building; I'll test it on my Orange Pi Zero and Orange Pi Zero + in the next few days and then try my xr819 and if that works see if the rtl8189ftv works too.

The good news on the 4.19 port is it seems extremely straightforward as the majority of the patches are no longer needed. A handful are though and they seem to work just fine. There is one patch I'm not sure if it is needed or not (something about the reset for the H3) but it fails to apply cleanly as there appeared to be some changes to the reset code between 4.14 and 4.19 for the sunxi target.

Are you using this:

driver repository?

That's the one. 4.19 compiled successfully for all sunxi targets, and ran perfectly fine on my Orange Pi Zero H2+. I'm going to try building an image for the Orange Pi Zero H2+ with the xr819 enabled and the Orange Pi Zero Plus (H5) with the rtl8189fs enabled and see if they still kernel panic on me. Will compile them today remotely but probably won't get to test them on the hardware until later tonight/tomorrow at the earliest.

Module not compiling on 4.19. Also I think I know what I was doing wrong and why the module was segfaulting...

On the bright side the xr819 on 4.19 on the Orange Pi Zero seems to be working just fine, excepting some interrupt messages spamming the dmesg output. Can use it as an AP or connect to my WLAN just fine.

edit: Compilation error looks like it might be difficult to solve. Near as I can tell (and I'm not a C programmer so I am pretty much talking out of my ass) the driver is calling a header which is calling a header which is calling a header which defines a structure one way (part of the kernel) and simultaneously calls another header which defines the same structure another way (musl library?). Since the musl library structure (struct iovec in alltypes.h) is defined differently than the kernel function (struct iovec in uio.h) the compiler craps out.

Someone who is smarter than I will have to solve this. In the mean time I'm refining the xr819 for the Orange Pi Zero H2+ and will post on github. I don't think I will be able to silence all the dmesg log errors (and they'll happen a-plenty) but it will at least seem to work. If it seems reasonably stable I'll initiate a pull request to the OpenWRT master branch.

So I think I’m ready to put this to bed. The rtl8189fs doesn’t compile for me, but even if it did it looks like it won’t work properly in OpenWRT anyway. Hauek never committed his work because it wouldn’t work properly with uci.

The xr819 on the H2+ Orange Pi does seem to work somewhat well (excepting the dmesg spam), but only on the 4.19 kernel. When 4.19 gets pulled into master I’ll pull my changes too.

1 Like

This way not work?

And this - for android.

anyone got it working i have OPiPC+ with same wifi and it's still not working