DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 61F512086A
Subject: Re: brcmfmac with BCM4359 on arm64 (RK3399) and SDIO
To:     =?UTF-8?Q?Christoph_M=c3=bcllner?= 
        <christoph.muellner@theobroma-systems.com>,
        Franky Lin <franky.lin@broadcom.com>
References: <5C44048D-0676-48E6-9AA3-F327839F13E5@theobroma-systems.com>
 <CA+8PC_dkJAPR2C0DsOWRb__RrijbZZ43MM1gtKGjsMxdTGwsZQ@mail.gmail.com>
 <fabdecc1-f032-789e-058f-2c62442b12c0@theobroma-systems.com>
 <C9DFBEBB-4481-4CBA-AE10-92A20C815D4F@theobroma-systems.com>
 <f7645f53-3e63-c888-c4a7-ece11655849d@broadcom.com>
 <b97f6b6c-aad9-8008-aab3-bf1ab1c1f2a0@theobroma-systems.com>
Cc:     "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" 
        <linux-wireless@vger.kernel.org>,
        "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" 
        <brcm80211-dev-list.pdl@broadcom.com>,
        brcm80211-dev-list <brcm80211-dev-list@cypress.com>
From:   Arend van Spriel <arend.vanspriel@broadcom.com>
Message-ID: <e481cbcb-6cfd-b534-eb67-c2e8d0a7761e@broadcom.com>
Date:   Fri, 12 Oct 2018 11:52:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <b97f6b6c-aad9-8008-aab3-bf1ab1c1f2a0@theobroma-systems.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

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