802.11ac module gives max 6dbi transmitter power

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 {
	[email protected],0 {
		status = "okay";

		[email protected],0 {
			compatible = "mediatek,mt76";
			reg = <0x0000 0 0 0 0>;
			mediatek,eeprom-data = /incbin/("/path/to/eeprom.bin");;

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

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.