--
Christoph Müllner
Theobroma Systems Design und Consulting GmbH
Seestadtstraße 27 (Aspern IQ), 1220 Wien, Austria
Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9
http://www.theobroma-systems.com
Hi Christoph,
On Tue, Oct 9, 2018 at 11:10 AM Christoph Müllner
<[email protected]> wrote:
>
> Hi Arend,
>
> recently I got an SDIO module, which includes a BCM4359.
> I tried to get it up and running via the SD card interface
> on a RK3399 SoC and succeeded in doing so with
> bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4).
> All that was necessary was configure BCMDHD to run with
> in-band IRQs and use a GPIO as gpio_wl_reg_on.
>
> Since I can run a mainline kernel as well, I gave it a try and
> tried brcmfmac on Linux 4.19-rc7. As the BCM4359 is not in
> the list of supported SDIO devices, but is supported USB device,
> I've created a patch (attached), which adds the support for that device.
> Additionally I've patched my DTS to include the WL_REG_ON
> pin as part of mmc-pwrseq-simple's reset-gpios and added
> a bcm4329-fmac node in the mmc node.
>
> During bootup I see messages from brcmfmac, which indicate
> that the BCM4359 has been found, but loading the nvram file
> continuously fails:
>
> > [ 5.993741] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
> > [...]
> > [ 7.987167] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
> > [ 8.008715] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f1f0
> > [ 8.021182] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed
Does it always fail at nvram verification? If so please help to get
the address and varsz in brcmf_sdio_download_nvram. Also their
equivalent in bcmdhd which should be varaddr and varsize in
dhdsdio_write_vars.
Thanks,
--Franky
> That -84 means EILSEQ, which is the error value, which represents
> a CRC error during SDIO data exchange (returned by the function dw_mci_data_complete()
> in the MMC driver).
>
> To address this, I've reduced the clock speed (in several steps) to 400 kHz
> (and verified the clock signal on an oscilloscope), but the issue persists.
> I've also tried to use Linux 4.14.74, where I see the same issue.
>
> I can confirm that the MMC interface works in general (I can use an SD card
> to host my rootfs).
>
> FWIW I'm using the same exact same firmware and nvram file for the DHD driver
> and the brcmfmac.
>
> Do you have any ideas how to debug this issue?
>
> Thanks,
> Christoph
>
>
>
> --
> Christoph Müllner
> Theobroma Systems Design und Consulting GmbH
> Seestadtstraße 27 (Aspern IQ), 1220 Wien, Austria
> Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9
> http://www.theobroma-systems.com
>
>
>
>
On 10/9/2018 8:10 PM, Christoph Müllner wrote:
> Hi Arend,
>
> recently I got an SDIO module, which includes a BCM4359.
> I tried to get it up and running via the SD card interface
> on a RK3399 SoC and succeeded in doing so with
> bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4).
> All that was necessary was configure BCMDHD to run with
> in-band IRQs and use a GPIO as gpio_wl_reg_on.
>
> Since I can run a mainline kernel as well, I gave it a try and
> tried brcmfmac on Linux 4.19-rc7. As the BCM4359 is not in
> the list of supported SDIO devices, but is supported USB device,
> I've created a patch (attached), which adds the support for that device.
Okay. However, I should say that there is no BCM4359 USB device.
Regardless the patch looks okay.
> Additionally I've patched my DTS to include the WL_REG_ON
> pin as part of mmc-pwrseq-simple's reset-gpios and added
> a bcm4329-fmac node in the mmc node.
>
> During bootup I see messages from brcmfmac, which indicate
> that the BCM4359 has been found, but loading the nvram file
> continuously fails:
>
>> [ 5.993741] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
>> [...]
>> [ 7.987167] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
>> [ 8.008715] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f1f0
>> [ 8.021182] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed
>
> That -84 means EILSEQ, which is the error value, which represents
> a CRC error during SDIO data exchange (returned by the function dw_mci_data_complete()
> in the MMC driver).
Whenever I see -84 my suspicion are about power-supply for the chip.
However, it may also be the mmc host driver not adhering to so-called
"card busy" indication, which is in the SDIO spec.
> To address this, I've reduced the clock speed (in several steps) to 400 kHz
> (and verified the clock signal on an oscilloscope), but the issue persists.
> I've also tried to use Linux 4.14.74, where I see the same issue.
>
> I can confirm that the MMC interface works in general (I can use an SD card
> to host my rootfs).
SD and SDIO are not the same thing. More importantly you have it working
with bcmdhd on a vendor kernel. So start from there.
> FWIW I'm using the same exact same firmware and nvram file for the DHD driver
> and the brcmfmac.
Noted.
> Do you have any ideas how to debug this issue?
Would focus on getting logs from bcmdhd.
Regards,
Arend
> Thanks,
> Christoph
>
>
>
>
>
Hi Franky,
thank's for your help.
As the BCM4359 is already supported (as PCIe device) in the brcmfmac
driver, I assumed that base addresses will be correct.
But having a closer look it is indeed the problematic part.
I've temporary fixed the return value in brcmf_chip_tcm_rambase
to the one matching the DHD's output and the SDIO errors are gone:
bcmdhd (4.4):
[ 15.701860] dhdsdio_write_vars: varaddr=0x23f1e8
[ 15.707024] dhdsdio_write_vars: varsize=3604
[ 15.711830] dhdsdio_write_vars: bus->dongle_ram_base=0x160000
[ 15.718221] dhdsdio_write_vars: bus->ramsize=917504
[ 15.723649] dhdsdio_write_vars: bus->varsz=3601
[ 15.752063] dhdsdio_write_vars: Download, Upload and compare of NVRAM
succeeded.
brcmfmac (4.19):
[ 7.773752] brcmf_sdio_download_nvram: address=0x25f1f0
[ 7.782824] brcmf_sdio_download_nvram: bus->ci->ramsize=917504
[ 7.792544] brcmf_sdio_download_nvram: varsz=3600
[ 7.800926] brcmf_sdio_download_nvram: bus->ci->rambase=0x180000
[ 7.816106] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[ 7.835253] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading
2048 membytes at 0x0025f1f0
brcmfmac (4.19-fixedoffset):
[ 7.625436] brcmf_sdio_download_nvram: address=0x23f1f0
[ 7.634582] brcmf_sdio_download_nvram: bus->ci->ramsize=917504
[ 7.644284] brcmf_sdio_download_nvram: varsz=3600
[ 7.652641] brcmf_sdio_download_nvram: bus->ci->rambase=0x160000
Unfortunately I still don't get a wlan0 interface (and more important:
no error message from the brcmfmac driver).
I'm now trying to get brcmfmac's tracing features up and running
to see where the driver got stuck.
Anyways, thank you very much so far.
BR
Christoph
On 10/9/18 8:59 PM, Franky Lin wrote:
> Hi Christoph,
>
> On Tue, Oct 9, 2018 at 11:10 AM Christoph Müllner
> <[email protected]> wrote:
>>
>> Hi Arend,
>>
>> recently I got an SDIO module, which includes a BCM4359.
>> I tried to get it up and running via the SD card interface
>> on a RK3399 SoC and succeeded in doing so with
>> bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4).
>> All that was necessary was configure BCMDHD to run with
>> in-band IRQs and use a GPIO as gpio_wl_reg_on.
>>
>> Since I can run a mainline kernel as well, I gave it a try and
>> tried brcmfmac on Linux 4.19-rc7. As the BCM4359 is not in
>> the list of supported SDIO devices, but is supported USB device,
>> I've created a patch (attached), which adds the support for that device.
>> Additionally I've patched my DTS to include the WL_REG_ON
>> pin as part of mmc-pwrseq-simple's reset-gpios and added
>> a bcm4329-fmac node in the mmc node.
>>
>> During bootup I see messages from brcmfmac, which indicate
>> that the BCM4359 has been found, but loading the nvram file
>> continuously fails:
>>
>>> [ 5.993741] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
>>> [...]
>>> [ 7.987167] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
>>> [ 8.008715] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f1f0
>>> [ 8.021182] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed
>
> Does it always fail at nvram verification? If so please help to get
> the address and varsz in brcmf_sdio_download_nvram. Also their
> equivalent in bcmdhd which should be varaddr and varsize in
> dhdsdio_write_vars.
>
> Thanks,
> --Franky
>
>> That -84 means EILSEQ, which is the error value, which represents
>> a CRC error during SDIO data exchange (returned by the function dw_mci_data_complete()
>> in the MMC driver).
>>
>> To address this, I've reduced the clock speed (in several steps) to 400 kHz
>> (and verified the clock signal on an oscilloscope), but the issue persists.
>> I've also tried to use Linux 4.14.74, where I see the same issue.
>>
>> I can confirm that the MMC interface works in general (I can use an SD card
>> to host my rootfs).
>>
>> FWIW I'm using the same exact same firmware and nvram file for the DHD driver
>> and the brcmfmac.
>>
>> Do you have any ideas how to debug this issue?
>>
>> Thanks,
>> Christoph
>>
>>
>>
>> --
>> Christoph Müllner
>> Theobroma Systems Design und Consulting GmbH
>> Seestadtstraße 27 (Aspern IQ), 1220 Wien, Austria
>> Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9
>> http://www.theobroma-systems.com
>>
>>
>>
>>
Hi Franky and Arend,
today I could get a SDIO Wifi module, which includes a BCM43455.
I was able to get this up and running without any issues with the brcmfmac
driver and a 4.19 kernel. For me that's enough evidence to say that the SDIO
driver works.
However, the BCM4359 still does not work.
It times out in brcmf_sdio_firmware_callback(), while enabling func2.
I've inserted tons of debug log outputs in both, the DHD driver and the
brcmfmac driver, and compared them. Differences which I've found so far
are: a) brcmfmac strips out whitespaces from nvram contents and
b) DHD downloads firmware first and brcmfmac downloads nvram first.
I've adapted the DHD driver to behave like brcmfmac in both cases
and it still works.
I've increased the timeout for enabling func2 from 3 seconds to 10 seconds,
but that did not help.
Any ideas left?
Thanks,
Christoph
> On 09.10.2018, at 22:55, Christoph Müllner <[email protected]> wrote:
>
> Hi Franky,
>
> thank's for your help.
>
> As the BCM4359 is already supported (as PCIe device) in the brcmfmac
> driver, I assumed that base addresses will be correct.
> But having a closer look it is indeed the problematic part.
> I've temporary fixed the return value in brcmf_chip_tcm_rambase
> to the one matching the DHD's output and the SDIO errors are gone:
>
> bcmdhd (4.4):
> [ 15.701860] dhdsdio_write_vars: varaddr=0x23f1e8
> [ 15.707024] dhdsdio_write_vars: varsize=3604
> [ 15.711830] dhdsdio_write_vars: bus->dongle_ram_base=0x160000
> [ 15.718221] dhdsdio_write_vars: bus->ramsize=917504
> [ 15.723649] dhdsdio_write_vars: bus->varsz=3601
> [ 15.752063] dhdsdio_write_vars: Download, Upload and compare of NVRAM
> succeeded.
>
> brcmfmac (4.19):
> [ 7.773752] brcmf_sdio_download_nvram: address=0x25f1f0
> [ 7.782824] brcmf_sdio_download_nvram: bus->ci->ramsize=917504
> [ 7.792544] brcmf_sdio_download_nvram: varsz=3600
> [ 7.800926] brcmf_sdio_download_nvram: bus->ci->rambase=0x180000
> [ 7.816106] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
> [ 7.835253] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading
> 2048 membytes at 0x0025f1f0
>
> brcmfmac (4.19-fixedoffset):
> [ 7.625436] brcmf_sdio_download_nvram: address=0x23f1f0
> [ 7.634582] brcmf_sdio_download_nvram: bus->ci->ramsize=917504
> [ 7.644284] brcmf_sdio_download_nvram: varsz=3600
> [ 7.652641] brcmf_sdio_download_nvram: bus->ci->rambase=0x160000
>
> Unfortunately I still don't get a wlan0 interface (and more important:
> no error message from the brcmfmac driver).
> I'm now trying to get brcmfmac's tracing features up and running
> to see where the driver got stuck.
>
> Anyways, thank you very much so far.
>
> BR
> Christoph
>
>
> On 10/9/18 8:59 PM, Franky Lin wrote:
>> Hi Christoph,
>>
>> On Tue, Oct 9, 2018 at 11:10 AM Christoph Müllner
>> <[email protected]> wrote:
>>>
>>> Hi Arend,
>>>
>>> recently I got an SDIO module, which includes a BCM4359.
>>> I tried to get it up and running via the SD card interface
>>> on a RK3399 SoC and succeeded in doing so with
>>> bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4).
>>> All that was necessary was configure BCMDHD to run with
>>> in-band IRQs and use a GPIO as gpio_wl_reg_on.
>>>
>>> Since I can run a mainline kernel as well, I gave it a try and
>>> tried brcmfmac on Linux 4.19-rc7. As the BCM4359 is not in
>>> the list of supported SDIO devices, but is supported USB device,
>>> I've created a patch (attached), which adds the support for that device.
>>> Additionally I've patched my DTS to include the WL_REG_ON
>>> pin as part of mmc-pwrseq-simple's reset-gpios and added
>>> a bcm4329-fmac node in the mmc node.
>>>
>>> During bootup I see messages from brcmfmac, which indicate
>>> that the BCM4359 has been found, but loading the nvram file
>>> continuously fails:
>>>
>>>> [ 5.993741] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
>>>> [...]
>>>> [ 7.987167] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
>>>> [ 8.008715] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f1f0
>>>> [ 8.021182] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed
>>
>> Does it always fail at nvram verification? If so please help to get
>> the address and varsz in brcmf_sdio_download_nvram. Also their
>> equivalent in bcmdhd which should be varaddr and varsize in
>> dhdsdio_write_vars.
>>
>> Thanks,
>> --Franky
>>
>>> That -84 means EILSEQ, which is the error value, which represents
>>> a CRC error during SDIO data exchange (returned by the function dw_mci_data_complete()
>>> in the MMC driver).
>>>
>>> To address this, I've reduced the clock speed (in several steps) to 400 kHz
>>> (and verified the clock signal on an oscilloscope), but the issue persists.
>>> I've also tried to use Linux 4.14.74, where I see the same issue.
>>>
>>> I can confirm that the MMC interface works in general (I can use an SD card
>>> to host my rootfs).
>>>
>>> FWIW I'm using the same exact same firmware and nvram file for the DHD driver
>>> and the brcmfmac.
>>>
>>> Do you have any ideas how to debug this issue?
>>>
>>> Thanks,
>>> Christoph
>>>
>>>
>>>
>>> --
>>> Christoph Müllner
>>> Theobroma Systems Design und Consulting GmbH
>>> Seestadtstraße 27 (Aspern IQ), 1220 Wien, Austria
>>> Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9
>>> http://www.theobroma-systems.com
>>>
>>>
>>>
>>>
On 10/11/2018 6:04 PM, Christoph Müllner wrote:
> Hi Franky and Arend,
>
> today I could get a SDIO Wifi module, which includes a BCM43455.
> I was able to get this up and running without any issues with the brcmfmac
> driver and a 4.19 kernel. For me that's enough evidence to say that the SDIO
> driver works.
>
> However, the BCM4359 still does not work.
> It times out in brcmf_sdio_firmware_callback(), while enabling func2.
>
> I've inserted tons of debug log outputs in both, the DHD driver and the
> brcmfmac driver, and compared them. Differences which I've found so far
> are: a) brcmfmac strips out whitespaces from nvram contents and
> b) DHD downloads firmware first and brcmfmac downloads nvram first.
> I've adapted the DHD driver to behave like brcmfmac in both cases
> and it still works.
>
> I've increased the timeout for enabling func2 from 3 seconds to 10 seconds,
> but that did not help.
>
> Any ideas left?
When enabling func2 fails it generally means the firmware crashed. I am
not sure if the patch below works to get console information. It might
show up empty or simply fail if firmware did not fill shared memory
info, but it may be worth a try.
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/
index c99a191..739dbaa 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4109,7 +4109,7 @@ static void brcmf_sdio_firmware_callback(struct
device *d
} else {
/* Disable F2 again */
sdio_disable_func(sdiod->func2);
- goto release;
+ goto checkdied;
}
if (brcmf_chip_sr_capable(bus->ci)) {
@@ -4151,6 +4151,9 @@ static void brcmf_sdio_firmware_callback(struct
device *d
/* ready */
return;
+checkdied:
+ brcmf_sdio_checkdied(bus);
+ brcmf_sdio_readconsole(bus);
release:
sdio_release_host(sdiod->func1);
fail:
On 10/12/18 10:00 AM, Arend van Spriel wrote:
> On 10/11/2018 6:04 PM, Christoph Müllner wrote:
>> Hi Franky and Arend,
>>
>> today I could get a SDIO Wifi module, which includes a BCM43455.
>> I was able to get this up and running without any issues with the
>> brcmfmac
>> driver and a 4.19 kernel. For me that's enough evidence to say that
>> the SDIO
>> driver works.
>>
>> However, the BCM4359 still does not work.
>> It times out in brcmf_sdio_firmware_callback(), while enabling func2.
>>
>> I've inserted tons of debug log outputs in both, the DHD driver and the
>> brcmfmac driver, and compared them. Differences which I've found so far
>> are: a) brcmfmac strips out whitespaces from nvram contents and
>> b) DHD downloads firmware first and brcmfmac downloads nvram first.
>> I've adapted the DHD driver to behave like brcmfmac in both cases
>> and it still works.
>>
>> I've increased the timeout for enabling func2 from 3 seconds to 10
>> seconds,
>> but that did not help.
>>
>> Any ideas left?
>
> When enabling func2 fails it generally means the firmware crashed. I am
> not sure if the patch below works to get console information. It might
> show up empty or simply fail if firmware did not fill shared memory
> info, but it may be worth a try.
I added the patch and additionally added debug output for all error
cases in the two called functions. Here's the output:
[ 14.746092] brcmfmac: brcmf_sdio_firmware_callback: enable F2: err=-62
[ 14.767523] brcmfmac: brcmf_sdio_checkdied: firmware not built with
-assert
[ 14.778777] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[ 14.789220] brcmfmac: brcmf_sdio_readconsole: brcmf_sdio_readconsole:
bus->console_addr == 0!
Do you have an educated guess, what causes the firmware crash, when
being loaded via the brcmfmac driver?
Thanks,
Christoph
On 10/12/2018 10:59 AM, Christoph Müllner wrote:
>
>
> On 10/12/18 10:00 AM, Arend van Spriel wrote:
>> On 10/11/2018 6:04 PM, Christoph Müllner wrote:
>>> Hi Franky and Arend,
>>>
>>> today I could get a SDIO Wifi module, which includes a BCM43455.
>>> I was able to get this up and running without any issues with the
>>> brcmfmac
>>> driver and a 4.19 kernel. For me that's enough evidence to say that
>>> the SDIO
>>> driver works.
>>>
>>> However, the BCM4359 still does not work.
>>> It times out in brcmf_sdio_firmware_callback(), while enabling func2.
>>>
>>> I've inserted tons of debug log outputs in both, the DHD driver and the
>>> brcmfmac driver, and compared them. Differences which I've found so far
>>> are: a) brcmfmac strips out whitespaces from nvram contents and
>>> b) DHD downloads firmware first and brcmfmac downloads nvram first.
>>> I've adapted the DHD driver to behave like brcmfmac in both cases
>>> and it still works.
>>>
>>> I've increased the timeout for enabling func2 from 3 seconds to 10
>>> seconds,
>>> but that did not help.
>>>
>>> Any ideas left?
>>
>> When enabling func2 fails it generally means the firmware crashed. I am
>> not sure if the patch below works to get console information. It might
>> show up empty or simply fail if firmware did not fill shared memory
>> info, but it may be worth a try.
>
> I added the patch and additionally added debug output for all error
> cases in the two called functions. Here's the output:
>
> [ 14.746092] brcmfmac: brcmf_sdio_firmware_callback: enable F2: err=-62
> [ 14.767523] brcmfmac: brcmf_sdio_checkdied: firmware not built with
> -assert
> [ 14.778777] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
> [ 14.789220] brcmfmac: brcmf_sdio_readconsole: brcmf_sdio_readconsole:
> bus->console_addr == 0!
>
> Do you have an educated guess, what causes the firmware crash, when
> being loaded via the brcmfmac driver?
Let's look at the firmware+nvram you are using. Can you do:
$ strings brcmfmac4359-sdio.bin | tail -3
and send the output and the nvram file.
Regards,
Arend
On 10/12/2018 10:59 AM, Christoph Müllner wrote:
>
>
> On 10/12/18 10:00 AM, Arend van Spriel wrote:
>> On 10/11/2018 6:04 PM, Christoph Müllner wrote:
>>> Hi Franky and Arend,
>>>
>>> today I could get a SDIO Wifi module, which includes a BCM43455.
>>> I was able to get this up and running without any issues with the
>>> brcmfmac
>>> driver and a 4.19 kernel. For me that's enough evidence to say that
>>> the SDIO
>>> driver works.
>>>
>>> However, the BCM4359 still does not work.
>>> It times out in brcmf_sdio_firmware_callback(), while enabling func2.
>>>
>>> I've inserted tons of debug log outputs in both, the DHD driver and the
>>> brcmfmac driver, and compared them. Differences which I've found so far
>>> are: a) brcmfmac strips out whitespaces from nvram contents and
>>> b) DHD downloads firmware first and brcmfmac downloads nvram first.
>>> I've adapted the DHD driver to behave like brcmfmac in both cases
>>> and it still works.
>>>
>>> I've increased the timeout for enabling func2 from 3 seconds to 10
>>> seconds,
>>> but that did not help.
>>>
>>> Any ideas left?
>>
>> When enabling func2 fails it generally means the firmware crashed. I am
>> not sure if the patch below works to get console information. It might
>> show up empty or simply fail if firmware did not fill shared memory
>> info, but it may be worth a try.
>
> I added the patch and additionally added debug output for all error
> cases in the two called functions. Here's the output:
>
> [ 14.746092] brcmfmac: brcmf_sdio_firmware_callback: enable F2: err=-62
> [ 14.767523] brcmfmac: brcmf_sdio_checkdied: firmware not built with
> -assert
> [ 14.778777] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
> [ 14.789220] brcmfmac: brcmf_sdio_readconsole: brcmf_sdio_readconsole:
> bus->console_addr == 0!
>
> Do you have an educated guess, what causes the firmware crash, when
> being loaded via the brcmfmac driver?
Maybe we can find out with the patch below.
Regards,
Arend
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/ne
index b2e1ab5..b1a4631 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -2969,21 +2969,35 @@ static int brcmf_sdio_trap_info(struct seq_file
*seq, str
if (error < 0)
return error;
- seq_printf(seq,
- "dongle trap info: type 0x%x @ epc 0x%08x\n"
- " cpsr 0x%08x spsr 0x%08x sp 0x%08x\n"
- " lr 0x%08x pc 0x%08x offset 0x%x\n"
- " r0 0x%08x r1 0x%08x r2 0x%08x r3 0x%08x\n"
- " r4 0x%08x r5 0x%08x r6 0x%08x r7 0x%08x\n",
- le32_to_cpu(tr.type), le32_to_cpu(tr.epc),
- le32_to_cpu(tr.cpsr), le32_to_cpu(tr.spsr),
- le32_to_cpu(tr.r13), le32_to_cpu(tr.r14),
- le32_to_cpu(tr.pc), sh->trap_addr,
- le32_to_cpu(tr.r0), le32_to_cpu(tr.r1),
- le32_to_cpu(tr.r2), le32_to_cpu(tr.r3),
- le32_to_cpu(tr.r4), le32_to_cpu(tr.r5),
- le32_to_cpu(tr.r6), le32_to_cpu(tr.r7));
-
+ if (seq)
+ seq_printf(seq,
+ "dongle trap info: type 0x%x @ epc 0x%08x\n"
+ " cpsr 0x%08x spsr 0x%08x sp 0x%08x\n"
+ " lr 0x%08x pc 0x%08x offset 0x%x\n"
+ " r0 0x%08x r1 0x%08x r2 0x%08x r3 0x%08x\n"
+ " r4 0x%08x r5 0x%08x r6 0x%08x r7
0x%08x\n",
+ le32_to_cpu(tr.type), le32_to_cpu(tr.epc),
+ le32_to_cpu(tr.cpsr), le32_to_cpu(tr.spsr),
+ le32_to_cpu(tr.r13), le32_to_cpu(tr.r14),
+ le32_to_cpu(tr.pc), sh->trap_addr,
+ le32_to_cpu(tr.r0), le32_to_cpu(tr.r1),
+ le32_to_cpu(tr.r2), le32_to_cpu(tr.r3),
+ le32_to_cpu(tr.r4), le32_to_cpu(tr.r5),
+ le32_to_cpu(tr.r6), le32_to_cpu(tr.r7));
+ else
+ pr_debug("dongle trap info: type 0x%x @ epc 0x%08x\n"
+ " cpsr 0x%08x spsr 0x%08x sp 0x%08x\n"
+ " lr 0x%08x pc 0x%08x offset 0x%x\n"
+ " r0 0x%08x r1 0x%08x r2 0x%08x r3 0x%08x\n"
+ " r4 0x%08x r5 0x%08x r6 0x%08x r7 0x%08x\n",
+ le32_to_cpu(tr.type), le32_to_cpu(tr.epc),
+ le32_to_cpu(tr.cpsr), le32_to_cpu(tr.spsr),
+ le32_to_cpu(tr.r13), le32_to_cpu(tr.r14),
+ le32_to_cpu(tr.pc), sh->trap_addr,
+ le32_to_cpu(tr.r0), le32_to_cpu(tr.r1),
+ le32_to_cpu(tr.r2), le32_to_cpu(tr.r3),
+ le32_to_cpu(tr.r4), le32_to_cpu(tr.r5),
+ le32_to_cpu(tr.r6), le32_to_cpu(tr.r7));
return 0;
}
@@ -3037,8 +3051,10 @@ static int brcmf_sdio_checkdied(struct brcmf_sdio
*bus)
else if (sh.flags & SDPCM_SHARED_ASSERT)
brcmf_err("assertion in dongle\n");
- if (sh.flags & SDPCM_SHARED_TRAP)
+ if (sh.flags & SDPCM_SHARED_TRAP) {
brcmf_err("firmware trap in dongle\n");
+ brcmf_sdio_trap_info(NULL, bus, &sh);
+ }
return 0;
}
> On 12.10.2018, at 13:22, Arend van Spriel <[email protected]> wrote:
>
> On 10/12/2018 10:59 AM, Christoph Müllner wrote:
>>
>>
>> On 10/12/18 10:00 AM, Arend van Spriel wrote:
>>> On 10/11/2018 6:04 PM, Christoph Müllner wrote:
>>>> Hi Franky and Arend,
>>>>
>>>> today I could get a SDIO Wifi module, which includes a BCM43455.
>>>> I was able to get this up and running without any issues with the
>>>> brcmfmac
>>>> driver and a 4.19 kernel. For me that's enough evidence to say that
>>>> the SDIO
>>>> driver works.
>>>>
>>>> However, the BCM4359 still does not work.
>>>> It times out in brcmf_sdio_firmware_callback(), while enabling func2.
>>>>
>>>> I've inserted tons of debug log outputs in both, the DHD driver and the
>>>> brcmfmac driver, and compared them. Differences which I've found so far
>>>> are: a) brcmfmac strips out whitespaces from nvram contents and
>>>> b) DHD downloads firmware first and brcmfmac downloads nvram first.
>>>> I've adapted the DHD driver to behave like brcmfmac in both cases
>>>> and it still works.
>>>>
>>>> I've increased the timeout for enabling func2 from 3 seconds to 10
>>>> seconds,
>>>> but that did not help.
>>>>
>>>> Any ideas left?
>>>
>>> When enabling func2 fails it generally means the firmware crashed. I am
>>> not sure if the patch below works to get console information. It might
>>> show up empty or simply fail if firmware did not fill shared memory
>>> info, but it may be worth a try.
>>
>> I added the patch and additionally added debug output for all error
>> cases in the two called functions. Here's the output:
>>
>> [ 14.746092] brcmfmac: brcmf_sdio_firmware_callback: enable F2: err=-62
>> [ 14.767523] brcmfmac: brcmf_sdio_checkdied: firmware not built with
>> -assert
>> [ 14.778777] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
>> [ 14.789220] brcmfmac: brcmf_sdio_readconsole: brcmf_sdio_readconsole:
>> bus->console_addr == 0!
>>
>> Do you have an educated guess, what causes the firmware crash, when
>> being loaded via the brcmfmac driver?
>
> Maybe we can find out with the patch below.
That gives me (three out of three times):
> [ 12.934594] brcmfmac: brcmf_sdio_firmware_callback: enable F2: err=-62
> [ 12.943851] brcmfmac: brcmf_sdio_checkdied: firmware not built with -assert
> [ 12.951734] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
> [ 12.959320] dongle trap info: type 0x4 @ epc 0x001e0f8c
> [ 12.959320] cpsr 0x80000193 spsr 0x800000b3 sp 0x001b35b0
> [ 12.959320] lr 0x0006608b pc 0x001e0f8c offset 0x1b3558
> [ 12.959320] r0 0x001fbf14 r1 0x00000001 r2 0x18101000 r3 0x18001000
> [ 12.959320] r4 0x001fbf14 r5 0x00000000 r6 0x00000002 r7 0x000043ef
> [ 12.993068] brcmfmac: brcmf_sdio_readconsole: brcmf_sdio_readconsole: bus->console_addr == 0!