jernej

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.

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.

what if you first add monitor interface and then delete first one?

Yes, Igor, in order to build sun8i on non x64 host machines, this patch should be included: https://github.com/jernejsk/OpenELEC-OPi2/blob/openelec-7.0/projects/H3/patches/linux/linux-82-fix-build-on-non-amd64-hosts.patch

I checked source code and monitor mode seems to be supported. Maybe you can try this: sudo iw phy phy0 interface add wlan1 type monitor where wlan1 is some unused interface. If that doesn't work, try to play with ifconfig up/down before. At the end, you will have two interfaces, linked to same physical device. You can remove unneeded one with: sudo iw <interface> del where <interface> is the name of the interface you want to delete.

@y52, I don't have time to test it just now, but are you sure that simple "ifconfig wlan0 down" before changing mode wouldn't help?

Here is the patched source, which should work, but I don't have any means to test: https://mega.nz/#!wFJlmCzR!yNKE9Ql2fhc0zfP4mGBOYqEkOkO5yP1W7lxyYZTovrI EDIT: os_dep/linux/sdio_intf.c must be edited and removed calls to wifi_setup_dt() and wifi_teardown_dt()

Unfortunatelly, driver can't be compilet with 'CONFIG_RTL8188F = y' due to missing files... EDIT: Found something promising: https://github.com/geekboxzone/mmallow_kernel/tree/geekbox/drivers/net/wireless/rockchip_wlan/rtl8189fs or http://openlinux.amlogic.com:8000/download/ARM/wifi/rtk8189ftv-2016-05-04-71be37c3f6.tar.gz

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.

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.

Well, then I guess we can only wait to schematic release...

I must disappoint you, but video output set to vdpau in remote desktop will probably never work. The main reason here is tha VDPAU implementation basically bypasses every graphic stack (even the framebuffer) to gain speed and offload processor. For that reason your remote server is not aware that anything should be there. If you want details, just ask

Uh, sorry I missed the thread.

If I understand correctly, Orange Pi Lite comes with a new wifi chipset RTL8189FTV. I checked "official" Android image for it and this setting is the only difference. I'm curious if this is really necessary to make it work. I suspect that it uses same wifi driver as older boards.

Did any of you manage to get RTL8189ETV wifi chip working? I don't own any board with such chip but I received reports that it doesn't work (Plus image on Plus 2). It seems that following is needed to make it work: [module_para] lpo_use_apclk = "losc_out" Can anyone confirm this? EDIT: It seems that I just mix up RTL8189ETV and RTL8189ES, which seems to be the same. But there is one new wifi chipset if I'm not wrong?

What issue do you have with green led? You mean heartbeat trigger set by default? If that is so, you can take my patch...

Seems to be a no-go, at least for legal reasons, if not technical.

No problem. It is in very inconvenient place. I already considered cloning your repo and putting drivers from modules/ folder in the right place, so separate driver builds would not be needed anymore. Actually, the only other driver worth considering would be NAND driver, but since it is only in binary blob form and not many H3 boards include NAND chips, it can be dropped.

Why would MALI R4 driver need a lot of work? I'm using driver r4p0 from kernel source located in modules/mali and it works without a change. Only thing needed would be a proper section in fex file.

Montjoie also implemented some things for different phy options, but nobody managed to get it working on Plus AFAIK. Wens branch seems also worth a try, but currently I'm unable to, so I thought that you did. I will definetly try. In that case it is better to put LED code in board init function, so it will lit almost instantly after power on and it would be defined through dts (which already is).

@tkaiser, I see that you still setting gpio in U-Boot. That is not necessary anymore. It is correctly described in dts and executed during kernel boot. At least if you are using mripard's sunxi-next branch. Anyway, did you managed to set up ethernet on Plus with wens code? I didn't managed to get it working with montjoie's code.

@tkaiser, I can confirm that booting from eMMC already works. Only one option is needed to be turned on in U-Boot (check my github). There is one interesting detail, though. /dev/mmcblk0 and /dev/mmcblk1 have reversed meaning for Plus, at least in OpenELEC. Usually, /dev/mmcblk0 is SD card, but for Plus this means eMMC.

4. Audio patch has no significance on H3. Basically it just sets number of channels to 8 and that's done already. 5. I think you can remove HW video decoding point, if you sure that Armbian alreadi includes libvdpau-sunxi. You can also take updated driver for wifi from my github, although I'm not sure how much better it is. Speed is still something to be desired. About booting from NAND: Yes, that will still take a long time before it would be possible, but I made same mistake as you. OPiPlus has eMMC not NAND. This means that in theory it uses same driver as SD card and booting should be possible. I think that just U-Boot configuration should be adjusted. I will try this next week, when I get hands on Plus.

To be honest, I also tried to use green led for power. Actually, my ultimate goal is to have green led for power on and red led for suspend. Feels more natural because other home entertainment devices has same policy. However, I didn't succed in to turn on green led in U-Boot due to problems with R_PIO pins. Maybe I didn't enable clock or there is problem with pin mapping or both. But currently I have more interesting work than playing with LEDs.

@tkaiser, did you notice this patch? It's about led and keys definition and it is already merged.