[Banana Pi BPI-R64] Mainline OpenWRT image

Banana Pi Router design BPI-R64(MT7622)
237

gpio90 can be set only on bootup via Devicetree (asmsel)

see activation of sata in my repo:

the base+XX calculation is imho only for gpio-header (attention base differs from board to board)

238

In OpenWrt I solved the mPCIe/SATA switch using device-tree overlay. In that way you can specify the desired configuration in the bootloader environment which is accessible inside OpenWrt using the fw_printenv and fw_setenv commands. By default it is set to enable mPCIe.

fw_printenv bootconf
bootconf=config-mt7622-bananapi-bpi-r64-pcie1

To use the SATA port instead you can run

fw_setenv bootconf config-mt7622-bananapi-bpi-r64-sata

There is no need to make any low-level changes yourself. If bootconf is already set to config-mt7622-bananapi-bpi-r64-pcie1 and your mPCIe module is not detected, there must be another reason for that. I’m using my BPi-R64 board with an MT7615E mPCIe module installed in the 2nd slot and it has been working great so far (it’s an over-sized module and cannot fit into the first slot which I have actually never tried).

Also note that the one of the mPCIe slots (the one closer to the Ethernet ports) always works, even in case SATA configuration is selected.

1 Like
239

Thank you, I checked bootconf and it loads pcie, but still lspci gives empty reply. Dmesg

 root@OpenWrt:/# dmesg |grep pci
[    2.936248] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
[    2.942787] mtk-pcie 1a143000.pcie: Parsing ranges property...
[    2.948641] mtk-pcie 1a143000.pcie:      MEM 0x0020000000..0x0027ffffff -> 0x0020000000
[    3.058185] mtk-pcie 1a143000.pcie: Port0 link down
[    3.067274] mtk-pcie 1a143000.pcie: PCI host bridge to bus 0000:00
[    3.073452] pci_bus 0000:00: root bus resource [bus 00-ff]
[    3.078955] pci_bus 0000:00: root bus resource [mem 0x20000000-0x27ffffff]
[    3.085827] pci_bus 0000:00: scanning bus
[    3.091122] pci_bus 0000:00: fixups for bus
[    3.095297] pci_bus 0000:00: bus scan returning with max=00
[    3.102408] mtk-pcie 1a145000.pcie: host bridge /pcie@1a145000 ranges:
[    3.108979] mtk-pcie 1a145000.pcie: Parsing ranges property...
[    3.114815] mtk-pcie 1a145000.pcie:      MEM 0x0028000000..0x002fffffff -> 0x0028000000
[    3.223032] mtk-pcie 1a145000.pcie: Port1 link down
[    3.228049] mtk-pcie 1a145000.pcie: PCI host bridge to bus 0001:00
[    3.234228] pci_bus 0001:00: root bus resource [bus 00-ff]
[    3.239719] pci_bus 0001:00: root bus resource [mem 0x28000000-0x2fffffff]
[    3.246591] pci_bus 0001:00: scanning bus
[    3.251886] pci_bus 0001:00: fixups for bus
[    3.256071] pci_bus 0001:00: bus scan returning with max=00
240

Which kind of mPCIe hardware are you using? And have you tried both slots?

241

I have 2 wifi cards: QCA9882 and QCA9984. Both from Compex WLE600VX and WLE1216v5. They are 100% working cards, I tested both of them in another PC. I’v tried both slots, alone and together, mixed vice-a-versa.

Also I loaded board with Openwrt snapshot built, my own build, 21rc build. And got no luck.

Even without any cards at all I should get something from lspci.

242

No, this is not true. If I have both slots empty, lspci also doesn’t show anything, not even host bridges. So what you are seeing is (from software point of view) just both slots empty and/or link down.

With both slots populated, it looks like this on my board:

0000:00:00.0 PCI bridge: MEDIATEK Corp. Device 3258
0000:01:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
0001:00:01.0 PCI bridge: MEDIATEK Corp. Device 3258
0001:01:00.0 Unclassified device [0002]: MEDIATEK Corp. Device 7615

I don’t have any QCA modules here for testing, but I’ve heard that the R64 is picky about mPCIe modules. (the AX200 is sitting in mPCIe to NGFF adapter and works fine. it can only do client mode, like all Intel wifi NICs, though…)

Update: The Compex modules you mentioned seem to be problematic, see also [BPI-R64] PCIe issues

243

There were pcie hardware-issues on r64

  • missing capacitors on tx lines (causing some cards not detected,maybe depend on bus speed)
  • limited current (causing tx power limited on mt7615)

Maybe you fall into one of these.they are known and should be fixed in next hw-rev,but idk if this hardware is ready

there is a limitation that only one pcie-slot supports usb passthrough (afair the one shared with sata). So if card needs this (like some 4g modems) cards do not work correctly (but should shown up in lspci)

244

I was looking through this thread, and yes there are some issues with those cards at least on older kernels (I’m using 5.10).

Do you have any info about those caps? May be it possible to add them like changing protective resistors?

245

only this: [BPI-R64] PCIe issues

pcie-splitting is not yet merged to mainline, but maybe existent in openwrt

https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/

https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/

246

Yes, we got both patches in recent OpenWrt with Linux 5.10:

247

I know it has been discussed before, but the Sinovoip support pages disappeared, so I can’t find the method for setting permanent eth1 (wan) and eth0 (br-lan) MAC address. Is there any way to set it in U-boot or elsewhere?

248

Afair that was nowhere in official documents,but i have it written down here (os independ,but ifupdown/systemd maybe not working in openwrt):

https://www.fw-web.de/dokuwiki/doku.php?id=en/bpi-r2/network/start#mac-address

249

Thanks, but unfortunately I couldn’t make it in OpenWRT. There was a setenv command in previous u-boot menu, for setting mac address, but it is gone.

250

afair uboot-way depends on right dts. it needs mac-address property and alias for ethernet-node

251

Run this in openwrt:

fw_setenv ethaddr newaddress

Or in uboot

setenv ethaddr newaddress

saveenv

1 Like
252

I applied the fw_setenv ethaddr command, and it changed the MAC address indeed (after rebooting). Now every interface has the same MAC address. I think it changed the internal bridge address. Is there any way to specify it separately for the wan/eth1 also? Perhaps it is not so important, because br-lan and wan are on different segments, so there should be no ARP conflict.

253

It changes adress of eth0 (gmac between soc and switch). eth1 should not exist and wan (dsa port) is connected to eth0 too

254

Independently of the main MAC address you may configure an individual mac address for wan port (or any other port) in OpenWrt. This works in LuCI:

wan-mac
wan-mac.png894×801 83.5 KB

or in CLI:

uci add network device
uci set network.@device[-1].name= 'wan'
uci set network.@device[-1].macaddr= '02:03:04:05:06:07'
255

Thanks, it worked :+1:

256

I upgraded luci-mod-network and it handles the bridge interface differently that it used before. But now the LAN bridge does not have any fixed IP address and it does not act as a DHCP server. What should I change in the new config? Here is the bridge related section in the /etc/network/config:

config interface 'lan'
    option proto 'static'
    option ipaddr '192.168.0.1'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option ifname 'br-lan'

config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'lan1'
    list ports 'lan2'
    list ports 'lan3'
    list ports 'lan4'