Re: ath10k OTP loading issues

Re: ath10k OTP loading issues

[Kalle Valo]

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

Re: ath10k OTP loading issues

[Helmut Schaa]

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

Re: ath10k OTP loading issues

[Andre Valentin]

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

Re: ath10k OTP loading issues

[Helmut Schaa]

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

Re: ath10k OTP loading issues

[Kalle Valo]

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

Re: ath10k OTP loading issues

[Helmut Schaa]

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

Re: ath10k OTP loading issues

[Kalle Valo]

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

Re: ath10k OTP loading issues

[Andre Valentin]

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

Re: ath10k OTP loading issues

[Kalle Valo]

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

Re: ath10k OTP loading issues

[Helmut Schaa]

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

Re: ath10k OTP loading issues

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

Re: ath10k OTP loading issues

[Andre Valentin]

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

Re: ath10k OTP loading issues

[Kalle Valo]

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

Re: ath10k OTP loading issues

[André Valentin]

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

Re: ath10k OTP loading issues

[Kalle Valo]

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

Re: ath10k OTP loading issues

[André Valentin]

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