The processor MT7622 and especially the switch MT7531 are very hot (60°C) also on my board. I attached heatsinks on top of these chips. I can touch the heatsink of the CPU but the switch for not long time. The board nicely fits in the case of an old Wyse Cx0 thin client PC.
1 Like
I’m using Openwrt with 5.10 kernel but can not get PCIe working.
lspci just gives nothing.
GPIO 499 stays in low level, I can’t switch it to high. Suppose this is the reason.
Also tried a build from BPi 20210501 but getting jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 on load
on r64 gpio 90 is used for switching between sata (low)/pcie (high)
additional to this your codebase needs the pcie-splitting patches to use both pcie-slots
I got GPIO number from here.
It says that we should sum 409+xx, where xx - GPIO number we need.
But anyways, I get write error: Resource busy
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)
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
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=00Which kind of mPCIe hardware are you using? And have you tried both slots?
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.
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
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)
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?
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]/
Yes, we got both patches in recent OpenWrt with Linux 5.10:
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?
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
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.
afair uboot-way depends on right dts. it needs mac-address property and alias for ethernet-node
Run this in openwrt:
fw_setenv ethaddr newaddress
Or in uboot
setenv ethaddr newaddress
saveenv
1 Like
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.