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
Kindly
Tobias Baumann (RaptorSDS)
--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Hi Tobias,
On Thu, May 7, 2020 at 10:57 AM Tobias Baumann <[email protected]> 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
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 <[email protected]> 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 <[email protected]> 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-484 ( |snps,reset ) out hi ACTIVE LOW
> > you can ignore gpio-484 (snps,reset) for the current issue.
> > This is for the Ethernet PHY and has nothing to do with wifi.
> >
> >> gpio-491 ( |cd ) in lo ACTIVE LOW
> >>
> >>
> >> i think i do not have a pull down gpio pin i need the pins high state
> > which one do you mean exactly?
> >
> > since you are measuring with a multimeter anyways: can you please find
> > out the pin from the Amlogic SoC which is routed to the WLAN_DIS pin
> > of the WIFI module along with the polarity (high/low)?
> > in Amlogic's vendor u-boot you can use:
> > gset GPIO_NAME out high/low
> > for example:
> > gset GPIOX_11 out low
> >
> >
> > Best regards,
> > Martin
> >
>
> --
> Diese E-Mail wurde von AVG auf Viren geprüft.
> http://www.avg.com
>
Best regards,
Martin
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
[ 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
thanks
Tobias
Am 17.05.2020 um 22:28 schrieb Martin Blumenstingl:
> 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 <[email protected]> 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 <[email protected]> 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-484 ( |snps,reset ) out hi ACTIVE LOW
>>> you can ignore gpio-484 (snps,reset) for the current issue.
>>> This is for the Ethernet PHY and has nothing to do with wifi.
>>>
>>>> gpio-491 ( |cd ) in lo ACTIVE LOW
>>>>
>>>>
>>>> i think i do not have a pull down gpio pin i need the pins high state
>>> which one do you mean exactly?
>>>
>>> since you are measuring with a multimeter anyways: can you please find
>>> out the pin from the Amlogic SoC which is routed to the WLAN_DIS pin
>>> of the WIFI module along with the polarity (high/low)?
>>> in Amlogic's vendor u-boot you can use:
>>> gset GPIO_NAME out high/low
>>> for example:
>>> gset GPIOX_11 out low
>>>
>>>
>>> Best regards,
>>> Martin
>>>
>> --
>> Diese E-Mail wurde von AVG auf Viren geprüft.
>> http://www.avg.com
>>
>
> Best regards,
> Martin
--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Hi Tobias,
On Sun, May 17, 2020 at 11:05 PM Tobias Baumann
<[email protected]> 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
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)
i also attached the performance infos Wlan0->Router and RAM->SDHC
Am 18.05.2020 um 00:31 schrieb Martin Blumenstingl:
> Hi Tobias,
>
> On Sun, May 17, 2020 at 11:05 PM Tobias Baumann
> <[email protected]> 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
>
--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Hi Tobias,
On Mon, May 18, 2020 at 7:59 AM Tobias Baumann <[email protected]> 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&pasted
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
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)
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 .
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 ?
Tobias
Am 18.05.2020 um 22:37 schrieb Martin Blumenstingl:
> Hi Tobias,
>
> On Mon, May 18, 2020 at 7:59 AM Tobias Baumann <[email protected]> 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&pasted
> 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
>
--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Hi Tobias,
On Tue, May 19, 2020 at 8:21 AM Tobias Baumann <[email protected]> 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
Resend html-format was inside email
Am 21.05.2020 um 13:17 schrieb Tobias Baumann:
>
> Hi Martin
>
> first of all sorry for my short english writing
>
>
> Am 19.05.2020 um 22:16 schrieb Martin Blumenstingl:
>> Hi Tobias,
>>
>> On Tue, May 19, 2020 at 8:21 AM Tobias Baumann<[email protected]> 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?
>
> 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 .
>
>
>>> 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)?
>
> 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)
>
> 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 )
>
> ->
>
> 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)
>
> <-
>
>
>
>
>>> 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
>
> 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)
>
>
> thanks for the information
>
>
> Tobias
>
--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Hi Tobias,
On Thu, May 21, 2020 at 1:17 PM Tobias Baumann <[email protected]> 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