From patchwork Fri Nov 18 19:12:58 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Kazior X-Patchwork-Id: 9437213 X-Patchwork-Delegate: kvalo@adurom.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B818F60469 for ; Fri, 18 Nov 2016 19:13:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B03F4298B4 for ; Fri, 18 Nov 2016 19:13:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A4EF6299C4; Fri, 18 Nov 2016 19:13:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 0E5EC298B4 for ; Fri, 18 Nov 2016 19:13:33 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7obD-0000xO-K5; Fri, 18 Nov 2016 19:13:23 +0000 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7obB-0000ti-Fk for ath10k@lists.infradead.org; Fri, 18 Nov 2016 19:13:22 +0000 Received: by mail-wm0-x22f.google.com with SMTP id a197so57424271wmd.0 for ; Fri, 18 Nov 2016 11:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vhdVj5By5bpNH1ucTWwKxt9owEU3y73uf5/N7mdr6Y0=; b=4yVXdTBptt+NPcMlbFYlCv/5aGgIKlctfs2dyFj76Xt768FEicUMMeTFS0ztM0bmBu 3z5Pd8NTcnaLexdi5e03g9Vm3uIKy3+/LJcoEZrdRWqzNnrB3l7cup9ObPuWNxRCvXoo ASL4KcAUU5GAhpkKk5pOpY/IVHqcH67RzHMXg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vhdVj5By5bpNH1ucTWwKxt9owEU3y73uf5/N7mdr6Y0=; b=fzUjCKprqNyntxtNYuJ/WFX6IGH3Yr6m5kJEVBwDCkkip16B8yaYw6typoNrFRwBRC f9G6Rz0Nj7wogGCurBsdZwSIfvT6ITd2IqsgEHcVSTD1874gGAP8sOba5wNicFtRnqDB O76hZyXsk/oRIO091bkwcxcwXV0bZW/egbT89k0wFbebXa0rG4inxggrpTzdn+F7QfwF bPAYCFCPb9CIhrUDMD69ZZ14s0kBwvyhtIpShuHE3DIafCXNBn5znBJ5FILoD2K6N+KJ hnvfI3r+tG1vlpsWAB7tTah1MdwhZscBZz17h2QHOVkHQCsCyyhxH2vEIIoHJdiCmRp+ DqfA== X-Gm-Message-State: AKaTC0387i9tZscMpSgnFdZqdSydn/3WdZ6wZgm847sTZ4uFkvr3V6vNqieEWpTDiq9NwJdN3juzF2AiZuY1w7T4GK6Lt6wRxk+uZ0/HGjdj7Th5oNYAqlv+PhNpsSBhKksgx7pql3V8HNE35U4KuMnT X-Received: by 10.194.80.42 with SMTP id o10mr965189wjx.65.1479496379492; Fri, 18 Nov 2016 11:12:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.85.170 with HTTP; Fri, 18 Nov 2016 11:12:58 -0800 (PST) In-Reply-To: <2201471.3r8NqtoCOn@debian64> References: <3020314.NNveBmB38o@debian64> <2201471.3r8NqtoCOn@debian64> From: Michal Kazior Date: Fri, 18 Nov 2016 20:12:58 +0100 Message-ID: Subject: Re: IPQ4019 Firmware: board-2.bin vs board.bin To: Christian Lamparter X-DomainID: tieto.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161118_111321_720926_8A36EB86 X-CRM114-Status: GOOD ( 15.97 ) X-BeenThere: ath10k@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Valo, Kalle" , "ath10k@lists.infradead.org" Sender: "ath10k" Errors-To: ath10k-bounces+patchwork-ath10k=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On 18 November 2016 at 19:40, Christian Lamparter wrote: > On Friday, November 18, 2016 6:25:24 PM CET Michal Kazior wrote: >> On 18 November 2016 at 17:46, Christian Lamparter >> wrote: >> > I've acquired a IPQ4019 Router (Asus RT-AC58U). And It has a IPQ4019-SoC. >> > I'm currently in the process of porting it to LEDE. I can report that the >> > router is booting and I got the ath10k to work with 4.8.8 + >> > LEDE's compat-wireless (2016-10-08-1). >> > >> > Now, I ran across a small discrepancy with the provided firmware for >> > the IPQ4019. From the ath10k's driver prospective it seems that the >> > board-2.bin provided on github[0] has the wrong filename: >> > >> > ath10k_ahb a000000.wifi: Direct firmware load for ath10k/pre-cal-ahb-a000000.wifi.bin failed with error -2 >> > ath10k_ahb a000000.wifi: Falling back to user helper >> > firmware ath10k!pre-cal-ahb-a000000.wifi.bin: firmware_loading_store: map pages failed >> > ath10k_ahb a000000.wifi: qca4019 hw1.0 target 0x01000000 chip_id 0x003b00ff sub 0000:0000 >> > ath10k_ahb a000000.wifi: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1 >> > ath10k_ahb a000000.wifi: firmware ver 10.4-3.2.1-00044 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param crc32 b9833652 >> > ath10k_ahb a000000.wifi: failed to fetch board data for bus=ahb,vendor=0000,device=0000,subsystem-vendor=0000,subsystem-devn >> >> As far as I remember QCA4019 is supposed to used bmi chip >> identification instead of pci ids for board files. For some reason the >> driver uses pci ids on your device. Can you load ath10k_core with >> debug_mask=0xffffff3f and post results, please? I recall OpenWRT was >> messing with board file logic with its downstream patches and I >> wouldn't be surprised if LEDE keeps on doing that as well. > > I've attached the logs you want for both cases (board.bin and board2.bin). > LEDE does indeed patch ath10k [0]. But as far as I can tell, LEDE just > adds a extra path to supply the caldata [1] via request_firmware. Patch [1] is wrong. I find it frustrating OpenWRT/LEDE doesn't try to work with upstream on ixing these things right. You seem to have cal data file (I assume you extracted it from device flash partition). In this case there's no need for board file. Just in case - are you sure it's complete cal data and pre-cal? I recall qca4019 have the following flow: pre-cal -> otp get chip id -> get proper board file -> populate via otp (see commit 3d9195ea19e48). If it's really cal then I think a patch will be required (but this needs to land in upstream this time). Something like this is probably fine (didn't test!): !ar->normal_mode_fw.fw_file.otp_len) { ath10k_warn(ar, @@ -1075,6 +1080,11 @@ static int ath10k_core_fetch_board_file(struct ath10k *ar) char boardname[100]; int ret; + if (ar->cal_data) { + ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot skipping board file, cal data present\n"); + return 0; + } + ret = ath10k_core_create_board_name(ar, boardname, sizeof(boardname)); if (ret) { ath10k_err(ar, "failed to create board name: %d", ret); Michal --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -658,6 +658,11 @@ static int ath10k_core_get_board_id_from_otp(struct ath10k *ar) address = ar->hw_params.patch_load_addr; + if (ar->cal_data) { + ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot skipping board id, cal data present\n"); + return 0; + } + if (!ar->normal_mode_fw.fw_file.otp_data ||