Re: RTL8723BS driver doesn't work for,me but I can help testing
Hi Tobias, On Thu, May 21, 2020 at 1:17 PM Tobias Baumann <017623705...@o2online.de> wrote: [...] >>> with my patch and oleg RC5 hotstart(shutdown now) do not work with my >>> box ( wlan goes back to sleep mode always) >> >> I'm not sure what you mean here. >> if you run "shutdown now" then the system does not shut down and only >> wifi goes to sleep mode? > > i meant that after a reboot with "shutdown now" my box restart but the wifi > chip is back in sleep mode , while the wifi chip was online befor the > restart . I don't know how sleep mode is controlled (some GPIO or through SDIO communication) so I can't comment on that [...] > i read also the AP6330 and BCM4330 Datasheet for both of them is a start > order inside the datashet ( i think that RTL8723BS should have same timming) > . the time between 32k clock and WLAN_dis should be more than minimum 2 clock > cycle (1/32kHZ * 2cycle = 0.06ms ) > > also that AP6330 has most identical pinout as RTL8723BS ( i did not get the > pinout of BCM4330 because datasheet only has information to the chip and not > the small extra pcb where the chip is mount) I don't have any additional comments on this one > on Android 4.4 my box told me that GPIOAO_6 ist chip enable and GPIOX_11 ist > wlan enable > > mybe a clue is that in the HArdkernel S805 Datasheet the GPIOAO_6 is also a > 32k clock output (site 42 table 10 Func1 maybe (but i also found some Dts > file from old S805 RTL8723bs box they use only GPIOX_11 and powerPin2 was > comment out ) do you have an oscilloscope or does your multimeter support frequency measurements (based on what I understand it would only have to be capable of measuring 32kHz)? then you can prove or refute this :-) > i have another question , do we use the same wifi.c file for the meson8m2 > boxes as for endless mini ? i have taken a closer look at the file and the > two delay information you are mention are not in the wifi. c is neither a > function nor an instance, it just takes two fixed values "mdelay(200)" line > 156 , furthermore we ignore the output level of wifi_power_gpio2 and > automatically set it to "1" line 378 , so it is important which of the two > pins is passed to the header file first (translate with DEEPL) Endless Mini has the CHIP_EN signal hard-wired to 3.3V This is the .dts from the Endless Mini: https://github.com/endlessm/linux-meson/blob/d628bf1242928927a41f7482ba5ef7295e01a9ff/arch/arm/boot/dts/meson8b-ec100.dts [...] > You are right the chip has only wifi wake host and that should be GPIOX_21 as > input ; maybe on your box the pin is alway high on the board ( direkt an > 3.3V verdrahtet) on the Endless Mini GPIOX_21 is also WIFI_WAKE_HOST I haven't tested any reboot / shutdown / etc. cycles with RTL8723BS there yet because I typically use the sdio controller to access the internal SD card (and at the time of writing the MMC subsystem in Linux doesn't support two different cards with one MMC controller). So only because of your email I did a quick test on the Endless Mini. Best regards, Martin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: RTL8723BS driver doesn't work for,me but I can help testing
Hi Tobias, On Tue, May 19, 2020 at 8:21 AM Tobias Baumann <017623705...@o2online.de> wrote: > > good morning > > i got the new image from oleg(balbes150) 20200518 RC5 and some more > feedback > > with my patch and oleg RC5 hotstart(shutdown now) do not work with my > box ( wlan goes back to sleep mode always) I'm not sure what you mean here. if you run "shutdown now" then the system does not shut down and only wifi goes to sleep mode? > with my patch chance 1 of 5 till 1 of 3 that my wlan is up and not > sleep from cold start > > with oleg chance 1 of 2 till 1of 3 from cold start that wlan is up . > (maybe because of phandle order?) > > i thing there is maybe a timming problem between wlan dis , sdio data > and host wake up wlan . the power sequence driver supports the following two properties, see [0]: - post-power-on-delay-ms - power-off-delay-us Those are not set, meaning no delay is applied. For reference, these are the delays which are used on the Endless Mini (which also has a RTL8723BS module): [1] Do you know more about these delays (whether they are needed and how long they are supposed to be)? > it could be that GPIOAO_6 is the host wake up wlan ? is it possible to > change the activation order for the gpio pins by change it in dts ? please check my previous mails. I think that GPIOX_21 is the wifi host wakeup pin because it is marked as "input" on the 3.10 kernel. you can change the order of the GPIOs inside the sdio_pwrseq node, but all GPIOs are managed together (meaning there's virtually no delay between enabling the first and the second one). I am not sure if using an MMC power sequence is the right thing to do, because the card is detected for me regardless of whether GPIOX_11 is HIGH or LOW. The RTL8723BS driver currently does not manage any GPIOs. Martin [0] https://github.com/torvalds/linux/blob/c477ebe21fabe0010a2ed324ce3a1762c757d867/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt [1] https://github.com/endlessm/linux-meson/blob/4c76999c5c707fba9c390466efca093c3befa908/drivers/amlogic/wifi/wifi_dt.c#L153 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: RTL8723BS driver doesn't work for,me but I can help testing
Hi Tobias, On Mon, May 18, 2020 at 7:59 AM Tobias Baumann <017623705...@o2online.de> wrote: > > hi martin > > i activate your patch ; wlan works ; also with only edit GPIOX_11 wlan > works > > its now GPIO-402 out high ACTIVE_LOW ( 3.3V on pin12) great, thank you for doing the research! did you find out if GPIOAO_6 is needed at all? the 3.10 kernel enables it and sets it to HIGH. my understanding is that you didn't change this one so the output is still LOW. so I'm wondering if it is needed at all (I wouldn't be surprised if it was not needed, these 3.10 kernel .dts files seem to be copy from various vendors and do not necessarily reflect the actual hardware setup inside the box) > i also attached the performance infos Wlan0->Router and RAM->SDHC that's pretty good, great to see that it works fine for you :-) Martin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: RTL8723BS driver doesn't work for,me but I can help testing
Hi Tobias, On Sun, May 17, 2020 at 11:05 PM Tobias Baumann <017623705...@o2online.de> wrote: > > hi martin > > sorry for cc -problem it was my fault in thunderbird > > thanks for dtb file but this file has problem kernel stop with > > [6.122092] mmc0: new high speed SDIO card at address 0001 > [ 35.804258] VCCK: disabling > [ 35.808781] platform pwmleds: deferred probe pending > [ 35.812625] platform sound: deferred probe pending pwmleds was also there in your last dmesg please ignore the sound part, I haven't tested it on that particular board in a while > [ 215.804295] random: crng init done > > (last time deferred probe was gcc problem ) > > please can you provide me with dts file and i complile at my linux box > or maybe only the change line and i use the dtb from image and edit the > lines like the usb patch you can get all my patches from here: [0] as always: some of them are not even in linux-next yet and there's a reason for that ;-) I have changed the GPIO_ACTIVE_* polarity for the two GPIOs in the sdio_pwrseq node if you want to do that by yourself. Best regards, Martin [0] https://github.com/xdarklight/linux/tree/meson-mx-integration-5.8-20200517 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: RTL8723BS driver doesn't work for,me but I can help testing
Hi Tobias, (adding back the original Cc list since that got lost at some point. please keep them included) On Sun, May 17, 2020 at 9:57 PM Tobias Baumann <017623705...@o2online.de> wrote: > > hi Martin > > > i know what you mean with many modules from Arduino sensor modules not > all datasheet are correct > > ok i got into uboot env > > i could not get GPIOA0 write because of unknowm pin number GPIOAO_0 should work though (the underscore is important) > but GPIOX works > > now my measurmant show that out high = signal high (3.3V) and out low > =singnal low (0.0V) > > without any instruction the S812 pins show something betwen 0.2V and 0.8v > > and that GPIOX_11 (old gpio-123 ; new gpio-402) the one to PIN12 > WLAN-DIS of r8723bs modul > > and like you saw on my kernel cat print it is set to low I have updated the GPIOs polarity of GPIOAO_6 and GPIOX_11 (since both are showing inverse polarity compared to the Android kernel). since I don't know if you build mainline yourself or if you use builds from other people: I attached the updated .dtb so you can use that if you want to Please let me know if that fixes wifi for you. > thanks for you uboot gset instruction thats helps > > Am 17.05.2020 um 20:09 schrieb Martin Blumenstingl: > > Hi Tobias, > > > > On Sun, May 17, 2020 at 8:53 AM Tobias Baumann <017623705...@o2online.de> > > wrote: > >> hi Martin > >> > >> > >> yes i mean rtw_antsel=1 or rtw_ansel=2 with cold start > >> > >> i got hands on pine64 rtl8723bs pdf file with datasheet i attached it > >> there i found the pinout and found a hint that maybe help !!! > > it *may* help. beware that there are *many* RTL8723BS modules out > > there, which may or may not follow the same pattern. > > > > Realtek only sells the RTL8723BS chip on it's own. But it needs some > > extra components (crystals, resistors, capacitors, ...) > > When changing some of these components you need to certify (FCC / CE / > > some other regulatory) the wifi card again (to ensure it follows the > > specification and does not interfere with other devices). > > Thus there are manufacturers (for example FN-LINK) that sell certified > > RTL8723BS modules. > > > > Also one datasheet can describe the signal as "active low". > > However, if there is a small transistor circuit on the module PCB (or > > the main SoC PCB) then that can "flip" the signal, meaning: the SoC > > outputs HIGH but the module gets LOW - or vice versa. > > Thus we describe the GPIOs from the GPIO controller (in this case: > > Amlogic SoC) perspective. > > > >> GPIOs 0-135:(from 3.10.99 Kernel ) > >> gpio-3 (gpio_key) in hi > >> gpio-6 (sdio_wifi ) out hi -> > > this one is GPIOAO_6 and called "gpio-382" in your 5.7 kernel GPIO dump > > > >> gpio-14 (amlsd ) in lo > >> gpio-15 (DWC_OTG ) out hi > >> gpio-64 (amlsd ) in lo > >> gpio-122 (sdio_wifi ) out hi > > this one is GPIOX_10. I don't know why the vendor kernel requests this as > > GPIO > > because actually it is using the xtal_32k_out mux on the pin controller. > > I assume this is what you have for pin24 below (32k/RTC clock/WLAN > > clock), because it's output is 32.768kHz (or rounded: 32kHz) > > > >> gpio-123 (sdio_wifi ) out hi > > this one is GPIOX_11 and called "gpio-402" in your 5.7 kernel GPIO dump > > > >> gpio-132 (bt_rfkill ) out hi -> pin 34 Bt_dis (Bluetooth > >> disable) > > this one is GPIOX_20 and not part of your 5.7 kernel GPIO dump > > Linux 5.8 will gain RTL8723BS Bluetooth support -> with that the GPIO > > will show up as well > > > > do you know if this is related to the wifi part somehow? > > > >> gpio-133 (sdio_wifi ) in hi > > this one is GPIOX_21 and not part of your 5.7 kernel GPIO dump either. > > It is the "wifi host wake" and should not be related to your issue. > > the SDIO wifi card uses it to let the host know that data is available > > and the host should resume from suspend. > > > > [...] > >> GPIO Kernel 5.7 > >> > >> gpiochip1: GPIOs 376-390, parent: platform/c8100084.pinctrl, ao-bank: > >> gpio-382 (|reset ) out lo > >> > >> gpiochip0: GPIOs 391-511, parent: platform/c1109880.pinctrl, cbus-banks: > >> gpio-402 (|reset ) out lo > >> gpio-48
Re: RTL8723BS driver doesn't work for,me but I can help testing
Hi Tobias, On Thu, May 7, 2020 at 10:57 AM Tobias Baumann <017623705...@o2online.de> wrote: > > Hello Community > > I was referred to you by Martin. I have an older Android TV box that > runs for over 3 years with Armbian Linux (Debian Jessie Headless Kernel > 3.10.99). I'm looking forward to the new kernels and I'm glad that older > hardware is still supported. > Together with Oleg(balbes150) and Martin(xdarklight) I am testing the > new kernel 5.x for ARM ( Amlogic S812 / Meson8m2 ) . Martin has written > a patch for the SDIO controller in the last days so that also Wifi > module and MMC are recognized. I could now successfully load the driver > module RTLWIFI from the kernel. But unfortunately the card is only > listed on the desktop as "not ready" or in the terminal (iwlist) as "no > scan result". In the dmesg/lsmod RTLWIFI->RTL8723bs is loaded and the > module is loaded with version v4.3.5.5_12290.20140916_BTCOEX20140507-4E40 . > > > I would like to ask you to check the driver because even in kernel > 3.10.99 a newer version (v4.3.16_13854.20150410_BTCOEX20150119-5844) is > loaded and also at github are hard kernels ( version 2017 Kernel 4.9>) > and ap17 and thirdyouth (v5.2.17.1_26955.20180307_COEX20180201-6f52). > More recent ones can also be found - these have already been > successfully tested with Debian 10. i hope that this may solve the > problem with my Linux box. > > I would appreciate feedback on this request or information about > debugging . My Linux box is also available for testing purposes I just tried this on one of my Meson8b boards to see if it's some problem with the MMC controller driver (meson-mx-sdio). Here are my steps: - (boot the board) - ip link set up dev wlan0 - (wait until that finishes, it takes a while because it seems to load the wifi firmware) - iw dev wlan0 scan - (wait a few seconds, then it shows many 2.4GHz wifi networks) - wpa_passphrase MY_24GHz_WIFI_SSID > /tmp/wpa_supplicant_conf - (enter the passphrase and press CTRL-D) - wpa_supplicant -iwlan0 -c/tmp/wpa_supplicant.conf -Dnl80211 & - (wait a couple more seconds for it to connect) - dhcpcd wlan0 - then I ran iperf3, see the attached result - then I ran dmesg | grep -Ei "(rtl8723bs|wlan0)", see the attached result with these commands wifi is working "fine" for me. my definition of fine: it connects to my AP and traffic can flow. transfer speeds are on the low side (with 15Mbit/s and 5Mbit/s) but I have no reference (for example from a vendor kernel) so I can't say if that's to be expected. I am not sure about any "desktop" tools and their behavior because I don't use these. can you please try the steps above and attach the output of the "failing" commands (together with the dmesg output)? Best regards, Martin # iperf3 -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.175 port 50082 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 922 KBytes 7.55 Mbits/sec0105 KBytes [ 5] 1.00-2.01 sec 1.12 MBytes 9.32 Mbits/sec0153 KBytes [ 5] 2.01-3.00 sec 1.18 MBytes 9.95 Mbits/sec0206 KBytes [ 5] 3.00-4.18 sec 1.43 MBytes 10.2 Mbits/sec0270 KBytes [ 5] 4.18-5.00 sec 1.68 MBytes 17.1 Mbits/sec0342 KBytes [ 5] 5.00-6.10 sec 1.93 MBytes 14.6 Mbits/sec0426 KBytes [ 5] 6.10-7.00 sec 1.86 MBytes 17.4 Mbits/sec0433 KBytes [ 5] 7.00-8.00 sec 2.73 MBytes 22.9 Mbits/sec0433 KBytes [ 5] 8.00-9.00 sec 2.80 MBytes 23.5 Mbits/sec0433 KBytes [ 5] 9.00-10.00 sec 2.80 MBytes 23.5 Mbits/sec0433 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 18.4 MBytes 15.5 Mbits/sec0 sender [ 5] 0.00-10.22 sec 17.5 MBytes 14.4 Mbits/sec receiver iperf Done. # iperf3 -c 192.168.1.100 -R Connecting to host 192.168.1.100, port 5201 Reverse mode, remote host 192.168.1.100 is sending [ 5] local 192.168.1.175 port 50086 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 584 KBytes 4.76 Mbits/sec [ 5] 1.00-2.04 sec 509 KBytes 4.02 Mbits/sec [ 5] 2.04-3.00 sec 549 KBytes 4.68 Mbits/sec [ 5] 3.00-4.00 sec 962 KBytes 7.88 Mbits/sec [ 5] 4.00-5.00 sec 749 KBytes 6.15 Mbits/sec [ 5] 5.00-6.00 sec 1.29 MBytes 10.8 Mbits/sec [ 5] 6.00-7.00 sec 427 KBytes 3.51 Mbits/sec [ 5] 7.00-8.01 sec 451 KBytes 3.65 Mbits/sec [ 5] 8.01-9.00 sec 601 KBytes 5.00 Mbits/sec [ 5] 9.00-10.00 sec 638 KBytes 5.20 Mbits/sec - - - -
