[PATCH v5] ath10k: save firmware debug log messages.

[Ben Greear]

On 09/02/2014 07:58 AM, Li, Yanbo wrote:
> Hi Ben,
> 
> I just start to investigate about how to get the full dump from target.  It can utilization the debugfs framework you have done, 
> We can work together and figure out more detail about how to implement it. 

Sounds good.  I have patches to deal with dumping debug-log, ROM and RAM bss regions,
and a proprietary tool to decode all of this that QCA can have access to.

My patches are similar to what has been posted before, but tweaked
slightly and tested.  I am trying to get the debug-log patch
in acceptable form before posting the rest of the patches, but I
can make them available earlier if someone wants to see them.

Please let me know what you have in mind.

Thanks,
Ben

> 
> Thanks 
> BR /Yanbo
> 
> -----Original Message-----
> From: ath10k [mailto:ath10k-bounces at lists.infradead.org] On Behalf Of Ben Greear
> Sent: Tuesday, September 02, 2014 10:52 PM
> To: michal.kazior at tieto.com; Valo, Kalle
> Cc: ath10k at lists.infradead.org
> Subject: Re: [PATCH v5] ath10k: save firmware debug log messages.
> 
> 
> 
> On 09/02/2014 06:51 AM, Michal Kazior wrote:
>> On 2 September 2014 15:38, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>>> (Dropping linux-wireless)
>>>
>>> greearb at candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb at candelatech.com>
>>>>
>>>> They may be dumped through the firmware dump debugfs file.
>>>>
>>>> Signed-off-by: Ben Greear <greearb at candelatech.com>
>>>
>>> Before I start looking at this in detail: this looks fragile and 
>>> complicated from ath10k point of view. Why not just take a dump of 
>>> the whole firmware memory and postprocess this, with whatever else we 
>>> might need from the firmware? That's a lot easier to maintain.
>>
>> I like the idea although it still makes sense to keep some sort of a 
>> circular buffer for the debug mesg events delivered via wmi, does it 
>> not?
> 
> Upstream firmware already creates and sends dbglog messages, and it is nice to see a history.  It sends them to host fairly often, so just grabbing the log on crash could miss useful info.
> 
> For that matter, I'd like to read firmware debuglog ids not just on crash, which I could easily do with this patch as the basis by creating a new debugfs file that just dumps the debuglog ids.
> 
> I'm not sure what I could do with a full ram dump, but perhaps QCA devs have something.  It would at a minimum use a lot more RAM to store it.
> I just need (know how to decode) the BSS regions, debug-logs, and registers.
> 
> Thanks,
> Ben
> 
>>
>>
>> Michał
>>
> 
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com