It’s a BPI-MT7615 module. Should I contact @sinovoip?
I have issues on official LEDE image too: when I bring up mt7615 module system goes in reboot.
It’s a BPI-MT7615 module. Should I contact @sinovoip?
I have issues on official LEDE image too: when I bring up mt7615 module system goes in reboot.
Hi, @svintuss
Would you please create a github repo for all patches and firmware bin. I can’t follow your approach. Thanks.
Sure, will do that soon. I just want to find out how to make OpenWRT patches from manually modified files. I don’t like a “compile - install - make changes - recompile again - replace modules on working system” approach.
I’ve got some progress here.
After several hours of load testing with iperf3
I found out that mt7615 makes system crash if TX power exceeds 21 dBm. That means that in ‘AU’ or ‘US’ regional domains one have to manually limit TX power to 21 dBm.
I don’t know yet whether it’s my unit’s or a general BPI-MT7615 board/driver problem.
I also have that problem. I got a solution from BPI. If you want use BPI-MT7615 module on BPI-R64 board, The R64 board must modify a resistance to provide more power to the pci-e slot.
Which slot (pcie0,cn25?), which resistant and to which value?
You’re right.
Thanks to the assistance of 肖 [email protected] from @sinovoip I’ve managed to solve the TX power crash problem.
BPI-R64’s mPCIe slot current is limited to 1.5A (1.44A to be precise). When TX power of mt7615e board exceeds 22 dBm it starts to draw too much current and the whole system crashes.
This 1.5A limit is managed by SY6280 programmable switch. There are two solutions:
I tried method 1, I can confirm that it works. Board is stable with 23 dBm TX power. Maybe the same procedure could be done to CN8 slot too.
UPD: There seems to be an issue with method 1: mt7615e goes up only after initial power on. If one reboots the board or presses reset
button there comes up this message in kernel log:
[ 12.231122] mt7615e 0000:01:00.0: Firmware is not ready for download
UPD2: Can confirm that method 2 works without issue. After changing R217 to 3KOhm the board is working fine on 23 dBm.
Cn8 has additional problem with missing capacitors on tx-lines
Is there any new state using eeprom from file? In Mainline i see only mtd version (which conflicts with mt7622), and mtd in 5.4 is broken (at least in openwrt)
And also mt76 git
hi svintuss,
I encounter this problem too. when I use MT7615 5g wifi, the board will be stuck then reboot. don’t have any log output. I hard to debug with my less knowledge of it without any log output in console.
i am remove the paython,when make it ,get this error:
–without-pymalloc CONFIG_SITE= ; fi )
configure: error: Please install autoconf-archive package and re-run autoreconf
Makefile:352: recipe for target '/home/neo/BPI_R64_OpenWRT/openwrt/build_dir/hostpkg/Python-3.9.4/.configured' failed
make[3]: *** [/home/neo/BPI_R64_OpenWRT/openwrt/build_dir/hostpkg/Python-3.9.4/.configured] Error 1
make[3]: Leaving directory '/home/neo/BPI_R64_OpenWRT/openwrt/feeds/packages/lang/python/python3'
time: package/feeds/packages/python3/host-compile#5.97#0.40#8.36
package/Makefile:111: recipe for target 'package/feeds/packages/python3/host/compile' failed
make[2]: *** [package/feeds/packages/python3/host/compile] Error 2
make[2]: Leaving directory '/home/neo/BPI_R64_OpenWRT/openwrt'
package/Makefile:107: recipe for target '/home/neo/BPI_R64_OpenWRT/openwrt/staging_dir/target-aarch64_cortex-a53_musl/stamp/.package_compile' failed
make[1]: *** [/home/neo/BPI_R64_OpenWRT/openwrt/staging_dir/target-aarch64_cortex-a53_musl/stamp/.package_compile] Error 2
make[1]: Leaving directory '/home/neo/BPI_R64_OpenWRT/openwrt'
/home/neo/BPI_R64_OpenWRT/openwrt/include/toplevel.mk:218: recipe for target 'world' failed
make: *** [world] Error 2
copying kernel,dt, rootfs
cp: cannot stat 'build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/bpi_bananapi-r64-kernel.bin': No such file or directory
cp: cannot stat 'build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/image-mt7622-bananapi-bpi-r64.dtb': No such file or directory
cp: cannot stat 'build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/root.ext4': No such file or directory
done. Copy folder r64-boot into root folder of USB drive (at least 4GB needed)
Have you tried this?
The R64 is fully supported by mainline OpenWrt by now, no need to start off with outdated vendor-modified version of OpenWrt. You can follow the documentation on Build system setup regarding the prerequisites.
Then clone OpenWrt and launch menuconfig
git clone https://git.openwrt.org/openwrt/openwrt.git/
cd openwrt
scripts/feeds update
scripts/feeds install -a
make menuconfig
Then select R64 board and packages you would like:
Then trigger build using make -j$(nproc)
and wait for a long time
A third option, like option 1 is to disable the current limiting by shorting pins 2 and 3. i.e. using a 0 ohm Resistor for R217 the ISET. This leaves the EN pin still functional so the reboot works. I was successful with this approach.
My ugly solder job:
Hello guys. It’s been some time since I tried to make use of BPI R64 and I fell off track. Could somebody fast forward me on recent updates regarding OpenWRT support?
Installation to eMMC (and SPI-NAND) can be done using the bootloader menu when booting from SD card and also triggered to happen on next boot my modifying bootloader environment from inside OpenWrt. See https://openwrt.org/toh/sinovoip/bananapi_bpi-r64_v1.1#sd_card_installation
The opposite is true now: There are only squashfs images, the same image can be used on SPI-NAND, eMMC and SD card for sysupgrade.
mt76 still doesn’t supper loading EEPROM for MT7622 built-in 802.11bgn WiFi in a meaningful way for this board, you will need to patch to load from file.
Yes, Bluetooth works out of the box.
mt76 still doesn’t supper loading EEPROM for MT7622 built-in 802.11bgn WiFi in a meaningful way for this board, you will need to patch to load from file.
EEPROM can be flashed to SPI-NAND and mt76 can load it from there as intended:
Thank you.
This trick won’t work for MT7615, right? I still have to hardcode firmware in its driver?
AFAIK, mt7615 boards have own internal EEPROM and no other data required from system, maybe I’m wrong.