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
