Re: mwifiex cmd timeout on one pci variant

Brian Norris wrote on Wed, Sep 08, 2021 at 09:56:57AM -0700:

On Tue, Sep 7, 2021 at 9:52 PM Dominique MARTINET
[off-list ref] wrote:

quoted

This is probably more a question for the maker.. But maybe someone will
know.

Last I knew, at least one of the CC'd is still employed by the owner
of this IP (NXP now), but I don't know that much. But then, they
haven't been giving out a lot of free support lately, AFAIK.

Thanks for the information.
I've also tried reaching out through our reseller before but it'll
likely take some time to tickle up, if it ever does...

quoted

Context:
I've got a board with an i.MX8MP chip, and three different marvell W8997
M.2 modules -- one from laird which works fine, and two from azurewave
which are labeled exactly the same AW-CM276MA 2276MA PCIE-UART except
one works and not the other.
The inscription on the chip itself are slightly different, one saying
it's a W8997-M1216 from marvell (works) and the other having AW-CM276NF
azurewave mark. The electronics around are also different.

FWIW, I've only ever worked with the PCIe-USB variant of this chip.
And it had tons of bugs that resulted in "command timeouts" along the
way, and it took a lot of co-working with Marvell to get the firmware
fixed. I don't know their release model well enough to know whether
the PCIe-UART variant will have all the same bugs (and bugfixes). But
in case it helps, here's our firmware history:
https://chromium.googlesource.com/chromiumos/third_party/linux-firmware/+log/HEAD/mrvl/pcieusb8997_combo_v4.bin
*Most* of those should align pretty closely with what was published to
linux-firmware.git, but it's not guaranteed, since Marvell didn't
always follow our upstream-first guidelines there.

That indeed shows more updates for pcieusb than pcieuart..
The upstream repo https://github.com/NXP/mwifiex-firmware/ listed in
commit message also only seems to have ever updated pcieusb, so I guess
that's where the efforts have been poured.

Also made me try to force loading 'wrong' firmwares to see what happen
and pcie8997_wlan_v4.bin actually loads! But seems to have similar
problems. Others fail to start, but that's not really surprising.

quoted

I could say it's just a bad chip, but I've actually got two of each
(samples) which act the same... And I've tried it in another device
where it works with the same kernel/firmware, so there must be something
wrong on the board as well as the wifi card works elsewhere.

I've seen something as small as the "wrong" kind of noise cause the
firmware to grind to a halt, so there could be a firmware bug that
gets tickled by the particular layout or antenna configuration of the
board in question. I suppose that's not a very helpful guess, but at
least it might validate your observations.

Every bit helps! :)

quoted

Anyway, if someone knows how to get around to debugging this, I'd
appreciate a pointer! I can't see anything wrong with the tools I have
here.
If nothing else, I can't read /sys/class/devcoredump/devcd*/data that I
saw Amitkumar Karwar request somewhere else, so just deciphering this
would be great help.

I've never had success with that, but I haven't tried very hard. My
understanding is that it's something equivalent to a register and
state dump of the proprietary firmware, so you won't really learn much
from it without proprietary knowledge.

Yes, that was my guess as well (hence the many Ccs with hopefully one
working there :-D), but I also understand free support isn't something
all companies let or encourage their employees to do.


Thanks for the reply anyway, if nothing else it might make the
difference for paying a bit more for a card with less troubling
history if my words weight enough.

-- 
Dominique