On Tue, Sep 7, 2021 at 9:52 PM Dominique MARTINET <dominique.martinet@xxxxxxxxxxxxxxxxx> 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. > I've got a mwifiex M.2 pci module that won't take any wifi command and > hang right away (dmesg below). Bluetooth through serial works. > > > 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. > 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. > 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. Good luck, Brian
