Re: [RESEND] brcmfmac support for BCM4359 sdio on arm64 ??

[Arend Van Spriel <arend.vanspriel@broadcom.com>]

On 12/10/2019 3:15 PM, Christian Hewitt wrote:
> 
>> On 21 Nov 2019, at 8:01 pm, Christian Hewitt 
>> <christianshewitt@gmail.com <mailto:christianshewitt@gmail.com>> wrote:
>>>
>>> On 21 Nov 2019, at 1:00 pm, Arend Van Spriel 
>>> <arend.vanspriel@broadcom.com <mailto:arend.vanspriel@broadcom.com>> 
>>> wrote:
>>>
>>> On 11/21/2019 4:52 AM, Christian Hewitt wrote:
>>>>> On 24 Jun 2019, at 11:04 pm, Arend Van Spriel 
>>>>> <arend.vanspriel@broadcom.com 
>>>>> <mailto:arend.vanspriel@broadcom.com>> wrote:
>>>>>
>>>>> Hi Christian,
>>>>>
>>>>> Here it is. Hopefully unmangled this time.
>>>>>
>>>>> Regards,
>>>>> Arend
>>>>> ---
>>>>> diff --git 
>>>>> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
>>>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>>> index ec129864cc9c..7be8064c6dc7 100644
>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>>> @@ -785,7 +785,8 @@ void brcmf_sdiod_sgtable_alloc(struct 
>>>>> brcmf_sdio_dev *sdiodev)
>>>>>                     sdiodev->settings->bus.sdio.txglomsz);
>>>>>       nents += (nents >> 4) + 1;
>>>>>
>>>>> -       WARN_ON(nents > sdiodev->max_segment_count);
>>>>> +       WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u, 
>>>>> host_max_seg=%u, nents=%u\n",
>>>>> +                sdiodev->max_segment_count, host->max_segs, nents);
>>>>>
>>>>>       brcmf_dbg(TRACE, "nents=%d\n", nents);
>>>>>       err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
>>>> Hello Arend,
>>>> I’ve resumed testing on 5.4-rc8 with ^ this patch and 
>>>> https://github.com/chewitt/linux/commit/07fd0f25ceb72b15aa8c3fbd149aa41cbc55d035 
>>>> applied and brcmfmac.debug=30 in boot params. Here is more extended 
>>>> output:
>>>> [    6.115132] brcmfmac: brcmfmac_module_init No platform data 
>>>> available.
>>>> [    6.116841] brcmfmac: brcmf_sdio_probe Enter
>>>> [    6.118695] brcmfmac: F1 signature read @0x18000000=0x17294359
>>>> [    6.118910] brcmfmac: brcmf_chip_recognition found AXI chip: 
>>>> BCM4359/9
>>>> [    6.120687] brcmfmac: brcmf_chip_cores_check  [1 ] core 0x800:52 
>>>> base 0x18000000 wrap 0x18100000
>>>> [    6.120692] brcmfmac: brcmf_chip_cores_check  [2 ] core 0x812:59 
>>>> base 0x18001000 wrap 0x18101000
>>>> [    6.120695] brcmfmac: brcmf_chip_cores_check  [3 ] core 0x83e:8 
>>>>  base 0x18002000 wrap 0x18102000
>>>> [    6.120697] brcmfmac: brcmf_chip_cores_check  [4 ] core 0x83c:21 
>>>> base 0x18003000 wrap 0x18103000
>>>> [    6.120698] brcmfmac: brcmf_chip_cores_check  [5 ] core 0x812:59 
>>>> base 0x18004000 wrap 0x18104000
>>>> [    6.120700] brcmfmac: brcmf_chip_cores_check  [6 ] core 0x829:22 
>>>> base 0x18005000 wrap 0x18105000
>>>> [    6.120702] brcmfmac: brcmf_chip_cores_check  [7 ] core 0x840:5 
>>>>  base 0x1800a000 wrap 0x00000000
>>>> [    6.120703] brcmfmac: brcmf_chip_cores_check  [8 ] core 0x135:0 
>>>>  base 0x00000000 wrap 0x18109000
>>>> [    6.120704] brcmfmac: brcmf_chip_cores_check  [9 ] core 0x240:0 
>>>>  base 0x00000000 wrap 0x00000000
>>>> [    6.120706] brcmfmac: brcmf_chip_set_passive Enter
>>>> [    6.121378] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x180000 
>>>> size=917504 (0xe0000) sr=0 (0x0)
>>>> [    6.121438] brcmfmac: brcmf_chip_setup ccrev=52, pmurev=26, 
>>>> pmucaps=0x3a0c3f1a
>>>> [    6.121441] brcmfmac: brcmf_get_module_param Enter, bus=0, 
>>>> chip=17241, rev=9
>>>> [    6.121618] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
>>>> [    6.121621] brcmfmac: brcmf_sdio_kso_init Enter
>>>> [    6.121635] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO driver 
>>>> strength init needed for chip BCM4359/9 rev 9 pmurev 26
>>>> [    6.121998] brcmfmac: brcmf_sdio_probe completed!!
>>>> [    6.122003] brcmfmac: brcmf_fw_alloc_request: using 
>>>> brcm/brcmfmac4359-sdio for chip BCM4359/9
>>>> [    6.122008] brcmfmac: brcmf_fw_get_firmwares enter: dev=mmc0:0001:1
>>>> [    6.293561] brcmfmac: brcmf_fw_complete_request firmware 
>>>> brcm/brcmfmac4359-sdio.bin found
>>>> [    6.309769] brcmfmac: brcmf_fw_complete_request firmware 
>>>> brcm/brcmfmac4359-sdio.txt found
>>>> [    6.309772] brcmfmac: brcmf_fw_request_nvram_done enter: 
>>>> dev=mmc0:0001:1
>>>> [    6.309840] brcmfmac: brcmf_fw_request_nvram_done nvram 
>>>> 000000007040259b len 3564
>>>> [    6.309843] brcmfmac: brcmf_sdio_firmware_callback Enter: 
>>>> dev=mmc0:0001:1, err=0
>>>> [    8.206959] brcmfmac: brcmf_sdio_download_code_file Enter
>>>> [    8.272184] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul 
>>>> at 0x00180000; size=636647
>>>> [    8.354229] brcmfmac: brcmf_sdio_download_nvram Enter
>>>> [    8.359730] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul 
>>>> at 0x0025f214; size=3564
>>>> [    8.367550] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
>>>> [    8.373550] brcmfmac: brcmf_sdio_verifymemory: error -84 on 
>>>> reading 2048 membytes at 0x0025f214
>>>> [    8.382188] brcmfmac: brcmf_sdio_download_firmware: dongle nvram 
>>>> file download failed
>>>> [    8.389982] brcmfmac: brcmf_sdio_firmware_callback failed: 
>>>> dev=mmc0:0001:1, err=-5
>>>> [    8.397514] brcmfmac: brcmf_sdio_remove Enter
>>>> [    8.402641] brcmfmac: brcmf_detach Enter
>>>> [    8.434899] brcmfmac: brcmf_chip_set_passive Enter
>>>> [    8.458772] brcmfmac: brcmf_sdio_remove Disconnected
>>>> I’m using renamed nvram.txt and fw_bcm4359c0_ag_apsta.bin from the 
>>>> bcmdhd.1.579.77.41.x driver (https://github.com/chewitt/bcmdhd/). In 
>>>> the full dmesg: https://pastebin.com/raw/DUUGSjWw there is some 
>>>> kernel splat starting 6.121488 that appears to be from probing. 
>>>> FWIW, the BT side of the device appears to be working fine.
>>>> Any suggestions?
>>>
>>> This is a differing issue, right? Sorry it has been a while back and 
>>> I did not search for your earlier emails.
>>>
>>> The error -84 is -EILSEQ which we get from SDIO layer. I think this 
>>> is returned when CRC errors occur on the SDIO bus. It would trigger a 
>>> retune in the host controller.
>>>
>>> Were you seeing similar issues on earlier kernel?
>>
>> BCM4359 has mainline support for some time as a PCIe device. I’m 
>> attempting SDIO support by patching ID’s to the usual places.
>>
>> I’ve seen the probing kernel splat on probing on all kernels I’ve 
>> attempted to use. I’ve been attempting since ~4.19.
>>
>> I’m testing with a selection of Amlogic boards/boxes covering 
>> Amlogic’s GXM, G12A, G12B and SM1 platforms. The G12*/SM1 boards are 
>> based on the OEM vendor reference design with relatively minor 
>> variations between them. I have G12B boxes (same base platform) that 
>> work fine with other Ampak modules. I have devices of all varieties 
>> that have the same Ampak ap6398s module. In all cases the BT side 
>> works fine, but the WiFi shows the errors ^ above.
>>
>> I don’t see any special handling for the BCM4359 in the bcmdhd code, 
>> but it appears to be grouped alongside 4349/4355 chips:
>>
>> https://github.com/chewitt/bcmdhd/blob/f7009015df77fdeb35f9c7d6925f83861acc54f3/include/sbchipc.h#L3989
>>
>> None of those chips appear in current mainline code under the SDIO 
>> path (4355 shows under PCIe) so my guess is that it’s not CRC errors, 
>> but these chips need a slightly different firmware loading process. I 
>> don’t see any special ifdef/handling for BCM4359 in the bcmdhd code, 
>> but then I’m not a coding developer so my ability to read and 
>> understand the code is limited.
>>
>> Recent-ish bcmdhd code is known/working on the same hardware with 
>> minor nip/tuck changes:
>>
>> https://gitlab.com/baylibre/amlogic/atv/linux/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd
> 
> Arend, is there any more input/context I can provide?
> 
> If it would help to have hardware with this chipset to explore what’s 
> needed, it can be easily arranged.

Hi Christian,

I noticed some upstream patches for 4359 sdio from Cypress couple of 
days ago. Here is one of the patches from v2 series: 
https://patchwork.kernel.org/patch/11286555/

Regards,
Arend