I recently bought the AC wlan extension for the bpi 64. I’m running self compiled openwrt master. Unfortunately, the module limits itself to only 6dbi transmitter power. I found a few articles on the internet talking about wrong EEPROM values, But how do I fix it? > root@apbureau:~# dmesg | grep mt76 > [ 2.419033] FIT: Selected configuration: “config-mt7622-bananapi-bpi-r64-pcie1” (OpenWrt bananapi_bpi-r64 with mt7622-bananapi-bpi-r64-pcie1) > [ 2.457108] FIT: flat_dt sub-image 0x0053b000…0x0053b11a “fdt-mt7622-bananapi-bpi-r64-pcie1” (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-pcie1) > [ 2.473718] FIT: flat_dt sub-image 0x0053c000…0x0053c20f “fdt-mt7622-bananapi-bpi-r64-sata” (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-sata) > [ 11.706074] mt7615e 0000:01:00.0: assign IRQ: got 148 > [ 11.711193] mt7615e 0000:01:00.0: enabling device (0000 -> 0002) > [ 11.717374] mt7615e 0000:01:00.0: enabling bus mastering > [ 11.731640] mt7615e 0000:01:00.0: Invalid MAC address, using random address 6a:7b:0b:d5:0b:d1 > [ 11.758867] mt7622-wmac 18000000.wmac: Invalid MAC address, using random address f2:df:70:e7:a8:9a > [ 11.822532] mt7615e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20180518100604a > [ 11.933254] mt7622-wmac 18000000.wmac: N9 Firmware Version: reserved, Build Time: 20220630094834 > [ 11.972498] mt7615e 0000:01:00.0: N9 Firmware Version: reserved, Build Time: 20200814163649 > [ 11.986634] mt7615e 0000:01:00.0: CR4 Firmware Version: reserved, Build Time: 20190121161307
Which module are you using? Module from AsiaRF, for example, come with a physical EEPROM on the module which contains calibration data. Other modules (such as UniElec) are not intended for end-users, but rather for integrators. They don’t come with a physical EEPROM and hence the calibration data needs to be loaded from somewhere else (such as the host boards flash memory, …)
I don’t know, actually … I bought it as a consumer on alibaba, and live in Europese Does that tell you enough?
Not really. Share a link to where you bought it from or at least a picture of the module itself, so I can try to identify the hardware.
is this sufficient? https://www.aliexpress.com/item/4000260974924.html?spm=a2g0o.order_detail.0.0.1e94f19cpEANeX
So this module also doesn’t have a physical EEPROM. Maybe @sinovoip @sinovoip1 can help here and let us know how they intended this module to be used and if they can share calibration data. You will have to either fork the board code and add this EEPROM to the device tree or use device tree overlay to attache the EEPROM content to a module in a specific PCIe slot.
fine by me … if it’s simply a matter of adjusting the FDT, it’s ok for me. But, off course, I need the calibration data, and a quick example of what I need to modify in the device tree would be fun
I have UniElec’s 7615 which is a very similar card. I think it may have been designed based on the Sinovoip card. It also has no eeprom.
UniElec ships routers with a (very old) custom version of OpenWrt that stores the 7615 card eeprom on a disk partition. I have the scatter and flash files for this (for use with MediaTek’s flash tool). It comes with a couple EEPROM files for their 7615 board. One of the EEPROM files is 64K, one is 256K.
If you get this to work, please share. I have one of the UniElec boards that is useless right now.
great! does anyone have a manual about how to include them in dts files?
This is how it should look like:
Here direct patching of bpi-r3 dts,but it is also possible via overlay…You have to use your data of course 
Thanks for pointing us in the right direction!!
Looking at the driver source code, it looks like the MT7615 driver is looking for up to 19880 bytes of data in the eeprom_data property. Of that, only the first 1024 bytes are the actual eeprom, and the rest is labelled DCOC and TXDP but I don’t think they are required. I don’t think anything except the actual 1024 bytes eeprom is required. Which is good, because the binary files given by UniElec only have real data for the first 1024 bytes. After that it looks like filler, probably just to make up disk space. The good news is I can see some commonalities between UniElec’s eeprom data and the data Frank linked above.
I think I’ll try this myself and see if I can get it working.
let me know … I didn’t get there 
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