Well I spent about a week fighting with this dumb bug. Whatever I did, MT7612 wifi chips were not working on EcoNet devices.
I developed the PCI driver (the wifi chips are connected to the CPI via PCI), so I was looking and looking for bugs in that. The nature of this issue was kind of a brick wall to investigate: The driver sends the firmware to the chip, kicks it off, and waits for the chip to say "Ready"... Well, the chip never says "Ready".
After *days* of comparing my PCI driver to the vendor code, I eventually tried loading up an entire vendor kernel and ATTEMPT to get some version of a wifi driver to run on it.
Man oh man that was hell. That kernel is based on a Linux 4.9 android fork (so basically, it's from 2016), of course the wifi driver wouldn't just work on it, and getting it to compile and load took me just about all of today.
When I finally fixed all of the issues and got it to load up, it did THE SAME THING. So now I turned my attention to the wifi driver, because even though it's not my code, I figured maybe there's something "weird" about this device which made it not work.
20 minutes of comparing the wifi driver to an ancient version that was known to work, and I saw a difference. It was a byte-swap in the old driver that was missing in the new one. And at that moment I realized, this is a Big Endian processor, it's entirely possible that nobody ever tried running this wifi driver on Big Endian...
30 minutes later I had a fix and confirmed it was working. Another hour later I had a patch out to the Linux kernel...
https://lore-kernel.gnuweeb.org/linux-wireless/20251027171759.1484844-1-cjd@cjdns.fr/#r
So there it is, a week of debugging for 2 hours of fixing, and the bug wasn't in my code.
I developed the PCI driver (the wifi chips are connected to the CPI via PCI), so I was looking and looking for bugs in that. The nature of this issue was kind of a brick wall to investigate: The driver sends the firmware to the chip, kicks it off, and waits for the chip to say "Ready"... Well, the chip never says "Ready".
After *days* of comparing my PCI driver to the vendor code, I eventually tried loading up an entire vendor kernel and ATTEMPT to get some version of a wifi driver to run on it.
Man oh man that was hell. That kernel is based on a Linux 4.9 android fork (so basically, it's from 2016), of course the wifi driver wouldn't just work on it, and getting it to compile and load took me just about all of today.
When I finally fixed all of the issues and got it to load up, it did THE SAME THING. So now I turned my attention to the wifi driver, because even though it's not my code, I figured maybe there's something "weird" about this device which made it not work.
20 minutes of comparing the wifi driver to an ancient version that was known to work, and I saw a difference. It was a byte-swap in the old driver that was missing in the new one. And at that moment I realized, this is a Big Endian processor, it's entirely possible that nobody ever tried running this wifi driver on Big Endian...
30 minutes later I had a fix and confirmed it was working. Another hour later I had a patch out to the Linux kernel...
https://lore-kernel.gnuweeb.org/linux-wireless/20251027171759.1484844-1-cjd@cjdns.fr/#r
So there it is, a week of debugging for 2 hours of fixing, and the bug wasn't in my code.
But when you're documenting packet layouts it's absolute misery. We still mentally represent numbers as big endian, shift-left and shift-right are big endian concepts. When we think of the bits in a byte, we think big-endian - even though a byte is atomic to the machine.
So yeah ¯\_(ツ)_/¯