Hello Arend,
Last October Christoph Müllner reported BCM4359 SDIO issues here: https://www.spinics.net/lists/linux-wireless/msg178783.html but the investigation stalled after the needs/timescale of his project forced a change to a different (working) module.
BCM4359 is being used in an increasing number of Amlogic devices the Kodi focussed distro LibreELEC supports. I’m one of the maintainers for the distro and I’d like to assist/resume the investigation.
To recap: using changes from Wright Feng that can be found here https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0050-brcmfmac-Add-support-for-BCM4359-SDIO-chipset.patch result in the BCM4359 device being identified but firmware/nvram loading fails:
[ 8.557929] brcmfmac: F1 signature read @0x18000000=0x17294359
[ 8.562087] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
[ 8.775655] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[ 8.775667] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f0c0
[ 8.775670] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed
See: http://ix.io/1KfY for the full dmesg output on 5.1-rc1 kernel including a splat that may or may not be related/relevant. I am using firmware and nvram files from https://github.com/LibreELEC/brcmfmac_sdio-firmware which match files found in several other github and public repo locations. The firmware/nvram are reported working in Android.
BCMDHD is also reported working with commits here: https://gitlab.com/baylibre/amlogic/atv/linux/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd but LibreELEC needs to support many different boards (with many different SDIO modules) from a single OS image, so BCMDHD is not the solution we need.
One additional patch I spotted mentioning BCM4359 (also from Wright Feng) was https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0073-non-upstream-reset-two-D11-cores-if-chip-has-two-D11.patch but it makes no difference (the dmesg log above is with this patch applied).
I don’t write code but am happy to build test kernels with suggested patches or explicit instructions. I’ve also CC’d LibreELEC colleague and linux-amlogic maintainer Neil Armstrong who can assist. NB: If direct access to hardware would help progress things I can easily organise remote access or get board samples shipped.
How can we resume the investigation?
Christian
On 6/8/2019 5:39 AM, Christian Hewitt wrote:
> Hello Arend,
>
> Last October Christoph Müllner reported BCM4359 SDIO issues here: https://www.spinics.net/lists/linux-wireless/msg178783.html but the investigation stalled after the needs/timescale of his project forced a change to a different (working) module.
>
> BCM4359 is being used in an increasing number of Amlogic devices the Kodi focussed distro LibreELEC supports. I’m one of the maintainers for the distro and I’d like to assist/resume the investigation.
>
> To recap: using changes from Wright Feng that can be found here https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0050-brcmfmac-Add-support-for-BCM4359-SDIO-chipset.patch result in the BCM4359 device being identified but firmware/nvram loading fails:
>
> [ 8.557929] brcmfmac: F1 signature read @0x18000000=0x17294359
> [ 8.562087] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
> [ 8.775655] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
> [ 8.775667] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f0c0
> [ 8.775670] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed
It seems to fail when reading back the nvram file to assure it was
downloaded properly.
> See: http://ix.io/1KfY for the full dmesg output on 5.1-rc1 kernel including a splat that may or may not be related/relevant. I am using firmware and nvram files from https://github.com/LibreELEC/brcmfmac_sdio-firmware which match files found in several other github and public repo locations. The firmware/nvram are reported working in Android.
The splat could be relevant. Maybe try the patch below to get actual
values that are checked in the WARN_ON.
> BCMDHD is also reported working with commits here: https://gitlab.com/baylibre/amlogic/atv/linux/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd but LibreELEC needs to support many different boards (with many different SDIO modules) from a single OS image, so BCMDHD is not the solution we need.
>
> One additional patch I spotted mentioning BCM4359 (also from Wright Feng) was https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0073-non-upstream-reset-two-D11-cores-if-chip-has-two-D11.patch but it makes no difference (the dmesg log above is with this patch applied).
>
> I don’t write code but am happy to build test kernels with suggested patches or explicit instructions. I’ve also CC’d LibreELEC colleague and linux-amlogic maintainer Neil Armstrong who can assist. NB: If direct access to hardware would help progress things I can easily organise remote access or get board samples shipped.
>
> How can we resume the investigation?
Let's try one step at a time ;-)
Regards,
Arend
---
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
b/driver
index fc12598..e9b0986 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -772,7 +772,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev
*sdiod
sdiodev->settings->bus.sdio.txglomsz);
nents += (nents >> 4) + 1;
- WARN_ON(nents > sdiodev->max_segment_count);
+ WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u,
host_max_seg=
+ sdiodev->max_segment_count, host->max_segs, nents);
brcmf_dbg(TRACE, "nents=%d\n", nents);
err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
q
> On 11 Jun 2019, at 1:45 pm, Arend Van Spriel <[email protected]> wrote:
[snip]
> The splat could be relevant. Maybe try the patch below to get actual values that are checked in the WARN_ON.
Hi Arend,
I think the patch got mangled in transit - it wouldn’t compile. Can you please resend, perhaps share via a paste site?
Christian
On 11 Jun 2019, at 1:45 pm, Arend Van Spriel <[email protected]> wrote:
>
> The splat could be relevant. Maybe try the patch below to get actual values that are checked in the WARN_ON.
>
>> BCMDHD is also reported working with commits here: https://gitlab.com/baylibre/amlogic/atv/linux/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd but LibreELEC needs to support many different boards (with many different SDIO modules) from a single OS image, so BCMDHD is not the solution we need.
>> One additional patch I spotted mentioning BCM4359 (also from Wright Feng) was https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0073-non-upstream-reset-two-D11-cores-if-chip-has-two-D11.patch but it makes no difference (the dmesg log above is with this patch applied).
>> I don’t write code but am happy to build test kernels with suggested patches or explicit instructions. I’ve also CC’d LibreELEC colleague and linux-amlogic maintainer Neil Armstrong who can assist. NB: If direct access to hardware would help progress things I can easily organise remote access or get board samples shipped.
>> How can we resume the investigation?
>
> Let's try one step at a time ;-)
>
> Regards,
> Arend
> ---
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/driver
> index fc12598..e9b0986 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -772,7 +772,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev *sdiod
> sdiodev->settings->bus.sdio.txglomsz);
> nents += (nents >> 4) + 1;
>
> - WARN_ON(nents > sdiodev->max_segment_count);
> + WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u, host_max_seg=
> + sdiodev->max_segment_count, host->max_segs, nents);
>
> brcmf_dbg(TRACE, "nents=%d\n", nents);
> err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
> q
^ this patch is mangled - please send me the correct one so I can reply with information to move things forwards. Thanks.
Christian
Hi Christian,
Here it is. Hopefully unmangled this time.
Regards,
Arend
---
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index ec129864cc9c..7be8064c6dc7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -785,7 +785,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev
*sdiodev)
sdiodev->settings->bus.sdio.txglomsz);
nents += (nents >> 4) + 1;
- WARN_ON(nents > sdiodev->max_segment_count);
+ WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u,
host_max_seg=%u, nents=%u\n",
+ sdiodev->max_segment_count, host->max_segs, nents);
brcmf_dbg(TRACE, "nents=%d\n", nents);
err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
> On 24 Jun 2019, at 8:04 pm, Arend Van Spriel <[email protected]> wrote:
>
> Hi Christian,
>
> Here it is. Hopefully unmangled this time.
Hi Arend.
The extra logging patch is un-mangled and applies fine, but I bumped to 5.2-rc4 recently (and now 5.2-rc7) and hit a major problem.
If I add the BCM4359 device ID’s with the following commit I see a brcmfmac splat and the system fails to boot.
commit: https://github.com/chewitt/linux/commit/f07161815699a48e636600a0b835d7ff64715383
splat: https://imgur.com/a/28wu5kh
defconfig: https://github.com/chewitt/LibreELEC.tv/blob/amlogic-master/projects/Amlogic/linux/linux.aarch64.conf
Adding the extra logging changes you suggested is not the issue, it’s adding the device ID’s.
I was previously using 5.1-rc1 and 5.1.9 kernels and didn’t see any issues adding the ID’s.
Any ideas?
Christian
> On 24 Jun 2019, at 11:04 pm, Arend Van Spriel <[email protected]> wrote:
>
> Hi Christian,
>
> Here it is. Hopefully unmangled this time.
>
> Regards,
> Arend
> ---
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index ec129864cc9c..7be8064c6dc7 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -785,7 +785,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev *sdiodev)
> sdiodev->settings->bus.sdio.txglomsz);
> nents += (nents >> 4) + 1;
>
> - WARN_ON(nents > sdiodev->max_segment_count);
> + WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u, host_max_seg=%u, nents=%u\n",
> + sdiodev->max_segment_count, host->max_segs, nents);
>
> brcmf_dbg(TRACE, "nents=%d\n", nents);
> err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
Hello Arend,
I’ve resumed testing on 5.4-rc8 with ^ this patch and https://github.com/chewitt/linux/commit/07fd0f25ceb72b15aa8c3fbd149aa41cbc55d035 applied and brcmfmac.debug=30 in boot params. Here is more extended output:
[ 6.115132] brcmfmac: brcmfmac_module_init No platform data available.
[ 6.116841] brcmfmac: brcmf_sdio_probe Enter
[ 6.118695] brcmfmac: F1 signature read @0x18000000=0x17294359
[ 6.118910] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4359/9
[ 6.120687] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:52 base 0x18000000 wrap 0x18100000
[ 6.120692] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:59 base 0x18001000 wrap 0x18101000
[ 6.120695] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:8 base 0x18002000 wrap 0x18102000
[ 6.120697] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:21 base 0x18003000 wrap 0x18103000
[ 6.120698] brcmfmac: brcmf_chip_cores_check [5 ] core 0x812:59 base 0x18004000 wrap 0x18104000
[ 6.120700] brcmfmac: brcmf_chip_cores_check [6 ] core 0x829:22 base 0x18005000 wrap 0x18105000
[ 6.120702] brcmfmac: brcmf_chip_cores_check [7 ] core 0x840:5 base 0x1800a000 wrap 0x00000000
[ 6.120703] brcmfmac: brcmf_chip_cores_check [8 ] core 0x135:0 base 0x00000000 wrap 0x18109000
[ 6.120704] brcmfmac: brcmf_chip_cores_check [9 ] core 0x240:0 base 0x00000000 wrap 0x00000000
[ 6.120706] brcmfmac: brcmf_chip_set_passive Enter
[ 6.121378] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x180000 size=917504 (0xe0000) sr=0 (0x0)
[ 6.121438] brcmfmac: brcmf_chip_setup ccrev=52, pmurev=26, pmucaps=0x3a0c3f1a
[ 6.121441] brcmfmac: brcmf_get_module_param Enter, bus=0, chip=17241, rev=9
[ 6.121618] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
[ 6.121621] brcmfmac: brcmf_sdio_kso_init Enter
[ 6.121635] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO driver strength init needed for chip BCM4359/9 rev 9 pmurev 26
[ 6.121998] brcmfmac: brcmf_sdio_probe completed!!
[ 6.122003] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
[ 6.122008] brcmfmac: brcmf_fw_get_firmwares enter: dev=mmc0:0001:1
[ 6.293561] brcmfmac: brcmf_fw_complete_request firmware brcm/brcmfmac4359-sdio.bin found
[ 6.309769] brcmfmac: brcmf_fw_complete_request firmware brcm/brcmfmac4359-sdio.txt found
[ 6.309772] brcmfmac: brcmf_fw_request_nvram_done enter: dev=mmc0:0001:1
[ 6.309840] brcmfmac: brcmf_fw_request_nvram_done nvram 000000007040259b len 3564
[ 6.309843] brcmfmac: brcmf_sdio_firmware_callback Enter: dev=mmc0:0001:1, err=0
[ 8.206959] brcmfmac: brcmf_sdio_download_code_file Enter
[ 8.272184] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x00180000; size=636647
[ 8.354229] brcmfmac: brcmf_sdio_download_nvram Enter
[ 8.359730] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x0025f214; size=3564
[ 8.367550] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[ 8.373550] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f214
[ 8.382188] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed
[ 8.389982] brcmfmac: brcmf_sdio_firmware_callback failed: dev=mmc0:0001:1, err=-5
[ 8.397514] brcmfmac: brcmf_sdio_remove Enter
[ 8.402641] brcmfmac: brcmf_detach Enter
[ 8.434899] brcmfmac: brcmf_chip_set_passive Enter
[ 8.458772] brcmfmac: brcmf_sdio_remove Disconnected
I’m using renamed nvram.txt and fw_bcm4359c0_ag_apsta.bin from the bcmdhd.1.579.77.41.x driver (https://github.com/chewitt/bcmdhd/). In the full dmesg: https://pastebin.com/raw/DUUGSjWw there is some kernel splat starting 6.121488 that appears to be from probing. FWIW, the BT side of the device appears to be working fine.
Any suggestions?
Christian
On 11/21/2019 4:52 AM, Christian Hewitt wrote:
>
>> On 24 Jun 2019, at 11:04 pm, Arend Van Spriel <[email protected]> wrote:
>>
>> Hi Christian,
>>
>> Here it is. Hopefully unmangled this time.
>>
>> Regards,
>> Arend
>> ---
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>> index ec129864cc9c..7be8064c6dc7 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>> @@ -785,7 +785,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev *sdiodev)
>> sdiodev->settings->bus.sdio.txglomsz);
>> nents += (nents >> 4) + 1;
>>
>> - WARN_ON(nents > sdiodev->max_segment_count);
>> + WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u, host_max_seg=%u, nents=%u\n",
>> + sdiodev->max_segment_count, host->max_segs, nents);
>>
>> brcmf_dbg(TRACE, "nents=%d\n", nents);
>> err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
>
> Hello Arend,
>
> I’ve resumed testing on 5.4-rc8 with ^ this patch and https://github.com/chewitt/linux/commit/07fd0f25ceb72b15aa8c3fbd149aa41cbc55d035 applied and brcmfmac.debug=30 in boot params. Here is more extended output:
>
> [ 6.115132] brcmfmac: brcmfmac_module_init No platform data available.
> [ 6.116841] brcmfmac: brcmf_sdio_probe Enter
> [ 6.118695] brcmfmac: F1 signature read @0x18000000=0x17294359
> [ 6.118910] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4359/9
> [ 6.120687] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:52 base 0x18000000 wrap 0x18100000
> [ 6.120692] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:59 base 0x18001000 wrap 0x18101000
> [ 6.120695] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:8 base 0x18002000 wrap 0x18102000
> [ 6.120697] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:21 base 0x18003000 wrap 0x18103000
> [ 6.120698] brcmfmac: brcmf_chip_cores_check [5 ] core 0x812:59 base 0x18004000 wrap 0x18104000
> [ 6.120700] brcmfmac: brcmf_chip_cores_check [6 ] core 0x829:22 base 0x18005000 wrap 0x18105000
> [ 6.120702] brcmfmac: brcmf_chip_cores_check [7 ] core 0x840:5 base 0x1800a000 wrap 0x00000000
> [ 6.120703] brcmfmac: brcmf_chip_cores_check [8 ] core 0x135:0 base 0x00000000 wrap 0x18109000
> [ 6.120704] brcmfmac: brcmf_chip_cores_check [9 ] core 0x240:0 base 0x00000000 wrap 0x00000000
> [ 6.120706] brcmfmac: brcmf_chip_set_passive Enter
> [ 6.121378] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x180000 size=917504 (0xe0000) sr=0 (0x0)
> [ 6.121438] brcmfmac: brcmf_chip_setup ccrev=52, pmurev=26, pmucaps=0x3a0c3f1a
> [ 6.121441] brcmfmac: brcmf_get_module_param Enter, bus=0, chip=17241, rev=9
> [ 6.121618] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
> [ 6.121621] brcmfmac: brcmf_sdio_kso_init Enter
> [ 6.121635] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO driver strength init needed for chip BCM4359/9 rev 9 pmurev 26
> [ 6.121998] brcmfmac: brcmf_sdio_probe completed!!
> [ 6.122003] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
> [ 6.122008] brcmfmac: brcmf_fw_get_firmwares enter: dev=mmc0:0001:1
> [ 6.293561] brcmfmac: brcmf_fw_complete_request firmware brcm/brcmfmac4359-sdio.bin found
> [ 6.309769] brcmfmac: brcmf_fw_complete_request firmware brcm/brcmfmac4359-sdio.txt found
> [ 6.309772] brcmfmac: brcmf_fw_request_nvram_done enter: dev=mmc0:0001:1
> [ 6.309840] brcmfmac: brcmf_fw_request_nvram_done nvram 000000007040259b len 3564
> [ 6.309843] brcmfmac: brcmf_sdio_firmware_callback Enter: dev=mmc0:0001:1, err=0
> [ 8.206959] brcmfmac: brcmf_sdio_download_code_file Enter
> [ 8.272184] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x00180000; size=636647
> [ 8.354229] brcmfmac: brcmf_sdio_download_nvram Enter
> [ 8.359730] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x0025f214; size=3564
> [ 8.367550] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
> [ 8.373550] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f214
> [ 8.382188] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed
> [ 8.389982] brcmfmac: brcmf_sdio_firmware_callback failed: dev=mmc0:0001:1, err=-5
> [ 8.397514] brcmfmac: brcmf_sdio_remove Enter
> [ 8.402641] brcmfmac: brcmf_detach Enter
> [ 8.434899] brcmfmac: brcmf_chip_set_passive Enter
> [ 8.458772] brcmfmac: brcmf_sdio_remove Disconnected
>
> I’m using renamed nvram.txt and fw_bcm4359c0_ag_apsta.bin from the bcmdhd.1.579.77.41.x driver (https://github.com/chewitt/bcmdhd/). In the full dmesg: https://pastebin.com/raw/DUUGSjWw there is some kernel splat starting 6.121488 that appears to be from probing. FWIW, the BT side of the device appears to be working fine.
>
> Any suggestions?
This is a differing issue, right? Sorry it has been a while back and I
did not search for your earlier emails.
The error -84 is -EILSEQ which we get from SDIO layer. I think this is
returned when CRC errors occur on the SDIO bus. It would trigger a
retune in the host controller.
Were you seeing similar issues on earlier kernel?
Regards,
Arend
> On 21 Nov 2019, at 1:00 pm, Arend Van Spriel <[email protected]> wrote:
>
> On 11/21/2019 4:52 AM, Christian Hewitt wrote:
>>> On 24 Jun 2019, at 11:04 pm, Arend Van Spriel <[email protected]> wrote:
>>>
>>> Hi Christian,
>>>
>>> Here it is. Hopefully unmangled this time.
>>>
>>> Regards,
>>> Arend
>>> ---
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>> index ec129864cc9c..7be8064c6dc7 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>> @@ -785,7 +785,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev *sdiodev)
>>> sdiodev->settings->bus.sdio.txglomsz);
>>> nents += (nents >> 4) + 1;
>>>
>>> - WARN_ON(nents > sdiodev->max_segment_count);
>>> + WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u, host_max_seg=%u, nents=%u\n",
>>> + sdiodev->max_segment_count, host->max_segs, nents);
>>>
>>> brcmf_dbg(TRACE, "nents=%d\n", nents);
>>> err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
>> Hello Arend,
>> I’ve resumed testing on 5.4-rc8 with ^ this patch and https://github.com/chewitt/linux/commit/07fd0f25ceb72b15aa8c3fbd149aa41cbc55d035 applied and brcmfmac.debug=30 in boot params. Here is more extended output:
>> [ 6.115132] brcmfmac: brcmfmac_module_init No platform data available.
>> [ 6.116841] brcmfmac: brcmf_sdio_probe Enter
>> [ 6.118695] brcmfmac: F1 signature read @0x18000000=0x17294359
>> [ 6.118910] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4359/9
>> [ 6.120687] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:52 base 0x18000000 wrap 0x18100000
>> [ 6.120692] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:59 base 0x18001000 wrap 0x18101000
>> [ 6.120695] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:8 base 0x18002000 wrap 0x18102000
>> [ 6.120697] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:21 base 0x18003000 wrap 0x18103000
>> [ 6.120698] brcmfmac: brcmf_chip_cores_check [5 ] core 0x812:59 base 0x18004000 wrap 0x18104000
>> [ 6.120700] brcmfmac: brcmf_chip_cores_check [6 ] core 0x829:22 base 0x18005000 wrap 0x18105000
>> [ 6.120702] brcmfmac: brcmf_chip_cores_check [7 ] core 0x840:5 base 0x1800a000 wrap 0x00000000
>> [ 6.120703] brcmfmac: brcmf_chip_cores_check [8 ] core 0x135:0 base 0x00000000 wrap 0x18109000
>> [ 6.120704] brcmfmac: brcmf_chip_cores_check [9 ] core 0x240:0 base 0x00000000 wrap 0x00000000
>> [ 6.120706] brcmfmac: brcmf_chip_set_passive Enter
>> [ 6.121378] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x180000 size=917504 (0xe0000) sr=0 (0x0)
>> [ 6.121438] brcmfmac: brcmf_chip_setup ccrev=52, pmurev=26, pmucaps=0x3a0c3f1a
>> [ 6.121441] brcmfmac: brcmf_get_module_param Enter, bus=0, chip=17241, rev=9
>> [ 6.121618] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
>> [ 6.121621] brcmfmac: brcmf_sdio_kso_init Enter
>> [ 6.121635] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO driver strength init needed for chip BCM4359/9 rev 9 pmurev 26
>> [ 6.121998] brcmfmac: brcmf_sdio_probe completed!!
>> [ 6.122003] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
>> [ 6.122008] brcmfmac: brcmf_fw_get_firmwares enter: dev=mmc0:0001:1
>> [ 6.293561] brcmfmac: brcmf_fw_complete_request firmware brcm/brcmfmac4359-sdio.bin found
>> [ 6.309769] brcmfmac: brcmf_fw_complete_request firmware brcm/brcmfmac4359-sdio.txt found
>> [ 6.309772] brcmfmac: brcmf_fw_request_nvram_done enter: dev=mmc0:0001:1
>> [ 6.309840] brcmfmac: brcmf_fw_request_nvram_done nvram 000000007040259b len 3564
>> [ 6.309843] brcmfmac: brcmf_sdio_firmware_callback Enter: dev=mmc0:0001:1, err=0
>> [ 8.206959] brcmfmac: brcmf_sdio_download_code_file Enter
>> [ 8.272184] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x00180000; size=636647
>> [ 8.354229] brcmfmac: brcmf_sdio_download_nvram Enter
>> [ 8.359730] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x0025f214; size=3564
>> [ 8.367550] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
>> [ 8.373550] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f214
>> [ 8.382188] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed
>> [ 8.389982] brcmfmac: brcmf_sdio_firmware_callback failed: dev=mmc0:0001:1, err=-5
>> [ 8.397514] brcmfmac: brcmf_sdio_remove Enter
>> [ 8.402641] brcmfmac: brcmf_detach Enter
>> [ 8.434899] brcmfmac: brcmf_chip_set_passive Enter
>> [ 8.458772] brcmfmac: brcmf_sdio_remove Disconnected
>> I’m using renamed nvram.txt and fw_bcm4359c0_ag_apsta.bin from the bcmdhd.1.579.77.41.x driver (https://github.com/chewitt/bcmdhd/). In the full dmesg: https://pastebin.com/raw/DUUGSjWw there is some kernel splat starting 6.121488 that appears to be from probing. FWIW, the BT side of the device appears to be working fine.
>> Any suggestions?
>
> This is a differing issue, right? Sorry it has been a while back and I did not search for your earlier emails.
>
> The error -84 is -EILSEQ which we get from SDIO layer. I think this is returned when CRC errors occur on the SDIO bus. It would trigger a retune in the host controller.
>
> Were you seeing similar issues on earlier kernel?
BCM4359 has mainline support for some time as a PCIe device. I’m attempting SDIO support by patching ID’s to the usual places.
I’ve seen the probing kernel splat on probing on all kernels I’ve attempted to use. I’ve been attempting since ~4.19.
I’m testing with a selection of Amlogic boards/boxes covering Amlogic’s GXM, G12A, G12B and SM1 platforms. The G12*/SM1 boards are based on the OEM vendor reference design with relatively minor variations between them. I have G12B boxes (same base platform) that work fine with other Ampak modules. I have devices of all varieties that have the same Ampak ap6398s module. In all cases the BT side works fine, but the WiFi shows the errors ^ above.
I don’t see any special handling for the BCM4359 in the bcmdhd code, but it appears to be grouped alongside 4349/4355 chips:
https://github.com/chewitt/bcmdhd/blob/f7009015df77fdeb35f9c7d6925f83861acc54f3/include/sbchipc.h#L3989
None of those chips appear in current mainline code under the SDIO path (4355 shows under PCIe) so my guess is that it’s not CRC errors, but these chips need a slightly different firmware loading process. I don’t see any special ifdef/handling for BCM4359 in the bcmdhd code, but then I’m not a coding developer so my ability to read and understand the code is limited.
Recent-ish bcmdhd code is known/working on the same hardware with minor nip/tuck changes:
https://gitlab.com/baylibre/amlogic/atv/linux/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd
Christian
On 12/10/2019 3:15 PM, Christian Hewitt wrote:
>
>> On 21 Nov 2019, at 8:01 pm, Christian Hewitt
>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> On 21 Nov 2019, at 1:00 pm, Arend Van Spriel
>>> <[email protected] <mailto:[email protected]>>
>>> wrote:
>>>
>>> On 11/21/2019 4:52 AM, Christian Hewitt wrote:
>>>>> On 24 Jun 2019, at 11:04 pm, Arend Van Spriel
>>>>> <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> Hi Christian,
>>>>>
>>>>> Here it is. Hopefully unmangled this time.
>>>>>
>>>>> Regards,
>>>>> Arend
>>>>> ---
>>>>> diff --git
>>>>> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>>> index ec129864cc9c..7be8064c6dc7 100644
>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>>> @@ -785,7 +785,8 @@ void brcmf_sdiod_sgtable_alloc(struct
>>>>> brcmf_sdio_dev *sdiodev)
>>>>> sdiodev->settings->bus.sdio.txglomsz);
>>>>> nents += (nents >> 4) + 1;
>>>>>
>>>>> - WARN_ON(nents > sdiodev->max_segment_count);
>>>>> + WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u,
>>>>> host_max_seg=%u, nents=%u\n",
>>>>> + sdiodev->max_segment_count, host->max_segs, nents);
>>>>>
>>>>> brcmf_dbg(TRACE, "nents=%d\n", nents);
>>>>> err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
>>>> Hello Arend,
>>>> I’ve resumed testing on 5.4-rc8 with ^ this patch and
>>>> https://github.com/chewitt/linux/commit/07fd0f25ceb72b15aa8c3fbd149aa41cbc55d035
>>>> applied and brcmfmac.debug=30 in boot params. Here is more extended
>>>> output:
>>>> [ 6.115132] brcmfmac: brcmfmac_module_init No platform data
>>>> available.
>>>> [ 6.116841] brcmfmac: brcmf_sdio_probe Enter
>>>> [ 6.118695] brcmfmac: F1 signature read @0x18000000=0x17294359
>>>> [ 6.118910] brcmfmac: brcmf_chip_recognition found AXI chip:
>>>> BCM4359/9
>>>> [ 6.120687] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:52
>>>> base 0x18000000 wrap 0x18100000
>>>> [ 6.120692] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:59
>>>> base 0x18001000 wrap 0x18101000
>>>> [ 6.120695] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:8
>>>> base 0x18002000 wrap 0x18102000
>>>> [ 6.120697] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:21
>>>> base 0x18003000 wrap 0x18103000
>>>> [ 6.120698] brcmfmac: brcmf_chip_cores_check [5 ] core 0x812:59
>>>> base 0x18004000 wrap 0x18104000
>>>> [ 6.120700] brcmfmac: brcmf_chip_cores_check [6 ] core 0x829:22
>>>> base 0x18005000 wrap 0x18105000
>>>> [ 6.120702] brcmfmac: brcmf_chip_cores_check [7 ] core 0x840:5
>>>> base 0x1800a000 wrap 0x00000000
>>>> [ 6.120703] brcmfmac: brcmf_chip_cores_check [8 ] core 0x135:0
>>>> base 0x00000000 wrap 0x18109000
>>>> [ 6.120704] brcmfmac: brcmf_chip_cores_check [9 ] core 0x240:0
>>>> base 0x00000000 wrap 0x00000000
>>>> [ 6.120706] brcmfmac: brcmf_chip_set_passive Enter
>>>> [ 6.121378] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x180000
>>>> size=917504 (0xe0000) sr=0 (0x0)
>>>> [ 6.121438] brcmfmac: brcmf_chip_setup ccrev=52, pmurev=26,
>>>> pmucaps=0x3a0c3f1a
>>>> [ 6.121441] brcmfmac: brcmf_get_module_param Enter, bus=0,
>>>> chip=17241, rev=9
>>>> [ 6.121618] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
>>>> [ 6.121621] brcmfmac: brcmf_sdio_kso_init Enter
>>>> [ 6.121635] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO driver
>>>> strength init needed for chip BCM4359/9 rev 9 pmurev 26
>>>> [ 6.121998] brcmfmac: brcmf_sdio_probe completed!!
>>>> [ 6.122003] brcmfmac: brcmf_fw_alloc_request: using
>>>> brcm/brcmfmac4359-sdio for chip BCM4359/9
>>>> [ 6.122008] brcmfmac: brcmf_fw_get_firmwares enter: dev=mmc0:0001:1
>>>> [ 6.293561] brcmfmac: brcmf_fw_complete_request firmware
>>>> brcm/brcmfmac4359-sdio.bin found
>>>> [ 6.309769] brcmfmac: brcmf_fw_complete_request firmware
>>>> brcm/brcmfmac4359-sdio.txt found
>>>> [ 6.309772] brcmfmac: brcmf_fw_request_nvram_done enter:
>>>> dev=mmc0:0001:1
>>>> [ 6.309840] brcmfmac: brcmf_fw_request_nvram_done nvram
>>>> 000000007040259b len 3564
>>>> [ 6.309843] brcmfmac: brcmf_sdio_firmware_callback Enter:
>>>> dev=mmc0:0001:1, err=0
>>>> [ 8.206959] brcmfmac: brcmf_sdio_download_code_file Enter
>>>> [ 8.272184] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul
>>>> at 0x00180000; size=636647
>>>> [ 8.354229] brcmfmac: brcmf_sdio_download_nvram Enter
>>>> [ 8.359730] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul
>>>> at 0x0025f214; size=3564
>>>> [ 8.367550] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
>>>> [ 8.373550] brcmfmac: brcmf_sdio_verifymemory: error -84 on
>>>> reading 2048 membytes at 0x0025f214
>>>> [ 8.382188] brcmfmac: brcmf_sdio_download_firmware: dongle nvram
>>>> file download failed
>>>> [ 8.389982] brcmfmac: brcmf_sdio_firmware_callback failed:
>>>> dev=mmc0:0001:1, err=-5
>>>> [ 8.397514] brcmfmac: brcmf_sdio_remove Enter
>>>> [ 8.402641] brcmfmac: brcmf_detach Enter
>>>> [ 8.434899] brcmfmac: brcmf_chip_set_passive Enter
>>>> [ 8.458772] brcmfmac: brcmf_sdio_remove Disconnected
>>>> I’m using renamed nvram.txt and fw_bcm4359c0_ag_apsta.bin from the
>>>> bcmdhd.1.579.77.41.x driver (https://github.com/chewitt/bcmdhd/). In
>>>> the full dmesg: https://pastebin.com/raw/DUUGSjWw there is some
>>>> kernel splat starting 6.121488 that appears to be from probing.
>>>> FWIW, the BT side of the device appears to be working fine.
>>>> Any suggestions?
>>>
>>> This is a differing issue, right? Sorry it has been a while back and
>>> I did not search for your earlier emails.
>>>
>>> The error -84 is -EILSEQ which we get from SDIO layer. I think this
>>> is returned when CRC errors occur on the SDIO bus. It would trigger a
>>> retune in the host controller.
>>>
>>> Were you seeing similar issues on earlier kernel?
>>
>> BCM4359 has mainline support for some time as a PCIe device. I’m
>> attempting SDIO support by patching ID’s to the usual places.
>>
>> I’ve seen the probing kernel splat on probing on all kernels I’ve
>> attempted to use. I’ve been attempting since ~4.19.
>>
>> I’m testing with a selection of Amlogic boards/boxes covering
>> Amlogic’s GXM, G12A, G12B and SM1 platforms. The G12*/SM1 boards are
>> based on the OEM vendor reference design with relatively minor
>> variations between them. I have G12B boxes (same base platform) that
>> work fine with other Ampak modules. I have devices of all varieties
>> that have the same Ampak ap6398s module. In all cases the BT side
>> works fine, but the WiFi shows the errors ^ above.
>>
>> I don’t see any special handling for the BCM4359 in the bcmdhd code,
>> but it appears to be grouped alongside 4349/4355 chips:
>>
>> https://github.com/chewitt/bcmdhd/blob/f7009015df77fdeb35f9c7d6925f83861acc54f3/include/sbchipc.h#L3989
>>
>> None of those chips appear in current mainline code under the SDIO
>> path (4355 shows under PCIe) so my guess is that it’s not CRC errors,
>> but these chips need a slightly different firmware loading process. I
>> don’t see any special ifdef/handling for BCM4359 in the bcmdhd code,
>> but then I’m not a coding developer so my ability to read and
>> understand the code is limited.
>>
>> Recent-ish bcmdhd code is known/working on the same hardware with
>> minor nip/tuck changes:
>>
>> https://gitlab.com/baylibre/amlogic/atv/linux/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd
>
> Arend, is there any more input/context I can provide?
>
> If it would help to have hardware with this chipset to explore what’s
> needed, it can be easily arranged.
Hi Christian,
I noticed some upstream patches for 4359 sdio from Cypress couple of
days ago. Here is one of the patches from v2 series:
https://patchwork.kernel.org/patch/11286555/
Regards,
Arend