Jump to content

Recommended Posts

Posted

I got my lite days ago, and have tried lots of images, none of them can recognize the build-in wifi :(  Instead, a eth0 device is presented. is it the actual wlan?

 

Armbian gives me the best compatibility so far (in terms of usb support)

 

I can read the chip module is printed realtek 8189FTV, but lsmod shows me a 8189es module loaded. By google around, no luck for the FTV version driver.

 

I also played with the script.bin, but still no luck. Anyone can give me some hints.

 

Thanks.

Posted

None of us devs has a Lite in his hands and we have no information about compatibility of the now used 8189FTV with the former used 8189ETV (using the 8189es module). We tried to prepare the Lite's arrival a while ago so it would be helpful if you load the updated fex file from here: https://github.com/igorpecovnik/lib/blob/master/config/fex/orangepilite.fex

 

Save it as a plain text file please while running Armbian on your board, then use

sudo su -
fex2bin /path/to/textfile /boot/bin/opilite-test.bin
ln -sf /boot/bin/opilite-test.bin /boot/script.bin
reboot

Obviously /path/to/textfile has to be replaced with the path of the text file you downloaded before. Please get back to us with information whether this helps. Best thing would be to post the output from 'sudo armbianmonitor -u' after the reboot.

Posted

As a quick try of the file, only copy and paste, wifi is still not working.

 

I don't see any update on the [wifi_para] session compare to the original orangepilite.bin. Not sure if it needs some fine tune to the numbers/ids.

 

I have no idea how do those parameters get determined. is it worth to try some sequence number, such as wifi_sdc_id=[2-8]?

 

Any beginner;s guide about that would be great too.

 
Posted

Well, it's ok if you don't want to help us -- means you have to wait quite some time. Again: None of us had a Lite in his hands, we have exactly zero information about the WiFi chip used, the whole fex file has been written by us based on assumptions and I asked you for the output of 'sudo armbianmonitor -u' which you refrain to provide.

Posted

Thx for the log. Regarding Ethernet we have to change line 351 to

gmac_used = 0

since now the internal PHY is recognized (H3 has an Fast Ethernet PHY integrated) and used even if it has zero connections to the outside (just like an Ethernet jack where never a cable will be plugged in).

 

Regarding WiFi: Hard to tell what's going on or wrong. I've no device with 8189ETV here so can't compare dmesg output. And AFAIK still no schematic released for the new Oranges so in case Xunlong changed hardware pin mappings it would be trial and error and in case the driver we now ship with is not compatible with 8189FTV it's basically the same.

 

Thx for testing. Maybe Igor has his OPi Plus ready and can at least compare dmesg output.

 

EDIT: Does /sys/bus/sdio/ exists and if so can you please provide the output of

ls -laR /sys/bus/sdio/

(preferrably in code blocks or on pastebin.com or similar if it's a huge amount of text)

Posted
  On 5/20/2016 at 1:00 PM, tkaiser said:

Thx for the log. Regarding Ethernet we have to change line 351 to

gmac_used = 0

since now the internal PHY is recognized (H3 has an Fast Ethernet PHY integrated) and used even if it has zero connections to the outside (just like an Ethernet jack where never a cable will be plugged in).

 

Regarding WiFi: Hard to tell what's going on or wrong. I've no device with 8189ETV here so can't compare dmesg output. And AFAIK still no schematic released for the new Oranges so in case Xunlong changed hardware pin mappings it would be trial and error and in case the driver we now ship with is not compatible with 8189FTV it's basically the same.

 

Thx for testing. Maybe Igor has his OPi Plus ready and can at least compare dmesg output.

 

EDIT: Does /sys/bus/sdio/ exists and if so can you please provide the output of

ls -laR /sys/bus/sdio/

(preferrably in code blocks or on pastebin.com or similar if it's a huge amount of text)

 

 

The output is following:

/sys/bus/sdio/:
total 0
drwxr-xr-x  4 root root    0 Jan  1  1970 .
drwxr-xr-x 16 root root    0 Jan  1  1970 ..
drwxr-xr-x  2 root root    0 Jan  1  1970 devices
drwxr-xr-x  4 root root    0 May  1 01:29 drivers
-rw-r--r--  1 root root 4096 May  1 01:30 drivers_autoprobe
--w-------  1 root root 4096 May  1 01:30 drivers_probe
--w-------  1 root root 4096 May  1 01:29 uevent

/sys/bus/sdio/devices:
total 0
drwxr-xr-x 2 root root 0 Jan  1  1970 .
drwxr-xr-x 4 root root 0 Jan  1  1970 ..
lrwxrwxrwx 1 root root 0 May  1 01:29 mmc1:0001:1 -> ../../../devices/platform/sunxi-mmc.1/mmc_host/mmc1/mmc1:0001/mmc1:0001:1

/sys/bus/sdio/drivers:
total 0
drwxr-xr-x 4 root root 0 May  1 01:29 .
drwxr-xr-x 4 root root 0 Jan  1  1970 ..
drwxr-xr-x 2 root root 0 May  1 01:29 rtl8189es
drwxr-xr-x 2 root root 0 May  1 01:29 rtl8723bs

/sys/bus/sdio/drivers/rtl8189es:
total 0
drwxr-xr-x 2 root root    0 May  1 01:29 .
drwxr-xr-x 4 root root    0 May  1 01:29 ..
--w------- 1 root root 4096 May  1 01:30 bind
--w------- 1 root root 4096 May  1 01:29 uevent
--w------- 1 root root 4096 May  1 01:30 unbind

/sys/bus/sdio/drivers/rtl8723bs:
total 0
drwxr-xr-x 2 root root    0 May  1 01:29 .
drwxr-xr-x 4 root root    0 May  1 01:29 ..
--w------- 1 root root 4096 May  1 01:30 bind
--w------- 1 root root 4096 May  1 01:29 uevent
--w------- 1 root root 4096 May  1 01:30 unbind
Posted

Can anyone with a Lite please try these fex modifications out:

 

 

  Reveal hidden contents

 

 

Changes: Defined eth0 as non existent and added 'lpo_use_apclk = "losc_out"' to WiFi section. Please report back ASAP preferably with output from

sudo armbianmonitor -u
lshw
ls -laR /sys/bus/sdio/
Posted

@tkaiser & @Igor

 

if it will help the Devs, i will make an additional contribution to the project to cover the cost of two Orange Pi Lites.

Posted
  On 5/24/2016 at 4:38 PM, Gravelrash said:

if it will help the Devs, i will make an additional contribution to the project to cover the cost of two Orange Pi Lites.

 

Thx for the offer. Please compare the value of an hour of development work with hardware costs for those boards and decide then again regarding donations ;)

 

At the moment nothing is known about compatibility between 8189ETV as used before and 8189FTV now so the whole approach to get this stuff up and running might waste a few hours easily...

Posted
  On 5/24/2016 at 4:47 PM, tkaiser said:

Thx for the offer. Please compare the value of an hour of development work with hardware costs for those boards and decide then again regarding donations

 

i hear you!!  

 

+I don't own that particular device and probably never will, 

 

I applaud you for attempting to support a device that even the manufacturer cant/wont and you don't even have your hands on, which is why i will again donate to the cause.

 

I really wish that the manufacturer took the view that by engaging more with you chaps there reputation would soar and the community as a whole would benefit.

 

There's a lot to be said for "Free and Open Source", but too many manufacturers and people seem to think free, as in beer; is what Free means......

 

anyroads.... paypal here i come..

Posted

I've just received OPI LITE and start testing based on Armbian_5.10 I've adapted/customized for my use cases on OPI ONE. By using the (dvfs-corrected) OPI ONE fex-file

for OPI LITE, disabling gmac (eth0) and not enabling internal wifi of the OPI LITE, the OPI LITE works just like the OPI ONE ( minus LAN ). Connections via external USB-LAN

connector ( 278mbps ) and cheap wifi-dongle ( 50mbps with noise) are successfully tested.

 

No valid testing output for internal wifi yet, will post as soon as tested.

Posted

So, my OPi Plus 2E arrived that also features 8189FTV (as do Lite and PC Plus too). With this fex file I get one device appearing below /sys/bus/sdio/devices/ after loading 8189es driver.

root@orangepiplus2e:/sys/bus/sdio/devices/mmc2:0001:1# cat device 
0xf179
root@orangepiplus2e:/sys/bus/sdio/devices/mmc2:0001:1# cat vendor 
0x024c

According to driver sources vendor/device ID point to 8188F. 'armbianmonitor -u' output here: http://sprunge.us/jiOI (don't be scared that's an Armbian image for BPi M2+ running there a few days testing DVFS stuff I hijacked by exchanging script.bin and a few settings, you can see dmesg output at the end. At second 172 I unloaded the driver and at 205 I loaded it again). Since I have no WiFi experiences with Linux (one experiment last year and that was that PITA that I'll not touch this area soon again) I hope this information is of help for others.

Posted

After I saw your link to the driver source on IRC, I remembered to check driver build options and come to the following conclusion:

 

If you want driver for RTL8189ETV, you should choose CONFIG_RTL8188E = y https://github.com/jwrdegoede/rtl8189ES_linux/blob/master/Makefile#L27

If you want driver for RTL8189FTV, you should choose CONFIG_RTL8188F = y https://github.com/jwrdegoede/rtl8189ES_linux/blob/master/Makefile#L34

 

And the best part is that same module can't support both chips at the same time. You have to compile it two times with different settings. BTW, that fex mod might still be needed but I can't tell for sure due to missing schematic.

Posted

Thx jernej for looking into it. Can we use these driver sources (since I would suspect Hans is only interested in mainlining driver work) with 3.4.x kernel and what about 'CONFIG_MULTIDRV = y' in sources?

Posted

Yes, those sources can be used with 3.4 (I'm using them) with some modifications. I'm not sure what CONFIG_MULTIDRV does, currently.

 

EDIT: It doesn't do anything. :)

Posted
  On 5/25/2016 at 5:03 PM, jernej said:

Here is the patched source, which should work, but I don't have any means to test

 

Thx a lot. Seems Igor is already testing and preparing to integrate drivers to be included in stock Armbian builds. :)

 

BTW: As reported by Y52 monitoring mode doesn't work. By looking through the sources do you have an idea why?

Posted

Some people confirmed that driver is working on Lite. However, MAC address changes every boot. This is very annoying at least for OpenELEC.

 

EDIT: Driver seems to behave same as RTL8189ES in this regard. So the only explanation is that RTL8189ES has preprogrammed MAC address in e-fuse storage but RTL8189FS doesn't.

Posted

Here is my solution for loading different wifi drivers on different boards. Basically it is just oneshot systemd service which runs a bash script. That script checks script.bin settings currently in use (there is read_fex.c source) and based on wifi settings loads appropriate wifi driver. In case of RTL8189FS it also checks for saved mac address and pass it as an argument or it creates a random one and saves it. Paths should be updated to be more appropriate for Debian.

 

Latest RTL8189FS source is here.

Posted

Added and it works, thanks Jernej. I also pushed to repository that you can test:

apt-get update && apt-get upgrade

Now for 8189es - is it best to use this source - with config change of course?

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines