Dears,
I working on adding support in mainline kernel for radxa-zero SBC.
https://www.cnx-software.com/2021/06/16/radxa-zero-sbc-quad-core-raspberry-pi-zero-w-alternative/
So far all seems to be working well on mainline 5.13.4 kernel except WiFi.
radxa-zero SBC uses SDIO attached AP6256 WiFi/BT module.
Chip seems to be communicating with brcmfmac driver - but kernel dmesg reports error like below.
(output is after kernel compile with:
CONFIG_BRCM_TRACING=y
CONFIG_BRCMDBG=y
and
echo 8 > /proc/sys/kernel/printk
modprobe brcmfmac debug=0x6)
5.13.4 dmesg from brcmfmac probing:
[ 138.188502] brcmfmac: brcmfmac_module_init No platform data available.
[ 138.189917] brcmfmac: brcmf_sdio_probe Enter
[ 138.194049] brcmfmac: F1 signature read @0x18000000=0x15294345
[ 138.199709] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4345/9
[ 138.207838] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:51 base 0x18000000 wrap 0x18100000
[ 138.214720] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:54 base 0x18001000 wrap 0x18101000
[ 138.223405] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:9 base 0x18002000 wrap 0x18102000
[ 138.232112] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:14 base 0x18003000 wrap 0x18103000
[ 138.240834] brcmfmac: brcmf_chip_cores_check [5 ] core 0x829:21 base 0x18004000 wrap 0x18104000
[ 138.249534] brcmfmac: brcmf_chip_cores_check [6 ] core 0x135:0 base 0x00000000 wrap 0x18107000
[ 138.258248] brcmfmac: brcmf_chip_cores_check [7 ] core 0x240:0 base 0x00000000 wrap 0x00000000
[ 138.266957] brcmfmac: brcmf_chip_set_passive Enter
[ 138.274227] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x198000 size=0 (0x0) sr=0 (0x0)
[ 138.279634] brcmfmac: brcmf_chip_get_raminfo: RAM size is undetermined
[ 138.286085] brcmfmac: brcmf_sdio_probe_attach: brcmf_chip_attach failed!
[ 138.292725] brcmfmac: brcmf_sdio_probe: brcmf_sdio_probe_attach failed
[ 138.299190] brcmfmac: brcmf_sdio_remove Enter
[ 138.303476] brcmfmac: brcmf_detach Enter
[ 138.307444] brcmfmac: brcmf_sdio_remove Disconnected
[ 138.312361] brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...
[ 138.319198] usbcore: registered new interface driver brcmfmac
i tested fw ver 7.45.96.61 and also a bit newer ver. (7.45.96.68). both are giving the same error. removing firmware changes nothing - so i think issue is in frcmfmac kernel code which is not ready yet for chip variant used in radxa-zero ap6256 wifi module.
Full kernel dmesg: https://pastebin.com/VT1tQUJY
May you pls advise me how to move forward with this issue?
+ linux-wireless, + Ondrej (who added support for 4345 rev 9)
On 7/25/2021 12:16 AM, Piotr Oniszczuk wrote:
>
>
>> Wiadomość napisana przez Arend van Spriel <[email protected]> w dniu 24.07.2021, o godz. 23:20:
>>
>>
>> I am not so sure what is going on so maybe you can apply the patch below and see what comes out.
>>
>> Regards,
>> Arend
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
>> index 4faab0170ffa..71fb34753528 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
>> @@ -691,9 +691,11 @@ static u32 brcmf_chip_tcm_ramsize(struct brcmf_core_priv *cr4)
>> nbb = (corecap & ARMCR4_TCBBNB_MASK) >> ARMCR4_TCBBNB_SHIFT;
>> totb = nab + nbb;
>>
>> + brcmf_err("corecap %x nab %u nbb %u\n", corecap, nab, nbb);
>> for (idx = 0; idx < totb; idx++) {
>> brcmf_chip_core_write32(cr4, ARMCR4_BANKIDX, idx);
>> bxinfo = brcmf_chip_core_read32(cr4, ARMCR4_BANKINFO);
>> + brcmf_err("[%3u] %08x\n", idx, bxinfo);
>> memsize += ((bxinfo & ARMCR4_BSZ_MASK) + 1) * ARMCR4_BSZ_MULT;
>> }
>>
>>
>
> Arend
>
> Pls find dmesg output with patch:
>
> [ 121.226458] brcmfmac: brcmfmac_module_init No platform data available.
> [ 121.227955] brcmfmac: brcmf_sdio_probe Enter
> [ 121.232119] brcmfmac: F1 signature read @0x18000000=0x15294345
> [ 121.237659] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4345/9
> [ 121.245832] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:51 base 0x18000000 wrap 0x18100000
> [ 121.252695] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:54 base 0x18001000 wrap 0x18101000
> [ 121.261363] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:9 base 0x18002000 wrap 0x18102000
> [ 121.270071] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:14 base 0x18003000 wrap 0x18103000
> [ 121.278783] brcmfmac: brcmf_chip_cores_check [5 ] core 0x829:21 base 0x18004000 wrap 0x18104000
> [ 121.287508] brcmfmac: brcmf_chip_cores_check [6 ] core 0x135:0 base 0x00000000 wrap 0x18107000
> [ 121.296206] brcmfmac: brcmf_chip_cores_check [7 ] core 0x240:0 base 0x00000000 wrap 0x00000000
> [ 121.304917] brcmfmac: brcmf_chip_set_passive Enter
> [ 121.312079] brcmfmac: brcmf_chip_tcm_ramsize: corecap 0 nab 0 nbb 0
Well. That explains the fact that RAM size ends up being zero. I want to
be sure the ARM CR4 core is up so can you retry using the patch below.
It is just getting bit more info, no fix.
Regards,
Arend
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 4faab0170ffa..b829ad2f3865 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -691,9 +691,12 @@ static u32 brcmf_chip_tcm_ramsize(struct
brcmf_core_priv *cr4)
nbb = (corecap & ARMCR4_TCBBNB_MASK) >> ARMCR4_TCBBNB_SHIFT;
totb = nab + nbb;
+ brcmf_err("up %d corecap %x nab %u nbb %u\n",
+ brcmf_chip_iscoreup(&cr4->pub), corecap, nab, nbb);
for (idx = 0; idx < totb; idx++) {
brcmf_chip_core_write32(cr4, ARMCR4_BANKIDX, idx);
bxinfo = brcmf_chip_core_read32(cr4, ARMCR4_BANKINFO);
+ brcmf_err("[%3u] %08x\n", idx, bxinfo);
memsize += ((bxinfo & ARMCR4_BSZ_MASK) + 1) *
ARMCR4_BSZ_MULT;
}
+ linux-wireless, + Ondrej
Hoi Piotr,
Please reply to all. This might interest others with a similar device.
On 7/26/2021 11:31 AM, Piotr Oniszczuk wrote:
> Arend,
>
> pls find dmesg with extra prints you proposed:
>
> [ 144.634234] brcmfmac: brcmfmac_module_init No platform data available.
> [ 144.638974] brcmfmac: brcmf_sdio_probe Enter
> [ 144.643057] brcmfmac: F1 signature read @0x18000000=0x15294345
> [ 144.648718] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4345/9
> [ 144.656662] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:51 base 0x18000000 wrap 0x18100000
> [ 144.663690] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:54 base 0x18001000 wrap 0x18101000
> [ 144.672346] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:9 base 0x18002000 wrap 0x18102000
> [ 144.681031] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:14 base 0x18003000 wrap 0x18103000
> [ 144.689683] brcmfmac: brcmf_chip_cores_check [5 ] core 0x829:21 base 0x18004000 wrap 0x18104000
> [ 144.698365] brcmfmac: brcmf_chip_cores_check [6 ] core 0x135:0 base 0x00000000 wrap 0x18107000
> [ 144.707019] brcmfmac: brcmf_chip_cores_check [7 ] core 0x240:0 base 0x00000000 wrap 0x00000000
> [ 144.715678] brcmfmac: brcmf_chip_set_passive Enter
> [ 144.722499] brcmfmac: brcmf_chip_tcm_ramsize: up 0 corecap 0 nab 0 nbb 0
I see. That helps. Let me come up with a patch for this.
[...]
> btw:
> to be sure about is my DT correct i done following tests:
> 1.boot my distro binary on other board with ap6256 (radxa-rockpi4b). works ok
> 2.selective disable wifi pwrseq and clock dt fragments. disabling stops chip detection so indirectly concluding my dt fragments seems to be ok
The fact that the wifi device is probed is enough proof. There may be
some additional clocks needed, but for now it looks like SDIO bus is
properly functioning to access the device.
Regards,
Arend
On 7/26/2021 11:37 AM, Arend van Spriel wrote:
> + linux-wireless, + Ondrej
>
> Hoi Piotr,
>
> Please reply to all. This might interest others with a similar device.
>
> On 7/26/2021 11:31 AM, Piotr Oniszczuk wrote:
>> Arend,
>>
>> pls find dmesg with extra prints you proposed:
>>
>> [ 144.634234] brcmfmac: brcmfmac_module_init No platform data available.
>> [ 144.638974] brcmfmac: brcmf_sdio_probe Enter
>> [ 144.643057] brcmfmac: F1 signature read @0x18000000=0x15294345
>> [ 144.648718] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4345/9
>> [ 144.656662] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:51
>> base 0x18000000 wrap 0x18100000
>> [ 144.663690] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:54
>> base 0x18001000 wrap 0x18101000
>> [ 144.672346] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:9
>> base 0x18002000 wrap 0x18102000
>> [ 144.681031] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:14
>> base 0x18003000 wrap 0x18103000
>> [ 144.689683] brcmfmac: brcmf_chip_cores_check [5 ] core 0x829:21
>> base 0x18004000 wrap 0x18104000
>> [ 144.698365] brcmfmac: brcmf_chip_cores_check [6 ] core 0x135:0
>> base 0x00000000 wrap 0x18107000
>> [ 144.707019] brcmfmac: brcmf_chip_cores_check [7 ] core 0x240:0
>> base 0x00000000 wrap 0x00000000
>> [ 144.715678] brcmfmac: brcmf_chip_set_passive Enter
>> [ 144.722499] brcmfmac: brcmf_chip_tcm_ramsize: up 0 corecap 0 nab 0
>> nbb 0
>
> I see. That helps. Let me come up with a patch for this.
>
> [...]
>
>> btw:
>> to be sure about is my DT correct i done following tests:
>> 1.boot my distro binary on other board with ap6256 (radxa-rockpi4b).
>> works ok
>> 2.selective disable wifi pwrseq and clock dt fragments. disabling
>> stops chip detection so indirectly concluding my dt fragments seems to
>> be ok
>
> The fact that the wifi device is probed is enough proof. There may be
> some additional clocks needed, but for now it looks like SDIO bus is
> properly functioning to access the device.
...but feel free to share the DT source so I can have a look.
Regards,
Arend
Arend,
pls find dmesg with extra prints you proposed:
[ 144.634234] brcmfmac: brcmfmac_module_init No platform data available.
[ 144.638974] brcmfmac: brcmf_sdio_probe Enter
[ 144.643057] brcmfmac: F1 signature read @0x18000000=0x15294345
[ 144.648718] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4345/9
[ 144.656662] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:51 base 0x18000000 wrap 0x18100000
[ 144.663690] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:54 base 0x18001000 wrap 0x18101000
[ 144.672346] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:9 base 0x18002000 wrap 0x18102000
[ 144.681031] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:14 base 0x18003000 wrap 0x18103000
[ 144.689683] brcmfmac: brcmf_chip_cores_check [5 ] core 0x829:21 base 0x18004000 wrap 0x18104000
[ 144.698365] brcmfmac: brcmf_chip_cores_check [6 ] core 0x135:0 base 0x00000000 wrap 0x18107000
[ 144.707019] brcmfmac: brcmf_chip_cores_check [7 ] core 0x240:0 base 0x00000000 wrap 0x00000000
[ 144.715678] brcmfmac: brcmf_chip_set_passive Enter
[ 144.722499] brcmfmac: brcmf_chip_tcm_ramsize: up 0 corecap 0 nab 0 nbb 0
[ 144.727030] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x198000 size=0 (0x0) sr=0 (0x0)
[ 144.734989] brcmfmac: brcmf_chip_get_raminfo: RAM size is undetermined
[ 144.741450] brcmfmac: brcmf_sdio_probe_attach: brcmf_chip_attach failed!
[ 144.748099] brcmfmac: brcmf_sdio_probe: brcmf_sdio_probe_attach failed
[ 144.754610] brcmfmac: brcmf_sdio_remove Enter
[ 144.758869] brcmfmac: brcmf_detach Enter
[ 144.762804] brcmfmac: brcmf_sdio_remove Disconnected
[ 144.767760] brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...
[ 144.774615] usbcore: registered new interface driver brcmfmac
DT i'm using: https://pastebin.com/yHAb6gn3
> Wiadomość napisana przez Arend van Spriel <[email protected]> w dniu 26.07.2021, o godz. 09:54:
>
> + linux-wireless, + Ondrej (who added support for 4345 rev 9)
>
> On 7/25/2021 12:16 AM, Piotr Oniszczuk wrote:
>>> Wiadomość napisana przez Arend van Spriel <[email protected]> w dniu 24.07.2021, o godz. 23:20:
>>>
>>>
>>> I am not so sure what is going on so maybe you can apply the patch below and see what comes out.
>>>
>>> Regards,
>>> Arend
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
>>> index 4faab0170ffa..71fb34753528 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
>>> @@ -691,9 +691,11 @@ static u32 brcmf_chip_tcm_ramsize(struct brcmf_core_priv *cr4)
>>> nbb = (corecap & ARMCR4_TCBBNB_MASK) >> ARMCR4_TCBBNB_SHIFT;
>>> totb = nab + nbb;
>>>
>>> + brcmf_err("corecap %x nab %u nbb %u\n", corecap, nab, nbb);
>>> for (idx = 0; idx < totb; idx++) {
>>> brcmf_chip_core_write32(cr4, ARMCR4_BANKIDX, idx);
>>> bxinfo = brcmf_chip_core_read32(cr4, ARMCR4_BANKINFO);
>>> + brcmf_err("[%3u] %08x\n", idx, bxinfo);
>>> memsize += ((bxinfo & ARMCR4_BSZ_MASK) + 1) * ARMCR4_BSZ_MULT;
>>> }
>>>
>>>
>> Arend
>> Pls find dmesg output with patch:
>> [ 121.226458] brcmfmac: brcmfmac_module_init No platform data available.
>> [ 121.227955] brcmfmac: brcmf_sdio_probe Enter
>> [ 121.232119] brcmfmac: F1 signature read @0x18000000=0x15294345
>> [ 121.237659] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4345/9
>> [ 121.245832] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:51 base 0x18000000 wrap 0x18100000
>> [ 121.252695] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:54 base 0x18001000 wrap 0x18101000
>> [ 121.261363] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:9 base 0x18002000 wrap 0x18102000
>> [ 121.270071] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:14 base 0x18003000 wrap 0x18103000
>> [ 121.278783] brcmfmac: brcmf_chip_cores_check [5 ] core 0x829:21 base 0x18004000 wrap 0x18104000
>> [ 121.287508] brcmfmac: brcmf_chip_cores_check [6 ] core 0x135:0 base 0x00000000 wrap 0x18107000
>> [ 121.296206] brcmfmac: brcmf_chip_cores_check [7 ] core 0x240:0 base 0x00000000 wrap 0x00000000
>> [ 121.304917] brcmfmac: brcmf_chip_set_passive Enter
>> [ 121.312079] brcmfmac: brcmf_chip_tcm_ramsize: corecap 0 nab 0 nbb 0
>
> Well. That explains the fact that RAM size ends up being zero. I want to be sure the ARM CR4 core is up so can you retry using the patch below. It is just getting bit more info, no fix.
>
> Regards,
> Arend
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> index 4faab0170ffa..b829ad2f3865 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> @@ -691,9 +691,12 @@ static u32 brcmf_chip_tcm_ramsize(struct brcmf_core_priv *cr4)
> nbb = (corecap & ARMCR4_TCBBNB_MASK) >> ARMCR4_TCBBNB_SHIFT;
> totb = nab + nbb;
>
> + brcmf_err("up %d corecap %x nab %u nbb %u\n",
> + brcmf_chip_iscoreup(&cr4->pub), corecap, nab, nbb);
> for (idx = 0; idx < totb; idx++) {
> brcmf_chip_core_write32(cr4, ARMCR4_BANKIDX, idx);
> bxinfo = brcmf_chip_core_read32(cr4, ARMCR4_BANKINFO);
> + brcmf_err("[%3u] %08x\n", idx, bxinfo);
> memsize += ((bxinfo & ARMCR4_BSZ_MASK) + 1) * ARMCR4_BSZ_MULT;
> }
>
Arend,
Neil Armstrong hinted me issue might be related to usage of memcpy() to/from an iomem mapping.
arm64 memcpy update (285133040e6c ("arm64: Import latest memcpy()/memmove() implementation")) triggers a memory abort when dram-access-quirk
is used on the G12A/G12B platforms.
I reverted https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mmc/host/meson-gx-mmc.c?h=v5.13.4&id=103a5348c22c3fca8b96c735a9e353b8a0801842
and got nicely working wifi.
So it looks root cause is amlogic specific - not brcmfmac.
Sorry for false report and many many thx for Your head-up!
br
> Wiadomość napisana przez Arend van Spriel <[email protected]> w dniu 26.07.2021, o godz. 11:39:
>
> On 7/26/2021 11:37 AM, Arend van Spriel wrote:
>> + linux-wireless, + Ondrej
>> Hoi Piotr,
>> Please reply to all. This might interest others with a similar device.
>> On 7/26/2021 11:31 AM, Piotr Oniszczuk wrote:
>>> Arend,
>>>
>>> pls find dmesg with extra prints you proposed:
>>>
>>> [ 144.634234] brcmfmac: brcmfmac_module_init No platform data available.
>>> [ 144.638974] brcmfmac: brcmf_sdio_probe Enter
>>> [ 144.643057] brcmfmac: F1 signature read @0x18000000=0x15294345
>>> [ 144.648718] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4345/9
>>> [ 144.656662] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:51 base 0x18000000 wrap 0x18100000
>>> [ 144.663690] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:54 base 0x18001000 wrap 0x18101000
>>> [ 144.672346] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:9 base 0x18002000 wrap 0x18102000
>>> [ 144.681031] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:14 base 0x18003000 wrap 0x18103000
>>> [ 144.689683] brcmfmac: brcmf_chip_cores_check [5 ] core 0x829:21 base 0x18004000 wrap 0x18104000
>>> [ 144.698365] brcmfmac: brcmf_chip_cores_check [6 ] core 0x135:0 base 0x00000000 wrap 0x18107000
>>> [ 144.707019] brcmfmac: brcmf_chip_cores_check [7 ] core 0x240:0 base 0x00000000 wrap 0x00000000
>>> [ 144.715678] brcmfmac: brcmf_chip_set_passive Enter
>>> [ 144.722499] brcmfmac: brcmf_chip_tcm_ramsize: up 0 corecap 0 nab 0 nbb 0
>> I see. That helps. Let me come up with a patch for this.
>> [...]
>>> btw:
>>> to be sure about is my DT correct i done following tests:
>>> 1.boot my distro binary on other board with ap6256 (radxa-rockpi4b). works ok
>>> 2.selective disable wifi pwrseq and clock dt fragments. disabling stops chip detection so indirectly concluding my dt fragments seems to be ok
>> The fact that the wifi device is probed is enough proof. There may be some additional clocks needed, but for now it looks like SDIO bus is properly functioning to access the device.
>
> ...but feel free to share the DT source so I can have a look.
>
> Regards,
> Arend
On 7/26/2021 2:21 PM, Piotr Oniszczuk wrote:
> Arend,
>
> Neil Armstrong hinted me issue might be related to usage of memcpy() to/from an iomem mapping.
> arm64 memcpy update (285133040e6c ("arm64: Import latest memcpy()/memmove() implementation")) triggers a memory abort when dram-access-quirk
> is used on the G12A/G12B platforms.
>
> I reverted https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mmc/host/meson-gx-mmc.c?h=v5.13.4&id=103a5348c22c3fca8b96c735a9e353b8a0801842
>
> and got nicely working wifi.
>
> So it looks root cause is amlogic specific - not brcmfmac.
>
> Sorry for false report and many many thx for Your head-up!
Hi Piotr,
Thanks for letting me know. I hadn't worked yet on the patch I had in
mind and I suspect it would not have helped.
Regards,
Arend