Chip debug tool

Chip debug tool

[Bassem Fahmy]

Hi
Our systems team is asking to develop a chip debug tool to be able to
test, calibrate and tweak every bit of the chip from user space
(something similar to Broadcom's WL tool). The tool would later be
stripped out and passed to customers to help them tweak specific
features.

The tool needs to be easy for the firmware and RF team to add extra
command, by adding some definitions in the user space tool and a
matching response in the firmware (no driver recompilation).

Based on this, I can think of few of options
- nl80211: to overload NL80211_CMD_TESTMODE or NL80211_CMD_VENDOR or
- nl80211: to create a new set of commands. These options don't seem
to have a chance to go back upstream though.

Another option is to use debugfs. In this case however, all the
commands would go to a single node, and the driver which would blindly
pass data to/from the chip. This is to avoid recompiling the driver
every time a new command is added.

Just wondering what is the proper (recommended way) for this. Any
ideas, directions?

Thanks, Bassem

Re: Chip debug tool

[Kalle Valo]

Bassem Fahmy <bassem@morsemicro.com> writes:

> Hi
> Our systems team is asking to develop a chip debug tool to be able to
> test, calibrate and tweak every bit of the chip from user space
> (something similar to Broadcom's WL tool). The tool would later be
> stripped out and passed to customers to help them tweak specific
> features.
>
> The tool needs to be easy for the firmware and RF team to add extra
> command, by adding some definitions in the user space tool and a
> matching response in the firmware (no driver recompilation).
>
> Based on this, I can think of few of options
> - nl80211: to overload NL80211_CMD_TESTMODE or NL80211_CMD_VENDOR or
> - nl80211: to create a new set of commands. These options don't seem
> to have a chance to go back upstream though.
>
> Another option is to use debugfs. In this case however, all the
> commands would go to a single node, and the driver which would blindly
> pass data to/from the chip. This is to avoid recompiling the driver
> every time a new command is added.
>
> Just wondering what is the proper (recommended way) for this. Any
> ideas, directions?

NL80211_CMD_TESTMODE was added exactly for this kind of use in mind
(used by RF/HW engineers and not by regular users), I recommend using
it.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches