ath10k OTP loading issues

DISCUSSION André Valentin 3 participants 18 messages Jun 27, 2014 – Jul 19, 2014 Qualcomm Atheros ATH10K wireless driver

lore

Share & tools

lore

André Valentin

author

2014-06-27 09:15 UTC #0 lore raw

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é

André Valentin

author

2014-06-27 11:01 UTC #1 lore raw

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é

Quoted 25 lines · André Valentin

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é

Kalle Valo

2014-07-02 08:13 UTC #2 lore raw

Quoted 3 lines · André Valentin

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.

Signature · 1 line

Kalle Valo

André Valentin

author

2014-07-02 08:34 UTC #3 lore raw

Hi!

Quoted 4 lines

Quoted 1 line
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é

Kalle Valo

2014-07-02 08:56 UTC #4 lore raw

Quoted 8 lines · André Valentin

Hi!
Quoted 4 lines
Quoted 1 line
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?

Quoted 1 line

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.

Signature · 1 line

Kalle Valo

André Valentin

author

2014-07-07 14:52 UTC #5 lore raw

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é

Quoted 12 lines · Kalle Valo

Quoted 6 lines
Quoted 4 lines
Quoted 1 line
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?
Quoted 1 line
Do you have another idea. Or is the MAC somehow encrypted ?

Quoted 9 lines

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
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Kalle Valo

2014-07-02 08:10 UTC #6 lore raw

In reply to André Valentin

Hi,

please always CC ath10k list, that way you get attention of all ath10k developers.

Quoted 14 lines · André Valentin

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

Quoted 2 lines

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.

Signature · 1 line

Kalle Valo

Helmut Schaa

2014-07-07 15:40 UTC #7 lore raw

Hi,

Quoted 16 lines · Kalle Valo

Quoted 14 lines · André Valentin
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

Quoted 6 lines

Quoted 2 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Andre Valentin

author

2014-07-15 21:17 UTC #8 lore raw

Hi!

Somehow I did not see this message. Sorry.

Quoted 7 lines

Quoted 6 lines
Quoted 2 lines
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.

Quoted 7 lines

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
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Helmut Schaa

2014-07-17 14:13 UTC #9 lore raw

Hey,

Quoted 3 lines · Andre Valentin

Hi!
Somehow I did not see this message. Sorry.

No problem.

Quoted 16 lines

Quoted 16 lines
Quoted 8 lines
Quoted 3 lines
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.

Quoted 6 lines

Quoted 1 line
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
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Kalle Valo

2014-07-17 15:04 UTC #10 lore raw

Quoted 4 lines · Helmut Schaa

Quoted 4 lines
Quoted 4 lines
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.

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
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).

Signature · 6 lines

Kalle Valo

_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Helmut Schaa

2014-07-17 15:46 UTC #11 lore raw

Quoted 19 lines · Kalle Valo

Quoted 4 lines · Helmut Schaa
Quoted 4 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
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

Quoted 8 lines

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
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Kalle Valo

2014-07-17 15:51 UTC #12 lore raw

Quoted 6 lines · Helmut Schaa

Quoted 3 lines
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.

Signature · 6 lines

Kalle Valo

_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Andre Valentin

author

2014-07-17 15:55 UTC #13 lore raw

Hi!

Quoted 6 lines · Kalle Valo

Quoted 4 lines · Helmut Schaa
Quoted 3 lines
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).

Quoted 6 lines

Quoted 2 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Kalle Valo

2014-07-17 16:00 UTC #14 lore raw

Quoted 12 lines · Andre Valentin

Hi!
Quoted 9 lines · Kalle Valo
Quoted 6 lines · Helmut Schaa
Quoted 3 lines
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?

Quoted 7 lines

Quoted 2 lines
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 :)

Signature · 6 lines

Kalle Valo

_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Helmut Schaa

2014-07-17 21:44 UTC #15 lore raw

In reply to Kalle Valo

Quoted 5 lines · Kalle Valo

Quoted 1 line · Helmut Schaa
Quoted 1 line
But in method 2) otp.bin will fail as there's no data in the OTP
area.
Quoted 1 line
Quoted 1 line
This is expected and that's why we should not run otp.bin at all

Quoted 8 lines

with
Quoted 4 lines
Quoted 1 line
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
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Andre Valentin

author

2014-07-19 23:47 UTC #16 lore raw

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
---

Quoted 1 line

ath10k: boot target cpu intr cause: 0x00000008

10c10
< ath10k: boot target cpu intr cause: 0x00000000
---

Quoted 1 line

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
---

Quoted 7 lines

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
---

Quoted 4 lines

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
---

Quoted 1 line

ath10k: boot target cpu intr cause: 0x00001008

68c71
< ath10k: boot target cpu intr cause: 0x00000000
---

Quoted 1 line

ath10k: boot target cpu intr cause: 0x00000008

74c77
< ath10k: boot target cpu intr cause: 0x00000000
---

Quoted 1 line

ath10k: boot target cpu intr cause: 0x00000008

76c79
< ath10k: boot target cpu intr cause: 0x00000000
---

Quoted 1 line

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
---

Quoted 9 lines

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
---

Quoted 2 lines

ath10k: boot otp execute result 2
ath10k: otp stream is empty, using board.bin contents

Do you have an idea?

André

Quoted 7 lines · Helmut Schaa

Quoted 5 lines · Kalle Valo
Quoted 1 line · Helmut Schaa
Quoted 1 line
But in method 2) otp.bin will fail as there's no data in the OTP
area.
Quoted 1 line
Quoted 1 line
This is expected and that's why we should not run otp.bin at all

Quoted 8 lines

Quoted 6 lines
with
Quoted 3 lines
Quoted 1 line
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
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Andre Valentin

author

2014-07-19 23:58 UTC #17 lore raw

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é

Quoted 112 lines · Andre Valentin

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
---
Quoted 1 line
ath10k: boot target cpu intr cause: 0x00000008
10c10
< ath10k: boot target cpu intr cause: 0x00000000
---
Quoted 1 line
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
---
Quoted 7 lines
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
---
Quoted 4 lines
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
---
Quoted 1 line
ath10k: boot target cpu intr cause: 0x00001008
68c71
< ath10k: boot target cpu intr cause: 0x00000000
---
Quoted 1 line
ath10k: boot target cpu intr cause: 0x00000008
74c77
< ath10k: boot target cpu intr cause: 0x00000000
---
Quoted 1 line
ath10k: boot target cpu intr cause: 0x00000008
76c79
< ath10k: boot target cpu intr cause: 0x00000000
---
Quoted 1 line
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
---
Quoted 9 lines
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
---
Quoted 2 lines
ath10k: boot otp execute result 2
ath10k: otp stream is empty, using board.bin contents
Do you have an idea?
André
Quoted 15 lines · Helmut Schaa
Quoted 11 lines · Kalle Valo
Quoted 1 line · Helmut Schaa
Quoted 1 line
But in method 2) otp.bin will fail as there's no data in the OTP
area.
Quoted 1 line
Quoted 1 line
This is expected and that's why we should not run otp.bin at all
with
Quoted 3 lines
Quoted 1 line
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

Signature · 24 lines

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
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k