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
