We do have about 10 BananaPi R64 on our desks ordered from Amazon & AliExpress …all rev. 1.1 (as printed on the pcb).
We just triggered a new order of 12 boards from here [1] … that looks like a rev 1.1 as well.
Which shop sells a rev 1.1+x version, you do call the “sale variant” ?
Greetings Thomas
if your boards are the v1.0 dev-variant (with the realtek-switch) yes…i got message from bpi/mtk/openwrt, that this board can be dropped as these are only for testing the SOC and were not in sale ever…only v1.1 was sold…and this is the one i use (the other lays in my shelf)
picture from aliexpress is a v1.1 (or later) because of 2 pcie slots
and I do not want to sell anything 
i’m user/tester only no employee of BPI
Over here in Europe we have bought several boards (that do have 2x mPCI slots! & 1x internal mt7615 4x4 antenna u.fl pins & mt7531 switch) and can still order them,… so this is rev 1.1. We are not aware of any store to order a rev 1.1+x version from, that does not provide a connectable internal mt7615 wifi.
Greetings Thomas
Hi Graphine … the mt762 wmac SoC has an mt7615 wifi build into the soc and that is the one we have on our BananaPi rev 1.1 with 4 u.fl antenna pins.
the mt7622 wmac is a limited mt7615 (only 2g, no dbdc,…)
@Bluse: have you wrote pm…i guess newer boards starting again with v1.0 
maybe my v1.1 was also a developer version 
had some pcie-trouble (missing capacitors)
Hi Frank,
As the fog disappears … exactly this 2,4GHz on-board mt7622 wmac (limited mt7615) radio is the one, we would like to support properly, hence put the calibration/mac-address data on the boot1/emmc partition as there is no EEPROM and no better reliable storage given.
this should be well documented (i know no good cause to use a second boot-partitions except testing preloaders). and maybe mainline should adapt this to make it same across distributions
For now I made PR to mt76 suggesting to offer an option to load EEPROM data from device tree.
This would also be a good way for devboards like the R64, suggested by @nbd168. I hope my implementation is fine for upstream, as that would allow us to ship OpenWrt images with 2.4GHz WiFi fully functional out-of-the-box.
This is only true for the old versions of the r64 board? To my knowledge, new r64 boards ship with another wifi chip on board.
No there was a dev-board containing additional mt7615. Newer r64 do only have the SOC wifi (mt7622) without calibration data.
Or do i miss anything? Which wifi chip is included on newer (which rev) r64 boards?
Did this ever get sorted out? I have OpenWrt snapshot on my BPI R64 and the MAC address is always randomly assigned. What is the current way in OpenWrt of configuring the MAC address on this board?
Afaik openwrt way is to load firmware for mt7622 from mtd partition,not sure about mt7615 connected via pcie. My repo has a patch for loading firmware-file (eeprom data containing mac-address) from rootfs.
The WiFi EEPROM for MT7622 on the BPi-R64 is embedded into device-tree.
WiFi MAC address is currently random as the board comes completely without any assigned MAC addresses (or calibration data stored on the board, hence the work-around to store the calbration data in DTS)
One way around it would be to (just like we do for the Ethernet MAC) store a randomly generated MAC for the built-in 2.4GHz WiFi in the U-Boot environment and apply it via sysfs during boot. In that way it at least wouldn’t change on every reboot. This shouldn’t be hard to do and I’ll implement it later today.
I didn’t know you could do this through sysfs. How?
diff --git a/target/linux/mediatek/mt7622/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mac b/target/linux/mediatek/mt7622/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mac
index d573465745..e39ca7edf0 100644
--- a/target/linux/mediatek/mt7622/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mac
+++ b/target/linux/mediatek/mt7622/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mac
@@ -14,4 +14,15 @@ case "$board" in
[ "$PHYNBR" = "0" ] && macaddr_add $(get_mac_label) 3 > /sys${DEVPATH}/macaddress
[ "$PHYNBR" = "1" ] && macaddr_add $(get_mac_label) 2 > /sys${DEVPATH}/macaddress
;;
+ bananapi,bpi-r64)
+ if [ ! "$PHYNBR" = "0" ] || [ ! -e /etc/fw_env.config ]; then
+ exit 0
+ fi
+ wifiaddr="$(fw_printenv -n wifiaddr 2>/dev/null)"
+ if [ -n "$wifiaddr" ]; then
+ echo "$wifiaddr" > /sys${DEVPATH}/macaddress
+ else
+ fw_setenv wifiaddr "$(cat /sys${DEVPATH}/macaddress)"
+ fi
+ ;;
esac
Edit: Tested and that works, but only on 2nd boot, as on firstboot /etc/fw_env.config may not have been created yet.
Edit 2: For this to work reliably we’ll have to migrate generation of /etc/fw_env.config from (legacy) uci-defaults to use the new /etc/board.d/ and /etc/board.json mechanism. Then it can work in the same way as applying default wifi settings from there: https://github.com/openwrt/openwrt/pull/4777
I can’t get this to work.
Your patch successfully echoes out the wifiaddr to the sysfs path, and if I cat the sysfs path it is the same as the uboot variable. But the mac address is not actually set. It remains the same as what the device driver sets it to at boot:
root@OpenWrt:/mnt/prime/root# dmesg
...
[ 9.226380] mt7622-wmac 18000000.wmac: Invalid MAC address, using random address b6:8d:bd:96:b8:100:
...
root@OpenWrt:/mnt/prime/root# fw_printenv wifiaddr
wifiaddr=5e:92:b2:be:ad:30
root@OpenWrt:/mnt/prime/root# cat /sys/devices/platform/18000000.wmac/ieee80211/phy0/macaddress
5e:92:b2:be:ad:30
root@OpenWrt:/mnt/prime/root# ifconfig
...
wlan0 Link encap:Ethernet HWaddr B6:8D:BD:96:B8:00
inet addr:192.168.2.76 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::b48d:bdff:fe96:b800/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1523 errors:0 dropped:0 overruns:0 frame:0
TX packets:89 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:261092 (254.9 KiB) TX bytes:11135 (10.8 KiB)
root@OpenWrt:/mnt/prime/root# ip link set wlan0 down
[ 416.750766] wlan0: deauthenticating from a0:63:91:4b:b7:80 by local choice (Reason: 3=DEAUTH_LEAVING)
root@OpenWrt:/mnt/prime/root# ip link set wlan0 address `fw_printenv -n wifiaddr`
root@OpenWrt:/mnt/prime/root# ip link set wlan0 up
[ 454.571052] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[ 454.587558] wlan0: authenticated
[ 454.609216] wlan0: associated
[ 455.701897] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
root@OpenWrt:/mnt/prime/root# ifconfig
...
wlan0 Link encap:Ethernet HWaddr 5E:92:B2:BE:AD:30
inet addr:192.168.2.4 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::5c92:b2ff:febe:ad30/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1596 errors:0 dropped:0 overruns:0 frame:0
TX packets:115 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:265999 (259.7 KiB) TX bytes:15819 (15.4 KiB)
You will have to re-create the wdev as the mac address is only set for the phy at this point. If you use /etc/config/wireless the mac address now set to the phy will be applied.
I patched my /etc/hotplug.d/11_fix_wifi_mac with your patch. Is it being called after the wdev is already made??
I am using /etc/config/wireless to configure the device, and when I boot it’s not taking the address set by your patched 11_fix_wifi_mac. I have to script “ip link wlan0 down/address/up” in a separate file to get the mac address set.
The initial wdev is created for legacy/compatibility reasons when the driver is loaded (as early wifi drivers in Linux always created one wdev network interface). It is not used in when you use OpenWrt’s UCI /etc/config/wireless to configure wifi.
Fair enough. I’ll just stick with my boot script to set the MAC address.
Maybe the UCI system at some point could be patched to pull the mac address from uboot too?