Re: brcmfmac with BCM4359 on arm64 (RK3399) and SDIO
> On 12.10.2018, at 13:22, Arend van Spriel > 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 0x8193 spsr 0x80b3 sp 0x001b35b0 > [ 12.959320] lr 0x0006608b pc 0x001e0f8c offset 0x1b3558 > [ 12.959320] r0 0x001fbf14 r1 0x0001 r2 0x18101000 r3 0x18001000 > [ 12.959320] r4 0x001fbf14 r5 0x r6 0x0002 r7 0x43ef > [ 12.993068] brcmfmac: brcmf_sdio_readconsole: brcmf_sdio_readconsole: > bus->console_addr == 0!
Re: brcmfmac with BCM4359 on arm64 (RK3399) and SDIO
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
Re: brcmfmac with BCM4359 on arm64 (RK3399) and SDIO
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 > 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=0x16 > [ 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=0x18 > [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=0x16 > > 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 >> 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. >> &g
Re: brcmfmac with BCM4359 on arm64 (RK3399) and SDIO
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=0x16 [ 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=0x18 [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=0x16 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 > 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 >> >> >> >>
brcmfmac with BCM4359 on arm64 (RK3399) and SDIO
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 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 0001-brcmfmac-Add-SDIO-support-for-BCM4359.patch Description: Binary data -- 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