Official OpenWrt Support for BananaPi BPi-R64 & what is missing

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.

3 Likes

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?

1 Like

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

1 Like

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?