rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

[Brent Roman]

Originally sent to linux-wireless on Feb 1, 2024:

The Radxa RockPi-S has a built-in RTL8723DS interfaced to a Rockchip 
RK3308 A35 ARM64 processor on one of its SDIO busses.

I maintain Armbian's support this board.

The built-in WiFi works perfectly with RTL's 8723ds.ko driver.
Recently, the rtw88 driver got support for SDIO.
https://lwn.net/Articles/925940/

However, when we attempt to enable the rtw88_8723ds module, WiFi does 
not work.

Specifically, the WiFi scan returns only the strongest AP while 
indicating that AP has a very weak signal.
No connections can be made.

Unloading the rtw88_8723ds modules to replace it with 8723ds immediately 
restores WiFi function without the need to reboot the system.

Has anyone tested the SDIO variant of this driver?
If so, on which board(s)?

I'd very much like to get this working.
Any tips for debugging, or just getting relevant info from the driver, 
would be appreciated.

Thanks!

Re: rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

[Larry Finger]

On 2/15/24 17:55, Brent Roman wrote:
> Originally sent to linux-wireless on Feb 1, 2024:
> 
> The Radxa RockPi-S has a built-in RTL8723DS interfaced to a Rockchip RK3308 A35 
> ARM64 processor on one of its SDIO busses.
> 
> I maintain Armbian's support this board.
> 
> The built-in WiFi works perfectly with RTL's 8723ds.ko driver.
> Recently, the rtw88 driver got support for SDIO.
> https://lwn.net/Articles/925940/
> 
> However, when we attempt to enable the rtw88_8723ds module, WiFi does not work.
> 
> Specifically, the WiFi scan returns only the strongest AP while indicating that 
> AP has a very weak signal.
> No connections can be made.
> 
> Unloading the rtw88_8723ds modules to replace it with 8723ds immediately 
> restores WiFi function without the need to reboot the system.
> 
> Has anyone tested the SDIO variant of this driver?
> If so, on which board(s)?
> 
> I'd very much like to get this working.
> Any tips for debugging, or just getting relevant info from the driver, would be 
> appreciated

Brent,

Yes, there are SDIO cards working with the RTW88 driver.

Is the EFUSE properly encoded on the RockPI-S? If not, then the parameters of 
the chip with respect to gains are not set correctly. You should be able to see 
that condition in the dmesg output. Also, is the driver getting a realistic MAC 
address? That also comes from the EFUSE.

Larry

Re: rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

[Brent Roman]

Larry,

Radxa confirmed that they do not program the eFUSE on these boards.
We do not get a sensible MAC from the chip, so I derive a one from the 
CPU's unique serial number.
It's a hack, but it works well and is standard's compliant.

The RockPI-S a *very* inexpensive board, so I can understand Radxa 
wanting to minimize the time spent configuring each one.
https://shop.allnetchina.cn/products/rock-pi-s

The vendor driver seems to deal with this by applying typical gain 
parameters when the eFUSE is invalid.
With that driver, this board's WiFi performs beautifully, despite the 
unprogrammed eFUSE.

Would you accept a patch to add this logic to RTW88?

- brent


Larry Finger wrote:
> On 2/15/24 17:55, Brent Roman wrote:
>> Originally sent to linux-wireless on Feb 1, 2024:
>>
>> The Radxa RockPi-S has a built-in RTL8723DS interfaced to a Rockchip 
>> RK3308 A35 ARM64 processor on one of its SDIO busses.
>>
>> I maintain Armbian's support this board.
>>
>> The built-in WiFi works perfectly with RTL's 8723ds.ko driver.
>> Recently, the rtw88 driver got support for SDIO.
>> https://lwn.net/Articles/925940/
>>
>> However, when we attempt to enable the rtw88_8723ds module, WiFi does 
>> not work.
>>
>> Specifically, the WiFi scan returns only the strongest AP while 
>> indicating that AP has a very weak signal.
>> No connections can be made.
>>
>> Unloading the rtw88_8723ds modules to replace it with 8723ds 
>> immediately restores WiFi function without the need to reboot the 
>> system.
>>
>> Has anyone tested the SDIO variant of this driver?
>> If so, on which board(s)?
>>
>> I'd very much like to get this working.
>> Any tips for debugging, or just getting relevant info from the 
>> driver, would be appreciated
>
> Brent,
>
> Yes, there are SDIO cards working with the RTW88 driver.
>
> Is the EFUSE properly encoded on the RockPI-S? If not, then the 
> parameters of the chip with respect to gains are not set correctly. 
> You should be able to see that condition in the dmesg output. Also, is 
> the driver getting a realistic MAC address? That also comes from the 
> EFUSE.
>
> Larry


-- 
  Brent Roman                                   MBARI
  Software Engineer               Tel: (831) 775-1808
  mailto:brent@mbari.org  http://www.mbari.org/~brent

Re: rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

[Larry Finger]

On 2/17/24 23:13, Brent Roman wrote:
> Larry,
> 
> Radxa confirmed that they do not program the eFUSE on these boards.
> We do not get a sensible MAC from the chip, so I derive a one from the CPU's 
> unique serial number.
> It's a hack, but it works well and is standard's compliant.
> 
> The RockPI-S a *very* inexpensive board, so I can understand Radxa wanting to 
> minimize the time spent configuring each one.
> https://shop.allnetchina.cn/products/rock-pi-s
> 
> The vendor driver seems to deal with this by applying typical gain parameters 
> when the eFUSE is invalid.
> With that driver, this board's WiFi performs beautifully, despite the 
> unprogrammed eFUSE.
> 
> Would you accept a patch to add this logic to RTW88?

Of course a patch would be accepted. Ultimately, the changes should be made to 
the wireless-next code base, and sent to this mailing list. To make things 
easier, you can send me a patch file for the rtw88 repo, and I can reformat it 
for wireless-next and send it to the mailing list under your signed-off-by. 
Either one would work.

Thanks for sorting this out. I like the idea of deriving the MAC address from 
the CPU serial number. That is unique and reproducible.

Larry

Re: rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

[Kalle Valo]

Larry Finger <Larry.Finger@lwfinger.net> writes:

> On 2/17/24 23:13, Brent Roman wrote:
>> Larry,
>> Radxa confirmed that they do not program the eFUSE on these boards.
>> We do not get a sensible MAC from the chip, so I derive a one from
>> the CPU's unique serial number.
>> It's a hack, but it works well and is standard's compliant.
>> The RockPI-S a *very* inexpensive board, so I can understand Radxa
>> wanting to minimize the time spent configuring each one.
>> https://shop.allnetchina.cn/products/rock-pi-s
>> The vendor driver seems to deal with this by applying typical gain
>> parameters when the eFUSE is invalid.
>> With that driver, this board's WiFi performs beautifully, despite
>> the unprogrammed eFUSE.
>> Would you accept a patch to add this logic to RTW88?
>
> Of course a patch would be accepted. Ultimately, the changes should be
> made to the wireless-next code base, and sent to this mailing list. To
> make things easier, you can send me a patch file for the rtw88 repo,
> and I can reformat it for wireless-next and send it to the mailing
> list under your signed-off-by. Either one would work.
>
> Thanks for sorting this out. I like the idea of deriving the MAC
> address from the CPU serial number. That is unique and reproducible.

But make sure that the CPU serial number is really unique. If it's not
that can cause MAC address collisions which is not good.

Usually wireless drivers create a random address if a stored MAC address
is not available.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

[Brent Roman]

Yes, that's all true.  However...
Random MAC address assignment tends to cause devices to be assigned a 
different IP address on each reboot.
This often doesn't play nicely with port forwarding.

It's difficult to "prove" the RK3308 cpu serial numbers are unique, but 
they should be and the few I've tested have been.

- brent

Kalle Valo wrote:
> Larry Finger <Larry.Finger@lwfinger.net> writes:
>
>> On 2/17/24 23:13, Brent Roman wrote:
>>> Larry,
>>> Radxa confirmed that they do not program the eFUSE on these boards.
>>> We do not get a sensible MAC from the chip, so I derive a one from
>>> the CPU's unique serial number.
>>> It's a hack, but it works well and is standard's compliant.
>>> The RockPI-S a *very* inexpensive board, so I can understand Radxa
>>> wanting to minimize the time spent configuring each one.
>>> https://shop.allnetchina.cn/products/rock-pi-s
>>> The vendor driver seems to deal with this by applying typical gain
>>> parameters when the eFUSE is invalid.
>>> With that driver, this board's WiFi performs beautifully, despite
>>> the unprogrammed eFUSE.
>>> Would you accept a patch to add this logic to RTW88?
>> Of course a patch would be accepted. Ultimately, the changes should be
>> made to the wireless-next code base, and sent to this mailing list. To
>> make things easier, you can send me a patch file for the rtw88 repo,
>> and I can reformat it for wireless-next and send it to the mailing
>> list under your signed-off-by. Either one would work.
>>
>> Thanks for sorting this out. I like the idea of deriving the MAC
>> address from the CPU serial number. That is unique and reproducible.
> But make sure that the CPU serial number is really unique. If it's not
> that can cause MAC address collisions which is not good.
>
> Usually wireless drivers create a random address if a stored MAC address
> is not available.
>


-- 
  Brent Roman                                   MBARI
  Software Engineer               Tel: (831) 775-1808
  mailto:brent@mbari.org  http://www.mbari.org/~brent

Re: rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

[Kalle Valo]

Brent Roman <brent@mbari.org> writes:

> Yes, that's all true.  However... Random MAC address assignment tends
> to cause devices to be assigned a different IP address on each reboot.
> This often doesn't play nicely with port forwarding.

Sure, I wasn't claiming that using random addresses is the perfect
solution. But you could also set a fixed random address from user space
(hopefully that works with rtw88).

> It's difficult to "prove" the RK3308 cpu serial numbers are unique,
> but they should be and the few I've tested have been.

Please take into account that rtw88 driver can be used with all sort of
different CPUs, not just RK3308. This is why I pointed this out.

(please don't top post)

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

[Brent Roman]

Kalle Valo wrote:
> Brent Roman <brent@mbari.org> writes:
>
>> Yes, that's all true.  However... Random MAC address assignment tends
>> to cause devices to be assigned a different IP address on each reboot.
>> This often doesn't play nicely with port forwarding.
> Sure, I wasn't claiming that using random addresses is the perfect
> solution. But you could also set a fixed random address from user space
> (hopefully that works with rtw88).
>
>> It's difficult to "prove" the RK3308 cpu serial numbers are unique,
>> but they should be and the few I've tested have been.
> Please take into account that rtw88 driver can be used with all sort of
> different CPUs, not just RK3308. This is why I pointed this out.
>
> (please don't top post)
>
The script that replaces the driver's random MAC is in Armbian's User Space,
which is unique for each supported board.  So, the CPU is known.

- brent

Re: rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

[Larry Finger]

On 2/19/24 02:24, Kalle Valo wrote:
> Brent Roman <brent@mbari.org> writes:
> 
>> Yes, that's all true.  However... Random MAC address assignment tends
>> to cause devices to be assigned a different IP address on each reboot.
>> This often doesn't play nicely with port forwarding.
> 
> Sure, I wasn't claiming that using random addresses is the perfect
> solution. But you could also set a fixed random address from user space
> (hopefully that works with rtw88).

That will require a new module parameter, which the community does not want.
> 
>> It's difficult to "prove" the RK3308 cpu serial numbers are unique,
>> but they should be and the few I've tested have been.
> 
> Please take into account that rtw88 driver can be used with all sort of
> different CPUs, not just RK3308. This is why I pointed this out.

We should be able to modify the code to handle a number of CPUs. They all should 
have a unique identifier. On my 2 Intel-based systems, there is no CPU serial 
number, but there is a serial number attached to the system, In addition, this 
code will only be invoked if the MAC address in the EUSE is invalid.

Larry

Re: rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

[Kalle Valo]

Larry Finger <Larry.Finger@lwfinger.net> writes:

> On 2/19/24 02:24, Kalle Valo wrote:
>> Brent Roman <brent@mbari.org> writes:
>> 
>>> Yes, that's all true.  However... Random MAC address assignment tends
>>> to cause devices to be assigned a different IP address on each reboot.
>>> This often doesn't play nicely with port forwarding.
>> Sure, I wasn't claiming that using random addresses is the perfect
>> solution. But you could also set a fixed random address from user space
>> (hopefully that works with rtw88).
>
> That will require a new module parameter, which the community does not want.

Where is the new module parameter needed? I was thinking about changing
the mac address using the standard interface, for example 'ip' tool or
similar. I think mac80211 supports that (see ieee80211_change_mage) but
I haven't tested it.

I'm worried that we are talking about different things here so maybe
it's best that I'll wait for the actual patch before commenting more.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S

[Brent Roman]

The Radxa RockPi-S has a built-in RTL8723DS interfaced to a Rockchip 
RK3308 A35 ARM64 processor on one of its SDIO busses.

I maintain Armbian's support this board.

The built-in WiFi works perfectly with RTL's 8723ds.ko driver.
Recently, the rtw88 driver got support for SDIO.
https://lwn.net/Articles/925940/

However, when we attempt to enable the rtw88_8723ds module, WiFi does 
not work.

Specifically, the WiFi scan returns only the strongest AP while 
indicating that AP has a very weak signal.
No connections can be made.

Unloading the rtw88_8723ds modules to replace it with 8723ds immediately 
restores WiFi function without the need to reboot the system.

Has anyone tested the SDIO variant of this driver?
If so, on which board(s)?

I'd very much like to get this working.
Any tips for debugging, or just getting relevant info from the driver, 
would be appreciated.

Thanks!