* ath10k OTP loading issues @ 2014-06-27 8:44 André Valentin 2014-06-27 11:01 ` André Valentin 2014-07-02 8:10 ` Kalle Valo 0 siblings, 2 replies; 22+ messages in thread From: André Valentin @ 2014-06-27 8:44 UTC (permalink / raw) To: linux-wireless Hi! I got problems initializing my ath10k PCI card in my Zyxel NBG 6716. It worked until some weeks, now, the driver does not load. I debugged a bit and this is what I got: Fri Jun 27 08:03:42 2014 kern.info kernel: [62908.290000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit] Fri Jun 27 08:03:43 2014 kern.info kernel: [62908.610000] ath10k: pci irq legacy irq_mode 0 reset_mode 0 Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.620000] ath10k: boot upload otp to 0x1234 len 6917 Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.780000] ath10k: otp calibration failed: 2 Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.790000] ath10k: failed to run otp: -22 Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.790000] ath10k: could not init core (-22) Fri Jun 27 08:03:43 2014 kern.err kernel: [62909.060000] ath10k: could not probe fw (-22) Fri Jun 27 08:03:43 2014 kern.err kernel: [62909.060000] ath10k: failed to register driver core: -22 Fri Jun 27 08:03:43 2014 kern.warn kernel: [62909.060000] ath10k_pci: probe of 0000:01:00.0 failed with error -22 If I remove OTP loading the card initializes fine, but I think I will not have a good performance. So bad idea. Currently I use compat-wireless-2014-05-22, with some patches form openwrt. The firmware-2.bin has been checked, it is the same as offered here: https://github.com/kvalo/ath10k-firmware Perhaps somebody has a hint for me? Kind regards, André ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-06-27 8:44 ath10k OTP loading issues André Valentin @ 2014-06-27 11:01 ` André Valentin 2014-07-02 8:13 ` Kalle Valo 2014-07-02 8:10 ` Kalle Valo 1 sibling, 1 reply; 22+ messages in thread From: André Valentin @ 2014-06-27 11:01 UTC (permalink / raw) To: linux-wireless Hi Again! I just saw the old thread about the same point. So I'm trying to look in the flash of my router if the OTP is stored there. Does this OTP have some kind of magic so I can identify it? André On 27.06.2014 10:44, André Valentin wrote: > Hi! > > I got problems initializing my ath10k PCI card in my Zyxel NBG 6716. It worked until some weeks, now, the driver does not load. I debugged a bit and this is what I got: > Fri Jun 27 08:03:42 2014 kern.info kernel: [62908.290000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit] > Fri Jun 27 08:03:43 2014 kern.info kernel: [62908.610000] ath10k: pci irq legacy irq_mode 0 reset_mode 0 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.620000] ath10k: boot upload otp to 0x1234 len 6917 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.780000] ath10k: otp calibration failed: 2 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.790000] ath10k: failed to run otp: -22 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.790000] ath10k: could not init core (-22) > Fri Jun 27 08:03:43 2014 kern.err kernel: [62909.060000] ath10k: could not probe fw (-22) > Fri Jun 27 08:03:43 2014 kern.err kernel: [62909.060000] ath10k: failed to register driver core: -22 > Fri Jun 27 08:03:43 2014 kern.warn kernel: [62909.060000] ath10k_pci: probe of 0000:01:00.0 failed with error -22 > > > If I remove OTP loading the card initializes fine, but I think I will not have a good performance. So bad idea. > Currently I use compat-wireless-2014-05-22, with some patches form openwrt. > The firmware-2.bin has been checked, it is the same as offered here: > https://github.com/kvalo/ath10k-firmware > > Perhaps somebody has a hint for me? > > Kind regards, > > André > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-06-27 11:01 ` André Valentin @ 2014-07-02 8:13 ` Kalle Valo 0 siblings, 0 replies; 22+ messages in thread From: Kalle Valo @ 2014-07-02 8:13 UTC (permalink / raw) To: André Valentin; +Cc: linux-wireless, ath10k André Valentin <avalentin@marcant.net> writes: > I just saw the old thread about the same point. So I'm trying to look > in the flash of my router if the OTP is stored there. Does this OTP > have some kind of magic so I can identify it? MAC addresses are good one to check. Basically it should be similar data as in board.bin. -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues @ 2014-07-02 8:13 ` Kalle Valo 0 siblings, 0 replies; 22+ messages in thread From: Kalle Valo @ 2014-07-02 8:13 UTC (permalink / raw) To: André Valentin; +Cc: linux-wireless, ath10k André Valentin <avalentin@marcant.net> writes: > I just saw the old thread about the same point. So I'm trying to look > in the flash of my router if the OTP is stored there. Does this OTP > have some kind of magic so I can identify it? MAC addresses are good one to check. Basically it should be similar data as in board.bin. -- Kalle Valo ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-02 8:13 ` Kalle Valo @ 2014-07-02 8:34 ` André Valentin -1 siblings, 0 replies; 22+ messages in thread From: André Valentin @ 2014-07-02 8:34 UTC (permalink / raw) To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org Hi! >> have some kind of magic so I can identify it? > > MAC addresses are good one to check. Basically it should be similar data > as in board.bin. Of course I already tried this. But no luck. Do you have another idea. Or is the MAC somehow encrypted ? I searched for the ASCII represantation and a binary string generated from the MAC bytes. Thanks, André _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues @ 2014-07-02 8:34 ` André Valentin 0 siblings, 0 replies; 22+ messages in thread From: André Valentin @ 2014-07-02 8:34 UTC (permalink / raw) To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org Hi! >> have some kind of magic so I can identify it? > > MAC addresses are good one to check. Basically it should be similar data > as in board.bin. Of course I already tried this. But no luck. Do you have another idea. Or is the MAC somehow encrypted ? I searched for the ASCII represantation and a binary string generated from the MAC bytes. Thanks, André ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-02 8:34 ` André Valentin @ 2014-07-02 8:56 ` Kalle Valo -1 siblings, 0 replies; 22+ messages in thread From: Kalle Valo @ 2014-07-02 8:56 UTC (permalink / raw) To: André Valentin Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org André Valentin <avalentin@marcant.net> writes: > Hi! > >>> have some kind of magic so I can identify it? >> >> MAC addresses are good one to check. Basically it should be similar data >> as in board.bin. > > Of course I already tried this. But no luck. How exactly did you search for it? Are you sure you used the correct MAC address? > Do you have another idea. Or is the MAC somehow encrypted ? Nothing special, the MAC address should should be within the first 20 bytes. For example, here's 00:03:07:12:34:56: $ od -t x1 board.bin | head -1 0000000 44 08 df 30 02 04 00 03 07 12 34 56 00 00 6a 00 But of course I might be missing something. Or the calibration data is somehow encrypted on the flash. -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues @ 2014-07-02 8:56 ` Kalle Valo 0 siblings, 0 replies; 22+ messages in thread From: Kalle Valo @ 2014-07-02 8:56 UTC (permalink / raw) To: André Valentin Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org André Valentin <avalentin@marcant.net> writes: > Hi! > >>> have some kind of magic so I can identify it? >> >> MAC addresses are good one to check. Basically it should be similar data >> as in board.bin. > > Of course I already tried this. But no luck. How exactly did you search for it? Are you sure you used the correct MAC address? > Do you have another idea. Or is the MAC somehow encrypted ? Nothing special, the MAC address should should be within the first 20 bytes. For example, here's 00:03:07:12:34:56: $ od -t x1 board.bin | head -1 0000000 44 08 df 30 02 04 00 03 07 12 34 56 00 00 6a 00 But of course I might be missing something. Or the calibration data is somehow encrypted on the flash. -- Kalle Valo ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-02 8:56 ` Kalle Valo (?) @ 2014-07-07 14:51 ` André Valentin -1 siblings, 0 replies; 22+ messages in thread From: André Valentin @ 2014-07-07 14:51 UTC (permalink / raw) To: Kalle Valo; +Cc: ath10k@lists.infradead.org Hi! Thanks for your hint. I now found at least the correct board.bin. Also I disabled the OTP check because it always throws an error. By the way, can I overwrite the MAC address? I changed it in board.bin to the device MAC, but it did not work. Also if I set it with ifconfig, it is only temorarily. Hostapd doesn't use it at all, it somehow reads the MAC from the device. Do you have an idea? André On 02.07.2014 10:56, Kalle Valo wrote: >>>> have some kind of magic so I can identify it? >>> >>> MAC addresses are good one to check. Basically it should be similar data >>> as in board.bin. >> >> Of course I already tried this. But no luck. > > How exactly did you search for it? Are you sure you used the correct MAC > address? > >> Do you have another idea. Or is the MAC somehow encrypted ? > > Nothing special, the MAC address should should be within the first 20 > bytes. For example, here's 00:03:07:12:34:56: > > $ od -t x1 board.bin | head -1 > 0000000 44 08 df 30 02 04 00 03 07 12 34 56 00 00 6a 00 > > But of course I might be missing something. Or the calibration data is > somehow encrypted on the flash. > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-06-27 8:44 ath10k OTP loading issues André Valentin @ 2014-07-02 8:10 ` Kalle Valo 2014-07-02 8:10 ` Kalle Valo 1 sibling, 0 replies; 22+ messages in thread From: Kalle Valo @ 2014-07-02 8:10 UTC (permalink / raw) To: André Valentin; +Cc: linux-wireless, ath10k Hi, please always CC ath10k list, that way you get attention of all ath10k developers. André Valentin <avalentin@marcant.net> writes: > I got problems initializing my ath10k PCI card in my Zyxel NBG 6716. > It worked until some weeks, now, the driver does not load. I debugged > a bit and this is what I got: > > Fri Jun 27 08:03:42 2014 kern.info kernel: [62908.290000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit] > Fri Jun 27 08:03:43 2014 kern.info kernel: [62908.610000] ath10k: pci irq legacy irq_mode 0 reset_mode 0 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.620000] ath10k: boot upload otp to 0x1234 len 6917 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.780000] ath10k: otp calibration failed: 2 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.790000] ath10k: failed to run otp: -22 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.790000] ath10k: could not init core (-22) > Fri Jun 27 08:03:43 2014 kern.err kernel: [62909.060000] ath10k: could not probe fw (-22) > Fri Jun 27 08:03:43 2014 kern.err kernel: [62909.060000] ath10k: failed to register driver core: -22 > Fri Jun 27 08:03:43 2014 kern.warn kernel: [62909.060000] ath10k_pci: probe of 0000:01:00.0 failed with error -22 > > If I remove OTP loading the card initializes fine, but I think I will > not have a good performance. So bad idea. All that was changed recently was that we now check the error code coming from otp.bin. So you have had this issue all along, it was just hidden before. -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues @ 2014-07-02 8:10 ` Kalle Valo 0 siblings, 0 replies; 22+ messages in thread From: Kalle Valo @ 2014-07-02 8:10 UTC (permalink / raw) To: André Valentin; +Cc: linux-wireless, ath10k Hi, please always CC ath10k list, that way you get attention of all ath10k developers. André Valentin <avalentin@marcant.net> writes: > I got problems initializing my ath10k PCI card in my Zyxel NBG 6716. > It worked until some weeks, now, the driver does not load. I debugged > a bit and this is what I got: > > Fri Jun 27 08:03:42 2014 kern.info kernel: [62908.290000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit] > Fri Jun 27 08:03:43 2014 kern.info kernel: [62908.610000] ath10k: pci irq legacy irq_mode 0 reset_mode 0 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.620000] ath10k: boot upload otp to 0x1234 len 6917 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.780000] ath10k: otp calibration failed: 2 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.790000] ath10k: failed to run otp: -22 > Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.790000] ath10k: could not init core (-22) > Fri Jun 27 08:03:43 2014 kern.err kernel: [62909.060000] ath10k: could not probe fw (-22) > Fri Jun 27 08:03:43 2014 kern.err kernel: [62909.060000] ath10k: failed to register driver core: -22 > Fri Jun 27 08:03:43 2014 kern.warn kernel: [62909.060000] ath10k_pci: probe of 0000:01:00.0 failed with error -22 > > If I remove OTP loading the card initializes fine, but I think I will > not have a good performance. So bad idea. All that was changed recently was that we now check the error code coming from otp.bin. So you have had this issue all along, it was just hidden before. -- Kalle Valo ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-02 8:10 ` Kalle Valo (?) @ 2014-07-07 15:40 ` Helmut Schaa 2014-07-15 21:16 ` Andre Valentin -1 siblings, 1 reply; 22+ messages in thread From: Helmut Schaa @ 2014-07-07 15:40 UTC (permalink / raw) To: Kalle Valo; +Cc: André Valentin, ath10k Hi, On Wed, Jul 2, 2014 at 10:10 AM, Kalle Valo <kvalo@qca.qualcomm.com> wrote: > André Valentin <avalentin@marcant.net> writes: > >> I got problems initializing my ath10k PCI card in my Zyxel NBG 6716. >> It worked until some weeks, now, the driver does not load. I debugged >> a bit and this is what I got: >> >> Fri Jun 27 08:03:42 2014 kern.info kernel: [62908.290000] ath10k_pci 0000:01:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit] >> Fri Jun 27 08:03:43 2014 kern.info kernel: [62908.610000] ath10k: pci irq legacy irq_mode 0 reset_mode 0 >> Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.620000] ath10k: boot upload otp to 0x1234 len 6917 >> Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.780000] ath10k: otp calibration failed: 2 >> Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.790000] ath10k: failed to run otp: -22 >> Fri Jun 27 08:03:43 2014 kern.err kernel: [62908.790000] ath10k: could not init core (-22) >> Fri Jun 27 08:03:43 2014 kern.err kernel: [62909.060000] ath10k: could not probe fw (-22) >> Fri Jun 27 08:03:43 2014 kern.err kernel: [62909.060000] ath10k: failed to register driver core: -22 >> Fri Jun 27 08:03:43 2014 kern.warn kernel: [62909.060000] ath10k_pci: probe of 0000:01:00.0 failed with error -22 >> >> If I remove OTP loading the card initializes fine, but I think I will >> not have a good performance. So bad idea. > > All that was changed recently was that we now check the error code > coming from otp.bin. So you have had this issue all along, it was just > hidden before. Same issue here. Is it correct that board.bin should contain the calibration data of the actual board? I tried copying it from the APs ART partition but still no luck. Any hint on how to debug further why the otp calibration fails? Thanks, Helmut _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-07 15:40 ` Helmut Schaa @ 2014-07-15 21:16 ` Andre Valentin 2014-07-17 14:12 ` Helmut Schaa 0 siblings, 1 reply; 22+ messages in thread From: Andre Valentin @ 2014-07-15 21:16 UTC (permalink / raw) To: Helmut Schaa, Kalle Valo; +Cc: ath10k Hi! Somehow I did not see this message. Sorry. >>> If I remove OTP loading the card initializes fine, but I think I will >>> not have a good performance. So bad idea. >> >> All that was changed recently was that we now check the error code >> coming from otp.bin. So you have had this issue all along, it was just >> hidden before. > > Same issue here. > > Is it correct that board.bin should contain the calibration data of > the actual board? > I tried copying it from the APs ART partition but still no luck. > > Any hint on how to debug further why the otp calibration fails? I have no idea except disabling the error return inside of ath10k_pci. Would that make sense as a temporary workaround? It seems I have normal performance without enfording otp loading. André _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-15 21:16 ` Andre Valentin @ 2014-07-17 14:12 ` Helmut Schaa 2014-07-17 15:03 ` Kalle Valo 0 siblings, 1 reply; 22+ messages in thread From: Helmut Schaa @ 2014-07-17 14:12 UTC (permalink / raw) To: Andre Valentin; +Cc: Kalle Valo, ath10k Hey, On Tue, Jul 15, 2014 at 11:16 PM, Andre Valentin <avalentin@marcant.net> wrote: > Hi! > > Somehow I did not see this message. Sorry. No problem. >>>> If I remove OTP loading the card initializes fine, but I think I will >>>> >>>> not have a good performance. So bad idea. >>> >>> >>> All that was changed recently was that we now check the error code >>> coming from otp.bin. So you have had this issue all along, it was just >>> hidden before. >> >> >> Same issue here. >> >> Is it correct that board.bin should contain the calibration data of >> the actual board? >> I tried copying it from the APs ART partition but still no luck. >> >> Any hint on how to debug further why the otp calibration fails? > > > I have no idea except disabling the error return inside of ath10k_pci. > Would that make sense as a temporary workaround? It seems I have normal > performance without enfording otp loading. Sure, but it is a workaround and I'd like to find out why it fails if I use the calibration data from the original firmware. Thanks, Helmut _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-17 14:12 ` Helmut Schaa @ 2014-07-17 15:03 ` Kalle Valo 2014-07-17 15:45 ` Helmut Schaa 0 siblings, 1 reply; 22+ messages in thread From: Kalle Valo @ 2014-07-17 15:03 UTC (permalink / raw) To: Helmut Schaa; +Cc: Andre Valentin, ath10k Helmut Schaa <helmut.schaa@googlemail.com> writes: >>> Is it correct that board.bin should contain the calibration data of >>> the actual board? I tried copying it from the APs ART partition but >>> still no luck. >>> >>> Any hint on how to debug further why the otp calibration fails? >> >> I have no idea except disabling the error return inside of ath10k_pci. >> Would that make sense as a temporary workaround? It seems I have normal >> performance without enfording otp loading. > > Sure, but it is a workaround and I'd like to find out why it fails if I use the > calibration data from the original firmware. Let me clarify. There are two ways to store the calibration data: 1) to the OTP area within the QCA9880 chip 2) to the host, for example to an MTD partition otp.bin is used with method 1). It reads the OTP area and provides the calibration data to the firmware. But in method 2) otp.bin will fail as there's no data in the OTP area. This is expected and that's why we should not run otp.bin at all with method 2). -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-17 15:03 ` Kalle Valo @ 2014-07-17 15:45 ` Helmut Schaa 2014-07-17 15:50 ` Kalle Valo 0 siblings, 1 reply; 22+ messages in thread From: Helmut Schaa @ 2014-07-17 15:45 UTC (permalink / raw) To: Kalle Valo; +Cc: Andre Valentin, ath10k On Thu, Jul 17, 2014 at 5:03 PM, Kalle Valo <kvalo@qca.qualcomm.com> wrote: > Helmut Schaa <helmut.schaa@googlemail.com> writes: > >>>> Is it correct that board.bin should contain the calibration data of >>>> the actual board? I tried copying it from the APs ART partition but >>>> still no luck. >>>> >>>> Any hint on how to debug further why the otp calibration fails? >>> >>> I have no idea except disabling the error return inside of ath10k_pci. >>> Would that make sense as a temporary workaround? It seems I have normal >>> performance without enfording otp loading. >> >> Sure, but it is a workaround and I'd like to find out why it fails if I use the >> calibration data from the original firmware. > > Let me clarify. There are two ways to store the calibration data: > > 1) to the OTP area within the QCA9880 chip > > 2) to the host, for example to an MTD partition > > otp.bin is used with method 1). It reads the OTP area and provides the > calibration data to the firmware. > > But in method 2) otp.bin will fail as there's no data in the OTP area. > This is expected and that's why we should not run otp.bin at all with > method 2). Thanks for clarification Kalle! So, method 2 requires only a board.bin? Helmut _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-17 15:45 ` Helmut Schaa @ 2014-07-17 15:50 ` Kalle Valo 2014-07-17 15:54 ` Andre Valentin 2014-07-17 21:44 ` Helmut Schaa 0 siblings, 2 replies; 22+ messages in thread From: Kalle Valo @ 2014-07-17 15:50 UTC (permalink / raw) To: Helmut Schaa; +Cc: Andre Valentin, ath10k Helmut Schaa <helmut.schaa@googlemail.com> writes: >> But in method 2) otp.bin will fail as there's no data in the OTP area. >> This is expected and that's why we should not run otp.bin at all with >> method 2). > > Thanks for clarification Kalle! So, method 2 requires only a > board.bin? Yes. You need to extract the board file from the MTD partition and provide it to ath10k. -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-17 15:50 ` Kalle Valo @ 2014-07-17 15:54 ` Andre Valentin 2014-07-17 15:59 ` Kalle Valo 2014-07-17 21:44 ` Helmut Schaa 1 sibling, 1 reply; 22+ messages in thread From: Andre Valentin @ 2014-07-17 15:54 UTC (permalink / raw) To: Kalle Valo, Helmut Schaa; +Cc: ath10k@lists.infradead.org Hi! On 17.07.2014 17:50, Kalle Valo wrote: > Helmut Schaa <helmut.schaa@googlemail.com> writes: > >>> But in method 2) otp.bin will fail as there's no data in the OTP area. >>> This is expected and that's why we should not run otp.bin at all with >>> method 2). >> >> Thanks for clarification Kalle! So, method 2 requires only a >> board.bin? > > Yes. You need to extract the board file from the MTD partition and > provide it to ath10k. > So the question is why does in this case fail the otp.bin loading process or why is it started. How can I prevent it. I provided the correspondig board.bin. If needed, I could run a debug on the ath10k loading. Kind regards, André _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-17 15:54 ` Andre Valentin @ 2014-07-17 15:59 ` Kalle Valo 0 siblings, 0 replies; 22+ messages in thread From: Kalle Valo @ 2014-07-17 15:59 UTC (permalink / raw) To: Andre Valentin; +Cc: Helmut Schaa, ath10k@lists.infradead.org Andre Valentin <avalentin@marcant.net> writes: > Hi! > > On 17.07.2014 17:50, Kalle Valo wrote: >> Helmut Schaa <helmut.schaa@googlemail.com> writes: >> >>>> But in method 2) otp.bin will fail as there's no data in the OTP area. >>>> This is expected and that's why we should not run otp.bin at all with >>>> method 2). >>> >>> Thanks for clarification Kalle! So, method 2 requires only a >>> board.bin? >> >> Yes. You need to extract the board file from the MTD partition and >> provide it to ath10k. > > So the question is why does in this case fail the otp.bin loading > process or why is it started. How can I prevent it. I provided the > correspondig board.bin. If needed, I could run a debug on the ath10k > loading. Because ath10k does not support method 2) yet. We only support method 1) right now, ie. the calibration data stored in OTP area. Patches more than welcome to fix the situation :) -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-17 15:50 ` Kalle Valo 2014-07-17 15:54 ` Andre Valentin @ 2014-07-17 21:44 ` Helmut Schaa 2014-07-19 23:46 ` Andre Valentin 1 sibling, 1 reply; 22+ messages in thread From: Helmut Schaa @ 2014-07-17 21:44 UTC (permalink / raw) To: Kalle Valo; +Cc: Andre Valentin, ath10k On 17. Juli 2014 17:50:36 MESZ, Kalle Valo <kvalo@qca.qualcomm.com> wrote: >Helmut Schaa <helmut.schaa@googlemail.com> writes: > >>> But in method 2) otp.bin will fail as there's no data in the OTP >area. >>> This is expected and that's why we should not run otp.bin at all >with >>> method 2). >> >> Thanks for clarification Kalle! So, method 2 requires only a >> board.bin? > >Yes. You need to extract the board file from the MTD partition and >provide it to ath10k. Understood. Will give it a try soon ... Helmut _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-17 21:44 ` Helmut Schaa @ 2014-07-19 23:46 ` Andre Valentin 2014-07-19 23:57 ` Andre Valentin 0 siblings, 1 reply; 22+ messages in thread From: Andre Valentin @ 2014-07-19 23:46 UTC (permalink / raw) To: Helmut Schaa, Kalle Valo; +Cc: ath10k Hi! I noticed that OTP loading works on some ZyXEL NBG6716 devices and some not. I made a diff between both boot (working non-working) logs. Please take a look at the cpu intr cause: 8c8 < ath10k: boot target cpu intr cause: 0x00000000 --- > ath10k: boot target cpu intr cause: 0x00000008 10c10 < ath10k: boot target cpu intr cause: 0x00000000 --- > ath10k: boot target cpu intr cause: 0x00000008 13,19c13,19 < ath10k: boot init ce src ring id 0 entries 16 base_addr ae4dd000 < ath10k: boot ce dest ring id 1 entries 512 base_addr aef52000 < ath10k: boot ce dest ring id 2 entries 32 base_addr ae4d8000 < ath10k: boot init ce src ring id 3 entries 32 base_addr ae28a000 < ath10k: boot init ce src ring id 4 entries 4096 base_addr ae4e0000 < ath10k: boot init ce src ring id 7 entries 2 base_addr ae4d9000 < ath10k: boot ce dest ring id 7 entries 2 base_addr ae4dc000 --- > ath10k: boot init ce src ring id 0 entries 16 base_addr aef3e000 > ath10k: boot ce dest ring id 1 entries 512 base_addr aeedc000 > ath10k: boot ce dest ring id 2 entries 32 base_addr ae0d1000 > ath10k: boot init ce src ring id 3 entries 32 base_addr aed7d000 > ath10k: boot init ce src ring id 4 entries 4096 base_addr ae7a0000 > ath10k: boot init ce src ring id 7 entries 2 base_addr ae0c2000 > ath10k: boot ce dest ring id 7 entries 2 base_addr ae730000 45c45,48 < ath10k: boot otp execute result 0 --- > ath10k: boot otp execute result 2 > ath10k: otp calibration failed: 2 > ath10k: failed to run otp: -22 > ath10k: Ignoring otp execution failure: -22 66c69 < ath10k: boot target cpu intr cause: 0x00001000 --- > ath10k: boot target cpu intr cause: 0x00001008 68c71 < ath10k: boot target cpu intr cause: 0x00000000 --- > ath10k: boot target cpu intr cause: 0x00000008 74c77 < ath10k: boot target cpu intr cause: 0x00000000 --- > ath10k: boot target cpu intr cause: 0x00000008 76c79 < ath10k: boot target cpu intr cause: 0x00000000 --- > ath10k: boot target cpu intr cause: 0x00000008 And with a cold reset (hacked the code) instead: 6,19c4,12 < ath10k: boot warm reset < ath10k: boot host cpu intr cause: 0x00000000 < ath10k: boot target cpu intr cause: 0x00000000 < ath10k: boot host cpu intr cause: 0x00000000 < ath10k: boot target cpu intr cause: 0x00000000 < ath10k: boot target reset state: 0x00000800 < ath10k: boot warm reset complete < ath10k: boot init ce src ring id 0 entries 16 base_addr ae4dd000 < ath10k: boot ce dest ring id 1 entries 512 base_addr aef52000 < ath10k: boot ce dest ring id 2 entries 32 base_addr ae4d8000 < ath10k: boot init ce src ring id 3 entries 32 base_addr ae28a000 < ath10k: boot init ce src ring id 4 entries 4096 base_addr ae4e0000 < ath10k: boot init ce src ring id 7 entries 2 base_addr ae4d9000 < ath10k: boot ce dest ring id 7 entries 2 base_addr ae4dc000 --- > ath10k: boot cold reset > ath10k: boot cold reset complete > ath10k: boot init ce src ring id 0 entries 16 base_addr aeed5000 > ath10k: boot ce dest ring id 1 entries 512 base_addr ae112000 > ath10k: boot ce dest ring id 2 entries 32 base_addr aeedf000 > ath10k: boot init ce src ring id 3 entries 32 base_addr ae453000 > ath10k: boot init ce src ring id 4 entries 4096 base_addr ad0c0000 > ath10k: boot init ce src ring id 7 entries 2 base_addr ae49f000 > ath10k: boot ce dest ring id 7 entries 2 base_addr ae258000 25,27d17 < ath10k: boot target indicator 0 < ath10k: boot target indicator 0 < ath10k: boot target indicator 0 45c35,36 < ath10k: boot otp execute result 0 --- > ath10k: boot otp execute result 2 > ath10k: otp stream is empty, using board.bin contents Do you have an idea? André On 17.07.2014 23:44, Helmut Schaa wrote: > > On 17. Juli 2014 17:50:36 MESZ, Kalle Valo <kvalo@qca.qualcomm.com> wrote: >> Helmut Schaa <helmut.schaa@googlemail.com> writes: >> >>>> But in method 2) otp.bin will fail as there's no data in the OTP >> area. >>>> This is expected and that's why we should not run otp.bin at all >> with >>>> method 2). >>> Thanks for clarification Kalle! So, method 2 requires only a >>> board.bin? >> Yes. You need to extract the board file from the MTD partition and >> provide it to ath10k. > Understood. Will give it a try soon ... > Helmut _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ath10k OTP loading issues 2014-07-19 23:46 ` Andre Valentin @ 2014-07-19 23:57 ` Andre Valentin 0 siblings, 0 replies; 22+ messages in thread From: Andre Valentin @ 2014-07-19 23:57 UTC (permalink / raw) To: Helmut Schaa, Kalle Valo; +Cc: ath10k Hi! And here is the working log just in case :-( ath10k: boot pci_mem 0xb2000000 ath10k: boot chip_id 0x043202ff hw_revision 0x2 ath10k: boot hif power up ath10k: boot warm reset ath10k: boot host cpu intr cause: 0x00000000 ath10k: boot target cpu intr cause: 0x00000000 ath10k: boot host cpu intr cause: 0x00000000 ath10k: boot target cpu intr cause: 0x00000000 ath10k: boot target reset state: 0x00000800 ath10k: boot warm reset complete ath10k: boot init ce src ring id 0 entries 16 base_addr ae4dd000 ath10k: boot ce dest ring id 1 entries 512 base_addr aef52000 ath10k: boot ce dest ring id 2 entries 32 base_addr ae4d8000 ath10k: boot init ce src ring id 3 entries 32 base_addr ae28a000 ath10k: boot init ce src ring id 4 entries 4096 base_addr ae4e0000 ath10k: boot init ce src ring id 7 entries 2 base_addr ae4d9000 ath10k: boot ce dest ring id 7 entries 2 base_addr ae4dc000 ath10k: boot waiting target to initialise ath10k: boot target indicator 0 ath10k: boot target indicator 0 ath10k: boot target indicator 0 ath10k: boot target indicator 0 ath10k: boot target indicator 0 ath10k: boot target indicator 0 ath10k: boot target indicator 0 ath10k: boot target indicator 2 ath10k: boot target initialised ath10k: pci irq legacy irq_mode 0 reset_mode 0 ath10k: Hardware name qca988x hw2.0 version 0x4100016c ath10k: trying fw api 2 ath10k: found fw version 10.1.467.2-1 ath10k: found fw timestamp 1391440175 ath10k: found otp image ie (6917 B) ath10k: found fw image ie (190250 B) ath10k: found firmware features ie (1 B) ath10k: Enabling feature bit: 1 ath10k: Enabling feature bit: 2 ath10k: features 00000000: 00 00 00 06 .... ath10k: using fw api 2 ath10k: boot push board extended data addr 0x0 ath10k: boot upload otp to 0x1234 len 6917 ath10k: boot otp execute result 0 ath10k: boot hif start ath10k: boot htc service 'Control' ul pipe 0 dl pipe 1 eid 0 ready ath10k: boot htc ep 0 ul polled 0 dl polled 0 ath10k: boot htc service 'Control' eid 0 TX flow control disabled ath10k: boot htc service HTT Data does not allocate target credits ath10k: boot htc service 'HTT Data' ul pipe 4 dl pipe 1 eid 1 ready ath10k: boot htc ep 1 ul polled 1 dl polled 0 ath10k: boot htc service 'HTT Data' eid 1 TX flow control disabled ath10k: htt tx max num pending tx 1424 ath10k: htt rx ring size 1024 fill_level 1000 ath10k: boot htc service 'WMI' ul pipe 3 dl pipe 2 eid 2 ready ath10k: boot htc ep 2 ul polled 0 dl polled 0 ath10k: boot wmi ready ath10k: firmware 10.1.467.2-1 booted ath10k: htt target version 2.1 ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.1.467.2-1 api 2 htt 2.1 ath10k: boot suspend complete ath10k: boot hif stop ath10k: boot warm reset ath10k: boot host cpu intr cause: 0x00000000 ath10k: boot target cpu intr cause: 0x00001000 ath10k: boot host cpu intr cause: 0x00000000 ath10k: boot target cpu intr cause: 0x00000000 ath10k: boot target reset state: 0x00000804 ath10k: boot warm reset complete ath10k: boot hif power down ath10k: boot warm reset ath10k: boot host cpu intr cause: 0x00000000 ath10k: boot target cpu intr cause: 0x00000000 ath10k: boot host cpu intr cause: 0x00000000 ath10k: boot target cpu intr cause: 0x00000000 ath10k: boot target reset state: 0x00000800 ath10k: boot warm reset complete André On 20.07.2014 01:46, Andre Valentin wrote: > Hi! > > I noticed that OTP loading works on some ZyXEL NBG6716 devices and some not. I made a diff between both > boot (working non-working) logs. Please take a look at the cpu intr cause: > > 8c8 > < ath10k: boot target cpu intr cause: 0x00000000 > --- >> ath10k: boot target cpu intr cause: 0x00000008 > 10c10 > < ath10k: boot target cpu intr cause: 0x00000000 > --- >> ath10k: boot target cpu intr cause: 0x00000008 > 13,19c13,19 > < ath10k: boot init ce src ring id 0 entries 16 base_addr ae4dd000 > < ath10k: boot ce dest ring id 1 entries 512 base_addr aef52000 > < ath10k: boot ce dest ring id 2 entries 32 base_addr ae4d8000 > < ath10k: boot init ce src ring id 3 entries 32 base_addr ae28a000 > < ath10k: boot init ce src ring id 4 entries 4096 base_addr ae4e0000 > < ath10k: boot init ce src ring id 7 entries 2 base_addr ae4d9000 > < ath10k: boot ce dest ring id 7 entries 2 base_addr ae4dc000 > --- >> ath10k: boot init ce src ring id 0 entries 16 base_addr aef3e000 >> ath10k: boot ce dest ring id 1 entries 512 base_addr aeedc000 >> ath10k: boot ce dest ring id 2 entries 32 base_addr ae0d1000 >> ath10k: boot init ce src ring id 3 entries 32 base_addr aed7d000 >> ath10k: boot init ce src ring id 4 entries 4096 base_addr ae7a0000 >> ath10k: boot init ce src ring id 7 entries 2 base_addr ae0c2000 >> ath10k: boot ce dest ring id 7 entries 2 base_addr ae730000 > 45c45,48 > < ath10k: boot otp execute result 0 > --- >> ath10k: boot otp execute result 2 >> ath10k: otp calibration failed: 2 >> ath10k: failed to run otp: -22 >> ath10k: Ignoring otp execution failure: -22 > 66c69 > < ath10k: boot target cpu intr cause: 0x00001000 > --- >> ath10k: boot target cpu intr cause: 0x00001008 > 68c71 > < ath10k: boot target cpu intr cause: 0x00000000 > --- >> ath10k: boot target cpu intr cause: 0x00000008 > 74c77 > < ath10k: boot target cpu intr cause: 0x00000000 > --- >> ath10k: boot target cpu intr cause: 0x00000008 > 76c79 > < ath10k: boot target cpu intr cause: 0x00000000 > --- >> ath10k: boot target cpu intr cause: 0x00000008 > > > And with a cold reset (hacked the code) instead: > > 6,19c4,12 > < ath10k: boot warm reset > < ath10k: boot host cpu intr cause: 0x00000000 > < ath10k: boot target cpu intr cause: 0x00000000 > < ath10k: boot host cpu intr cause: 0x00000000 > < ath10k: boot target cpu intr cause: 0x00000000 > < ath10k: boot target reset state: 0x00000800 > < ath10k: boot warm reset complete > < ath10k: boot init ce src ring id 0 entries 16 base_addr ae4dd000 > < ath10k: boot ce dest ring id 1 entries 512 base_addr aef52000 > < ath10k: boot ce dest ring id 2 entries 32 base_addr ae4d8000 > < ath10k: boot init ce src ring id 3 entries 32 base_addr ae28a000 > < ath10k: boot init ce src ring id 4 entries 4096 base_addr ae4e0000 > < ath10k: boot init ce src ring id 7 entries 2 base_addr ae4d9000 > < ath10k: boot ce dest ring id 7 entries 2 base_addr ae4dc000 > --- >> ath10k: boot cold reset >> ath10k: boot cold reset complete >> ath10k: boot init ce src ring id 0 entries 16 base_addr aeed5000 >> ath10k: boot ce dest ring id 1 entries 512 base_addr ae112000 >> ath10k: boot ce dest ring id 2 entries 32 base_addr aeedf000 >> ath10k: boot init ce src ring id 3 entries 32 base_addr ae453000 >> ath10k: boot init ce src ring id 4 entries 4096 base_addr ad0c0000 >> ath10k: boot init ce src ring id 7 entries 2 base_addr ae49f000 >> ath10k: boot ce dest ring id 7 entries 2 base_addr ae258000 > 25,27d17 > < ath10k: boot target indicator 0 > < ath10k: boot target indicator 0 > < ath10k: boot target indicator 0 > 45c35,36 > < ath10k: boot otp execute result 0 > --- >> ath10k: boot otp execute result 2 >> ath10k: otp stream is empty, using board.bin contents > > Do you have an idea? > > André > > On 17.07.2014 23:44, Helmut Schaa wrote: >> >> On 17. Juli 2014 17:50:36 MESZ, Kalle Valo <kvalo@qca.qualcomm.com> wrote: >>> Helmut Schaa <helmut.schaa@googlemail.com> writes: >>> >>>>> But in method 2) otp.bin will fail as there's no data in the OTP >>> area. >>>>> This is expected and that's why we should not run otp.bin at all >>> with >>>>> method 2). >>>> Thanks for clarification Kalle! So, method 2 requires only a >>>> board.bin? >>> Yes. You need to extract the board file from the MTD partition and >>> provide it to ath10k. >> Understood. Will give it a try soon ... >> Helmut > -- Mit freundlichen Grüßen, André Valentin Projektkoordination / Systemadministration MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld Fon: +49 (521) 95945-0 | Fax -18 URL: http://www.marcant.net | http://www.global-m2m.com Geschäftsführer: Thorsten Hojas Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238 ___________________________________________________________ CONFIDENTIALITY NOTICE The contents of this email are confidential to the ordinary user of the email address to which it was addressed and may also be privileged. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this email in error please email the sender by replying to this message. _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2014-07-19 23:58 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-06-27 8:44 ath10k OTP loading issues André Valentin 2014-06-27 11:01 ` André Valentin 2014-07-02 8:13 ` Kalle Valo 2014-07-02 8:13 ` Kalle Valo 2014-07-02 8:34 ` André Valentin 2014-07-02 8:34 ` André Valentin 2014-07-02 8:56 ` Kalle Valo 2014-07-02 8:56 ` Kalle Valo 2014-07-07 14:51 ` André Valentin 2014-07-02 8:10 ` Kalle Valo 2014-07-02 8:10 ` Kalle Valo 2014-07-07 15:40 ` Helmut Schaa 2014-07-15 21:16 ` Andre Valentin 2014-07-17 14:12 ` Helmut Schaa 2014-07-17 15:03 ` Kalle Valo 2014-07-17 15:45 ` Helmut Schaa 2014-07-17 15:50 ` Kalle Valo 2014-07-17 15:54 ` Andre Valentin 2014-07-17 15:59 ` Kalle Valo 2014-07-17 21:44 ` Helmut Schaa 2014-07-19 23:46 ` Andre Valentin 2014-07-19 23:57 ` Andre Valentin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.