Firmware debugging patches?

Kalle Valo kvalo at qca.qualcomm.com
Thu Jun 5 04:06:13 PDT 2014


Ben Greear <greearb at candelatech.com> writes:

> On 06/02/2014 12:29 PM, Emmanuel Grumbach wrote:
>
>> Different TLV based binary blobs concatenated. The actual encoding of
>> each of them is another story.
>
> Should we try to make the 'Type' in TLV be consistent as convenient
> across different drivers?  That might someday help auto-reporting
> tools?

I don't see the need for that as all firmwares are so different anyway.
As long as there's some magic string to recognize/verify for which
firmware it is we should be ok.

> It does not resolve my interest in firmware logs interleaved with
> kernel logs and possibly supplicant, however.
>
> Looks like trace-cmds could do that, but it will not be
> running for normal users when they experience crashes.
>
> Any suggestions other than printk for this feature?

Why do you want to put the crash dump in kernel log, can you describe
your "use case" here? For me it would be enough to have a UUID for each
crash dump and then have the driver print that to kernel log:

ath10k: firmware crashed (uuid 1234567890-4321)

And then you just need to find the correct dump from the file system and
start debugging. Would that be enough for you?

-- 
Kalle Valo



More information about the ath10k mailing list