maybe I should skip the AC card and go all the way for the AX version instead. In order to get here: I found this article on openwrt sites to “feed” the additional 3.3V for an AX adapter: https://forum.openwrt.org/t/mt7915-pcie-cards-on-bpi-unielec-boards/118194/20 is this something I could do on a R64 as well? take 12V from the GPIO and feed it back to 3.3V via another GPIO pin?
The U7623 board I used when I wrote that thread is different. The BPI-R64 board provides enough power at 3.3v in general for the AsiaRF 7915 cards. The problem is that each mPCIe slot also has current limiters that prevent one board from drawing more than a “certain amount” of power. How much that “certain amount” is depends on the revision. So whether or not you can use an AsiaRF 7915 board depends on you BPI-R64 revision, and whether or not you are willing to do some soldering.
The AsiaRF 7615 board should work with no issues, though. I have used it in the BPI-R64, and it is in my BPI-R2 right now. Works great.
And I’m actually compiling a kernel to test out my eeprom as I write this. If it works I can produce a firmware for you that might work with your current 7615 board.
I naively tried putting the mediatek,eeprom-data property in the root devicetree node, which didn’t work. My card didn’t see it. I then realized I have no idea how to target an addon-pci cards’s device tree node in the system device tree. Your example is targeting the built-in wifi, which has an existing node.
Right,it needs to be mapped to the card. Maybe there is a way for adding subnode to the right pcie port.
As alternative you can try this:
Then eeprom-data can be loaded from rootfs like firmware.
this patch is great! maybe you should submit it to openwrt mainline?
I’ve send a previous version to mt76 team (openwrt includes the mt76 repo) and it was rejected. But you can try a resend 
what was the argument? I really see no reason why you’d not want such a great function!
It was based on this
but i do not find it on a quick search. We added this for soc wifi which has additional ways (mtd partition,dts setting). Maybe with pcie card there is a good reason for file so just try to send it
The driver actually will try to load from a mtd partition if it can’t find the eeprom in the device tree…
data = of_get_property(np, "mediatek,eeprom-data", &size);
if (data) {
if (size > len)
return -EINVAL;
memcpy(eep, data, size);
return 0;
}
list = of_get_property(np, "mediatek,mtd-eeprom", &size);
…but for some reason it wants to read which mtd partition from the device tree, so I have the same problem - I don’t know how to specify a device tree node for a PCI card.
This is a fantastic solution. I was going to make an ugly hack to put the eeprom right into the driver, but this is a much better solution!
It works! Sort of… I’ll explain below.
@frank-w: Your code, of course, works great. I patched the mt76 driver in OpenWrt stable (22.03.2) and it now reads eeprom data from /lib/firmware/mediatek/mt7615e_rf.bin. The eeprom files I made all seem to work, more or less.
@jpsollie: So, it seems to work and my card comes up as more then just a generic WiFi card. However, I tgried four different eeprom files and can’t get it to come up to more than 10dBm output. I don’t think this is an eeprom issue, though. I seem to remember that this card needs extra 5v power supplied on some normally unused mPCIe pins (47 & 49) in order to go to full output. Right now I have this card in a BPI-R2, and I don’t think its mPCIe slot supplies this. But you have a BPI-R64 and its mPCIe slot does. I also have an R64, but it is sort of in “production”: in use as my main home router right now, and I don’t want to experiment with it. But if you tell me what version of OpenWrt you are using, I will build you a patched mt76.ko and you can test out your card.
See here for example: which builds upon
Similarly, on MT7986 with the current dtsi changes for PCIe which Frank is submitting to mainline Linux, you can do
&pcie {
pcie@0,0 {
status = "okay";
wifi@0,0 {
compatible = "mediatek,mt76";
reg = <0x0000 0 0 0 0>;
mediatek,eeprom-data = /incbin/("/path/to/eeprom.bin");;
};
};
};
2 Likes
Thanks @VA1DER! I’m using the latest self-compiled snapshot, so frank’s patch will be ok. In meantime, because I lost my patience, I bought the propierary ubiquiti card, I’ll see if I can extract the eeprom from there.
Here are the four eeproms I was able to find. I stuck in the mt76.ko module with Frank’s patch too. Three of the eeprom were in files provided by UniElec. The fourth one (labelled “extracted”) was the one that was installed on my UniElec board and I extracted it from a dump of its ROM. They all appear to be a little different. I’m going to try extracting the eeprom from an AsiaRF 7615 card and see what effect it has too.
EDIT: @dangowrt thank-you so much for the examples! Once I find an eeprom that works well in this board, I will use that to put the eeprom in the device tree.
EDIT2: I did grab the EEPROM off my AsiaRF 7615 card, and it’s here. When I use it, my card reports being able to sent at 24dbm. The eeproms carry the MAC address. I took the liberty of setting the MAC address in the AsiaRF eeprom to a random one in the upper end of AsiaRF’s allocation, so you should be able to use it.
glad you could do it … in a sense of desperate giving up I ordered a unielec U7615N-L3 card, hoping it would be able to do what I wanted … well, no, doesn’t even get detected (guess power issue)
@VA1DER: where did you put the patch in the openwrt src? I tried targets/linux/generic/hacks and packages/kernel/mac80211/patches, but neither of them seem to work
The UniElec cards are just like the BPI ones, with no EEPROM on them. That being said, it should at least detect when you put it in. In fact, it should act, basically, just like your BPI 7615 card. If it’s not even being detected (and if your BPI card is being detected) then I suspect a deffective card.
There should be no power issue with any 7615 card.
If you want a card that “Just Works”, then AsiaRF has a great 7615 card. It is a consumer card with a built-in EEPROM. I have even been able to get DBDC working with it.
The patch wasn’t done with quilt in mind. It’s intended to be manually applied. You have to hold a gun to the OpenWrt build system to make it do what you want, though. I’m not sitting at my computer, atm. When I get home I’ll get you the exact steps you need to build the patched kernel module. In broad strokes:
- Set up your build system, do the prelims, make toolchain/install, etc
- make package/kernel/mt76/prepare
- apply the patch to eeprom.c
- make eeprom.c imutable (sudo chattr +i eeprom.c)
- make -i package/kernel/mt76/compile
The precompiled module I made for you should work for you right now, though. Save a copy of your existing /lib/modules//mt76.ko, rename it to /lib/modules/mt76.ko.orig or something like that. Then copy the one I sent you in its place. It should make every mt76-based driver look for an eeprom file.
Isn’t it simpler to just use an dtb overlay like this one:
Then you don’t need to patch anything…
yes, this worked!
@ericwoud: I know, working with a DTB file may be easier, but it’s much better to provide a generic solution for all possible configs (which is what frank is doing here) compared to a hardlinked setup
Before I saw that it can be added as .dtbo, I was looking at setting up mtdparts with adding to kernel commandline like so:
block2mtd.block2mtd=/dev/mmcblk0p2,128KiB,MyMtd cmdlinepart.mtdparts=MyMtd:1M(mtddata)ro
So the driver could also be used unpatched. But I never went through with that as .dtbo is easier. Perhapse it can be usefull…
Good news. I personally find that wrestling the OpenWrt build system into submission and getting it to let you do something as simple as make a patch or a change can be an exercise in extreme frustration.