Re: mwifiex cmd timeout on one pci variant

[Dominique MARTINET <dominique.martinet@atmark-techno.com>]

Brian Norris wrote on Wed, Sep 08, 2021 at 09:56:57AM -0700:
> On Tue, Sep 7, 2021 at 9:52 PM Dominique MARTINET
> <dominique.martinet@atmark-techno.com> wrote:
> > 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...

> > 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.


> > 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! :)


> > 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