Hi,
On 28/05/2019 09:19, 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 an alternate (working) module.
Following Mullner's thread, this is what I collected with various fixes found
on other repos :
===========><===================================================
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index d2f788d88668..aa434b787953 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -971,6 +971,7 @@ static const struct sdio_device_id brcmf_sdmmc_ids[] = {
BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43455),
BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4354),
BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4356),
+ BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4359),
BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_CYPRESS_4373),
{ /* end: all zeroes */ }
};
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 927d62b3d41b..21e947fb1537 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -681,7 +681,6 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv
*ci)
case BRCM_CC_43569_CHIP_ID:
case BRCM_CC_43570_CHIP_ID:
case BRCM_CC_4358_CHIP_ID:
- case BRCM_CC_4359_CHIP_ID:
case BRCM_CC_43602_CHIP_ID:
case BRCM_CC_4371_CHIP_ID:
return 0x180000;
@@ -691,6 +690,7 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv
*ci)
case BRCM_CC_4366_CHIP_ID:
case BRCM_CC_43664_CHIP_ID:
return 0x200000;
+ case BRCM_CC_4359_CHIP_ID:
case CY_CC_4373_CHIP_ID:
return 0x160000;
default:
@@ -1339,6 +1339,7 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
switch (pub->chip) {
case BRCM_CC_4354_CHIP_ID:
case BRCM_CC_4356_CHIP_ID:
+ case BRCM_CC_4359_CHIP_ID:
case BRCM_CC_4345_CHIP_ID:
/* explicitly check SR engine enable bit */
pmu_cc3_mask = BIT(2);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index a907d7b065fa..cf90a87bda60 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -617,6 +617,7 @@ BRCMF_FW_DEF(43430A1, "brcmfmac43430-sdio");
BRCMF_FW_DEF(43455, "brcmfmac43455-sdio");
BRCMF_FW_DEF(4354, "brcmfmac4354-sdio");
BRCMF_FW_DEF(4356, "brcmfmac4356-sdio");
+BRCMF_FW_DEF(4359, "brcmfmac4359-sdio");
BRCMF_FW_DEF(4373, "brcmfmac4373-sdio");
static const struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = {
@@ -637,6 +638,7 @@ static const struct brcmf_firmware_mapping
brcmf_sdio_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFFFFFC0, 43455),
BRCMF_FW_ENTRY(BRCM_CC_4354_CHIP_ID, 0xFFFFFFFF, 4354),
BRCMF_FW_ENTRY(BRCM_CC_4356_CHIP_ID, 0xFFFFFFFF, 4356),
+ BRCMF_FW_ENTRY(BRCM_CC_4359_CHIP_ID, 0xFFFFFFFF, 4359),
BRCMF_FW_ENTRY(CY_CC_4373_CHIP_ID, 0xFFFFFFFF, 4373)
};
diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index 4224902a8e22..00e3f624baf2 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -41,6 +41,7 @@
#define SDIO_DEVICE_ID_BROADCOM_43455 0xa9bf
#define SDIO_DEVICE_ID_BROADCOM_4354 0x4354
#define SDIO_DEVICE_ID_BROADCOM_4356 0x4356
+#define SDIO_DEVICE_ID_BROADCOM_4359 0x4359
#define SDIO_DEVICE_ID_CYPRESS_4373 0x4373
#define SDIO_VENDOR_ID_INTEL 0x0089
===========><===================================================
But the driver stalls, without any errors.
I haven't activated debug traces in the brcmfmac driver to investigate further.
Neil
>
> BCM4359 is also 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
> results in the BCM4359 device being identified but firmware 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 the 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 the last few 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’m happy building test kernels but I don’t write code so I can be fed
> patches and can provide logs/output as long as the instructions are fairly
> explicit. I’ve also CC’d LibreELEC colleague and linux-amlogic maintainer
> Neil Armstrong who has vastly superior skills to myself and can assist. NB:
> If direct access to hardware would help progress things I can easily organise
> remote access or get board samples shipped.
>
> How to resume things again?
>
> Christian
>
