From: Kalle Valo <[email protected]>
Sangwook found out that commit 639d0b89 ("ath6kl: read firmware start
address from hardware") broke firmware boot on ar6003 hw2.0 as it seems
it's not posible to automatically query the address from hardware. So
we need to hardcode the address for hw2.0.
Reported-by: Sangwook Lee <[email protected]>
Tested-by: Sangwook Lee <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
---
Kalle:
I slightly changed again. without running ath6kl_bmi_read() before,
ath6kl_bmi_execute() failed with hw2.0 board, but I am not clear about this reason.
drivers/net/wireless/ath/ath6kl/init.c | 24 ++++++++++++++++--------
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
index b277111..07a6a44 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -1183,6 +1183,7 @@ static int ath6kl_upload_board_file(struct ath6kl *ar)
static int ath6kl_upload_otp(struct ath6kl *ar)
{
u32 address, param;
+ bool from_hw = false;
int ret;
if (WARN_ON(ar->fw_otp == NULL))
@@ -1201,25 +1202,28 @@ static int ath6kl_upload_otp(struct ath6kl *ar)
}
/* read firmware start address */
- ret = ath6kl_bmi_read(ar,
- ath6kl_get_hi_item_addr(ar,
- HI_ITEM(hi_app_start)),
- (u8 *) &address, sizeof(address));
+ ret = ath6kl_bmi_read(ar, ath6kl_get_hi_item_addr(ar,
+ HI_ITEM(hi_app_start)), (u8 *) &address, sizeof(address));
if (ret) {
ath6kl_err("Failed to read hi_app_start: %d\n", ret);
return ret;
}
- ar->hw.app_start_override_addr = address;
+ if (ar->hw.app_start_override_addr == 0) {
+ ar->hw.app_start_override_addr = address;
+ from_hw = true;
+ }
- ath6kl_dbg(ATH6KL_DBG_BOOT, "app_start_override_addr 0x%x\n",
+ ath6kl_dbg(ATH6KL_DBG_BOOT, "app_start_override_addr%s 0x%x\n",
+ from_hw ? " (from hw)" : "",
ar->hw.app_start_override_addr);
/* execute the OTP code */
- ath6kl_dbg(ATH6KL_DBG_BOOT, "executing OTP at 0x%x\n", address);
+ ath6kl_dbg(ATH6KL_DBG_BOOT, "executing OTP at 0x%x\n",
+ ar->hw.app_start_override_addr);
param = 0;
- ath6kl_bmi_execute(ar, address, ¶m);
+ ath6kl_bmi_execute(ar, ar->hw.app_start_override_addr, ¶m);
return ret;
}
@@ -1421,6 +1425,10 @@ static int ath6kl_init_hw_params(struct ath6kl *ar)
ar->hw.app_load_addr = AR6003_REV2_APP_LOAD_ADDRESS;
ar->hw.board_ext_data_addr = AR6003_REV2_BOARD_EXT_DATA_ADDRESS;
ar->hw.reserved_ram_size = AR6003_REV2_RAM_RESERVE_SIZE;
+
+ /* hw2.0 needs override address hardcoded */
+ ar->hw.app_start_override_addr = 0x944C00;
+
break;
case AR6003_REV3_VERSION:
ar->hw.dataset_patch_addr = AR6003_REV3_DATASET_PATCH_ADDRESS;
--
1.7.4.1
On 10/06/2011 04:12 PM, Sangwook Lee wrote:
> From: Kalle Valo <[email protected]>
>
> Sangwook found out that commit 639d0b89 ("ath6kl: read firmware start
> address from hardware") broke firmware boot on ar6003 hw2.0 as it seems
> it's not posible to automatically query the address from hardware. So
> we need to hardcode the address for hw2.0.
>
> Reported-by: Sangwook Lee <[email protected]>
> Tested-by: Sangwook Lee <[email protected]>
> Signed-off-by: Kalle Valo <[email protected]>
> ---
> Kalle:
> I slightly changed again. without running ath6kl_bmi_read() before,
> ath6kl_bmi_execute() failed with hw2.0 board, but I am not clear about this reason.
Hmm, that's strange. I didn't find any reason why this is needed.
> @@ -1201,25 +1202,28 @@ static int ath6kl_upload_otp(struct ath6kl *ar)
> }
>
> /* read firmware start address */
> - ret = ath6kl_bmi_read(ar,
> - ath6kl_get_hi_item_addr(ar,
> - HI_ITEM(hi_app_start)),
> - (u8 *) &address, sizeof(address));
> + ret = ath6kl_bmi_read(ar, ath6kl_get_hi_item_addr(ar,
> + HI_ITEM(hi_app_start)), (u8 *) &address, sizeof(address));
You just change indentation here, right? So this part can be dropped.
I have applied to ath6kl.git now. Thank you very much for your help!
Kalle
Hi Kalle
You wrote:
>>>Before I'm able to find a hw 2.0 device, can you try to debug this more?
>>>When scanning fails can check if ath6kldev_intr_bh_handler() is called
>>>or not? When scanning fails it usually happens because irqs are failing.
Yes, it seems true. when scanning fails. it failed to receive no more sdio irqs.
For the temporary testing, I made sdio polling kernel thread and then let it
call ath6kldev_intr_bh_handler(). With hw2.0, it works fine with
scanning issue.
Do you know any ideas to solve this problem clearly ?
Thanks
Sangwook
On 12 October 2011 08:20, Kalle Valo <[email protected]> wrote:
> On 10/06/2011 04:12 PM, Sangwook Lee wrote:
>> From: Kalle Valo <[email protected]>
>>
>> Sangwook found out that commit 639d0b89 ("ath6kl: read firmware start
>> address from hardware") broke firmware boot on ar6003 hw2.0 as it seems
>> it's not posible to automatically query the address from hardware. So
>> we need to hardcode the address for hw2.0.
>>
>> Reported-by: Sangwook Lee <[email protected]>
>> Tested-by: Sangwook Lee <[email protected]>
>> Signed-off-by: Kalle Valo <[email protected]>
>> ---
>> Kalle:
>> I slightly changed again. without running ath6kl_bmi_read() before,
>> ath6kl_bmi_execute() failed with hw2.0 board, but I am not clear about this reason.
>
> Hmm, that's strange. I didn't find any reason why this is needed.
>
>> @@ -1201,25 +1202,28 @@ static int ath6kl_upload_otp(struct ath6kl *ar)
>> ? ? ? }
>>
>> ? ? ? /* read firmware start address */
>> - ? ? ret = ath6kl_bmi_read(ar,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ath6kl_get_hi_item_addr(ar,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? HI_ITEM(hi_app_start)),
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? (u8 *) &address, sizeof(address));
>> + ? ? ret = ath6kl_bmi_read(ar, ath6kl_get_hi_item_addr(ar,
>> + ? ? ? ? ? ? HI_ITEM(hi_app_start)), (u8 *) &address, sizeof(address));
>
> You just change indentation here, right? So this part can be dropped.
>
> I have applied to ath6kl.git now. Thank you very much for your help!
>
> Kalle
>
Hi Sangwook,
On 10/12/2011 01:45 PM, Sangwook Lee wrote:
>>>> Before I'm able to find a hw 2.0 device, can you try to debug this more?
>>>> When scanning fails can check if ath6kldev_intr_bh_handler() is called
>>>> or not? When scanning fails it usually happens because irqs are failing.
>
> Yes, it seems true. when scanning fails. it failed to receive no more sdio irqs.
Do you get any interrupts at all from ar6003?
> For the temporary testing, I made sdio polling kernel thread and then let it
> call ath6kldev_intr_bh_handler(). With hw2.0, it works fine with
> scanning issue.
> Do you know any ideas to solve this problem clearly ?
Sorry, I don't have any ideas right now. I have seen interrupt problems
before but they have always been due to a problem in the SDIO
controller. I don't know if your problem is an SDIO controller problem
or just related to hw2.0.
Kalle