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!
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
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:[email protected] http://www.mbari.org/~brent
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
Larry Finger <[email protected]> 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
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 <[email protected]> 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:[email protected] http://www.mbari.org/~brent
Brent Roman <[email protected]> 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
Kalle Valo wrote:
> Brent Roman <[email protected]> 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
On 2/19/24 02:24, Kalle Valo wrote:
> Brent Roman <[email protected]> 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
Larry Finger <[email protected]> writes:
> On 2/19/24 02:24, Kalle Valo wrote:
>> Brent Roman <[email protected]> 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