Firmware debugging patches?

Ben Greear greearb at
Mon Jun 2 14:21:36 PDT 2014

On 06/02/2014 09:21 AM, Kalle Valo wrote:
> Ben Greear <greearb at> writes:
>> I have a bunch of patches that can dump some firmware debug logs,
>> stack, and exception stacks as ascii hex. Ath10k firmware-having folks
>> can use private tools to extract and decode useful info from this.
> You mean via printk? That sounds ugly.
> There was talk on linux-wireless about how to handle firmware crash
> dumps in a generic way. One proposal was to use ethtool and an event for
> this. Before that I was thinking of using trace points. Maybe we should
> support both?
> We should come up with an extensible format how to provide the firmware
> crash logs to user space, for example using some TLV based format, which
> contain all the necessary information (hw details, firmware version,
> memory dumps and whatnot). But ath10k should not have any parsing of the
> dumps, that should happen in user space.

I'm looking at how iwlwifi/mvm does this.  I should be able to read the
ath10k stack and exception stack on generic firmware, but to get the BSS region,
I ended up adding some additional meta info to the firmware-2.bin image
specifying the offsets when doing my CT firmware.

You should not need to re-compile the firmware for this, but you would have
to be able to run some xtensa tool commands to get this info and re-pack
the firmware with additional meta-info (as far as I know).

Any chance upstream firmware could support specifying the bss region
offsets so that I can dump that into the debugfs dump file?


Ben Greear <greearb at>
Candela Technologies Inc

More information about the ath10k mailing list