linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Kyle Evans <kvans32@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: brcmfmac4329-sdio firmware load failed.
Date: Tue, 16 Jan 2018 21:18:00 +0100	[thread overview]
Message-ID: <5A5E5DF8.9090307@broadcom.com> (raw)
In-Reply-To: <20180116012011.GA22945@localhost.localdomain>

On 1/16/2018 2:20 AM, Kyle Evans wrote:
> On Sat, Jan 13, 2018 at 10:19:19AM +0100, Arend van Spriel wrote:
>> On 1/12/2018 9:18 PM, Kyle Evans wrote:
>>> Thank you Arend. I updated to master again, v4.15-rc7+, and applied your
>>> patch. All log snips are grabbed with dmesg|grep -E 'mmc0|brcm', as the
>>> sdio device is on mmc0.
>>
>> Could you follow the reply convention of not top-posting.
>>
>>> Without patch [1], for reference...
>>>
>>> [    0.000000] Kernel command line: console=tty0 selinux=0
>>> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
>>
>> You made a type in the kernel command line, ie. "bebug" should be
>> "debug". Anyway, that is not that important for now.
>>
>>> [    3.952561] mmc0: Invalid maximum block size, assuming 512 bytes
>>> [    4.010466] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
>>> using ADMA
>>> [    4.338545] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
>>> [    4.347098] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
>>> [    4.350099] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
>>> [    4.378430] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
>>> [    4.388387] mmc0: new SDIO card at address 0001
>>> [    4.401773] brcmfmac: F1 signature read @0x18000000=0x9934329
>>> [    4.407624] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
>>> F1@0x080ac, err: -84
>>> [    4.410159] brcmfmac: brcmf_fw_map_chip_to_name: using
>>> brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
>>> [    4.781374] brcmfmac mmc0:0001:1: Direct firmware load for
>>> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
>>> [    4.781491] brcmfmac mmc0:0001:1: Falling back to user helper
>>> [   69.601645] brcmfmac: brcmf_c_process_clm_blob: request CLM blob file
>>> failed (-11)
>>> [   69.601668] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file
>>> failed, -11
>>> [   69.601685] brcmfmac: brcmf_bus_started: failed: -11
>>> [   69.601728] brcmfmac: brcmf_sdio_firmware_callback: dongle is not
>>> responding
>>>
>>>
>>> With patch [1]...
>>>
>>> [    0.000000] Kernel command line: console=tty0 selinux=0
>>> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
>>> [    3.954628] mmc0: Invalid maximum block size, assuming 512 bytes
>>> [    4.010608] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
>>> using ADMA
>>> [    4.341727] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
>>> [    4.349595] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
>>> [    4.352695] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
>>> [    4.381292] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
>>> [    4.387377] mmc0: new SDIO card at address 0001
>>> [    4.399393] brcmfmac: F1 signature read @0x18000000=0x9934329
>>> [    4.405883] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
>>> F1@0x080ac, err: -84
>>> [    4.407207] brcmfmac: brcmf_fw_map_chip_to_name: using
>>> brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x000003
>>> [    4.709436] brcmfmac mmc0:0001:1: Direct firmware load for
>>> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
>>> [    4.709517] brcmfmac mmc0:0001:1: Falling back to user helper
>>> [   69.710122] brcmfmac mmc0:0001:1: Direct firmware load for
>>> brcm/brcmfmac4329-sdio.clm_blob failed with error -2
>>> [   69.710137] brcmfmac mmc0:0001:1: Falling back to user helper
>>> [  131.054899] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>> Sep  2 2011 14:48:19 version 4.220.48
>>> [  131.072561] brcmfmac: brcmf_setup_wiphybands: rxchain error (-23)
>>> [  131.388384] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  131.392390] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  131.920861] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  131.924183] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  132.593074] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  133.135973] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  133.138223] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  133.152149] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  134.311983] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  134.458577] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  134.461640] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>> [  134.555048] brcmfmac: _brcmf_set_multicast_list: Setting
>>> BRCMF_C_SET_PROMISC failed, -23
>>>
>>>
>>> I can now connect to an AP with the following caveats:
>>>
>>> 1) It takes about two minutes before the wlan device is available. For a
>>> long while I didn't think it was working because I would check dmesg and
>>> check ifconfig -a before the wlan would be present.
>>
>> Those two minutes are a direct result of the clm_blob requests. Your
>> kernel config has user-mode helper fallback selected, which causes 60
>> seconds timeout waiting for user-space to provide the blob. You could
>> try and disable it. It is CONFIG_FW_LOADER_USER_HELPER_FALLBACK in your
>> .config.
>
> Yes, it's better without it.
>
>>
>>> 2) After reboot I get this nasty error...
>>> [    0.000000] Kernel command line: console=tty0 selinux=0
>>> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
>>> [    2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
>>> [    2.330010] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
>>> using ADMA
>>> [    2.645242] mmc0: error -110 whilst initialising SDIO card
>>
>> Ok. I suppose you mean a warm reboot. So I suppose the card is not
>> properly power cycled. If your SDHCI controller driver (is it
>> sdhci-acpi?) is loaded as a module, you could try to unload it and load
>> it again. Let me know if that works for you to confirm my guess.
>
> Yes, reboot = warm boot. The driver is sdhci-tegra. I have it built in as
> I am booting without an initrd. I have tried modprobe -r brcmfmac before
> reboot with no difference. It will take some work to create a ramdisk.
>
>>
>>> Regarding the patch, brcmfmac tries to load a firmware file twice for a
>>> device which the firmware file does not exist. Is there a know list of
>>> devices which do not need it that we can use to bypass
>>> brcmf_c_process_clm_blob()?
>>
>> It is unclear to me why the firmware load is done twice. Could it be in
>> the firmware class itself? In brcmfmac there is only one
>> request_firmware() call for the clm blob. At least in my version of it.
>> Do you have something else?
>
> It is your patch [1]. The helper function triggers the while loop.

That actually is not my patch. I just mentioned that one for reference. 
My patch was at the end of my email message or here [3].

Anyway, Kalle just applied a similar patch [4] which hopefully makes it 
into v4.15 release.

Regards,
Arend

[3] https://patchwork.kernel.org/patch/10154595/
[4] https://patchwork.kernel.org/patch/10166257/

  reply	other threads:[~2018-01-16 20:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 12:51 brcmfmac4329-sdio firmware load failed Kyle Evans
2018-01-10  8:47 ` Arend van Spriel
2018-01-12 20:18   ` Kyle Evans
2018-01-13  9:19     ` Arend van Spriel
2018-01-16  1:20       ` Kyle Evans
2018-01-16 20:18         ` Arend van Spriel [this message]
2018-01-18 17:50       ` sdio failure to initialize on warm boot Kyle Evans
2018-01-19  8:21         ` Arend van Spriel
2018-01-19 16:05           ` Kyle Evans
2018-01-22  9:22             ` Arend van Spriel
2018-01-26 10:45               ` Kyle Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5A5E5DF8.9090307@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=kvans32@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).