Banana Pi BPI-R64 open source smart router with MTK MT7622 64 bit chip design

most things need porting (started 2nd gmac,but dsa2.c changed too much) maybe my config…

1.DSA framework cannot support 2nd GMAC, and it’s not an easy job to upstream core-layer. In my opinion, it shouldn’t be a problem because TRGMII is 2.5Gbps so LAN/WAN NAT can be 2Gbps if HNAT is enabled.

2.HNAT framework was accepted in 4.16 kernel, and you can refer to openwrt trunk to see the HNAT support based on new framework.

3.Did you mean this patch? https://lore.kernel.org/patchwork/patch/935905/

  1. MTK is working on it, and they’re preparing V2 patch…

  2. MTK reference board/upstream driver is USB3x1 and PCIex3, but BPI-R2 is USB3x2 and PCIex2, so there is no plan to upstream this parts.

  1. I know it’s not easy because its hard to debug…i don’t understand why only 1 cpu is supported. Structure itself allows it,but with the get-first cpu function the cpu-dp is overridden if previous defined. imho we need to load cpu-dp from dts (maybe currently no standard defined) and include them in tearup and teardown

Right,but i had some trouble with it in 4.14…but i try in 4.18…

Imho r2 is the only official board with mt7623,why code matches a reference-board and not the public board?

what is your purpose to apply this patch. it seem upstream driver can support pciex2 and usb3x2 natively. did you need 3rd pcie slot instead of usb3?

no, but sata (connected to a pcie) was unstable

  1. The patch is used to switch usb3 1 (0, 1) to PCIe port 2 (0,1,2) . Anyway, I don’t have plan to send this one to mainline as it will break the common flow.

  2. The R2 DRM patches will be merged in mainline eventually.(4.19 or 4.20 rc cycle)

  3. The good news is we add built-in Bluetooth 5 support for R64. https://patchwork.kernel.org/patch/10566283/

  4. I’m now working on upstreaming uboot (R2/R64) to community.

Todo list:

  1. We have plan to add MT7615/R64 built-in WIFI mainline support

  2. HNAT in mainline.

anyone working on r2 BT-Module (MT8590 or mt6625l)? which is the right name? BT shows name “MTK MT8590 #1” but from spec it should be mt6625l, where google does not find anything except on this domain (forum,wiki,mainpage)

have you added the missing resolutions and is the patch available on patchwork or can i get it here for testing?

is usb3 1 (0, 1) the second usb-port or the usb3-controller itself?

Please ignore MT8590. BT-Module is MT6625 - it’s hard to upstream due to many reasons.

is usb3 1 (0, 1) the second usb-port or the usb3-controller itself?

=> usb2: usb@1a240000

have you added the missing resolutions and is the patch available on patchwork or can i get it here for testing?

hmm, I will consider about this but I can’t give you any answer for that since it mostly falls under the spare time work .

BTW, we will add USB2 (mini usb port) support in mainline in the future .

Is this the mini-usb-port?

If i understand you right,i have to revert pcie-patch if i want to use both usb3-ports…

@moore

include/linux/rtc/mt6397.h does not exist in 4.18…definitions are in drivers/rtc/rtc-mt6397.c, but i cannot patch this, because the header-file is included…seems it is separated by any ohter patch (seems to be this: https://lore.kernel.org/patchwork/patch/935908/)

currently i try to merge the dts-nodes from 4.14…also after merging nodes, power-off still not works…can you take a look whats missing?

in 4.18 mt6323/pwrap is defined in arch/arm/boot/dts/mt6323.dtsi so i tried it like this:

compiles fine, but no poweroff

Is this the mini-usb-port?

If i understand you right,i have to revert pcie-patch if i want to use both usb3-ports…

MT7623 has two usb3 xhci ports and one usb2 (musb) port (mini-usb-port), but we just support XHCI in upstream version now.

And one of the PCIe ports (0,1, “2”) shares its PHY with usb3 xhci port (0, “1”) =>usb@1a240000

1 Like

have reverted the pcie-patch in 4.14

@moore on 4.14 (fc6285a3f9bde6c7bb32c4f79675d696ff2667d3) i have additional patches for

mtk-pmic-keys.c
mt6323-poweroff.c
mt6397-rtc-poweroff.c

did not found this in related patches on patchwork…

Banana Pi BPI-R64 mass production version ready:

What are changes to current version? Is mt7515 still on board?

Has switch changed (rtl8367s,looks still the same)? Thats not bad but there is no dsa-driver for it (have not got swconfig working).

i see that there is an additional pcie-slot

Debug-uart is moved and the wifi-connector is dropped

MT7615 not on board now ,just use it with module. so this module can use on BPI-R2 and BPI-R64

is no bad decision,because there is no opensource-driver for it yet. For r2 i think it cannot be used (at least in rev 1.1) because module is too wide (bend over coils/voltage-regulators next to 40pin-header)

coils on r2: regulators_

which cards have you mounted on? these are normal-width-cards (full size=length)…afair mt7615 is 2times wider (nearly square)

but there are still wifi-antenna-connector at bottom of your picture…

1 Like

maybe we can use some extender like that:

i have tried this one:

but did not getting it working

@sinovoip have you a storage-overview like this for r64? is also preloader needed (if yes which one is the right)?

currently i try gpio…

after adding CONFIG_GPIO_SYSFS to my Kernel i see /sys/class/gpio, but i cannot export it (i try gpio56=pin3)

root@bpi-iot-ros-ai:~# cat /sys/kernel/debug/pinctrl/10211000.pinctrl-pinctrl_mt7622/gpio-ranges
GPIO ranges handled:
0: pinctrl_mt7622 GPIOS [409 - 511] PINS [0 - 102]
root@bpi-iot-ros-ai:~# GPIO_NO=$((409+56))
root@bpi-iot-ros-ai:~# echo $GPIO_NO
465
root@bpi-iot-ros-ai:~# echo $GPIO_NO > /sys/class/gpio/export
-bash: echo: write error: Invalid argument

any idea?

have included BT (from https://github.com/objelf/linux/commit/f5384792c20356d5d49af29aaf0a1c4bc763537e), but it seems i need a firmwarefile

[    5.081560] bluetooth hci0: Direct firmware load for mediatek/mt7622pr2h.bin failed with error -2                                     
[    5.090811] Bluetooth: hci0: Failed to load firmware file (-2)

you can get BT firmware from here :slight_smile:

https://github.com/wkennington/linux-firmware/tree/master/mediatek

thanks, i put the file to /lib/firmware, but still get the error

dmesg | grep hci0
[    4.888999] bluetooth hci0: Direct firmware load for mediatek/mt7622pr2h.bin failed with error -2
[    4.898991] Bluetooth: hci0: Failed to load firmware file (-2)
[    5.058857] bluetooth hci0: Direct firmware load for mediatek/mt7622pr2h.bin failed with error -2
[    5.068074] Bluetooth: hci0: Failed to load firmware file (-2)
root@bpi-iot-ros-ai:~# ls /lib/firmware/
ap6210  ap6212  brcm  mt7622pr2h.bin
root@bpi-iot-ros-ai:~# bluetoothctl
[bluetooth]# power on
No default controller available

where does the driver look for the firmware? i have used kernel-documentation: https://www.kernel.org/doc/html/latest/driver-api/firmware/fw_search_path.html

oh i see that a subfolder mediatek is used…so i put it there…and after reboot i got this:

root@bpi-iot-ros-ai:~# ls /lib/firmware/mediatek
mt7622pr2h.bin
root@bpi-iot-ros-ai:~# dmesg | grep hci0
[   14.819610] Bluetooth: hci0: Execution of wmt command timed out   
[   14.819672] Bluetooth: hci0: Failed to send wmt patch dwnld (-110)

first message seem to come from here: https://github.com/frank-w/BPI-R2-4.14/blob/4.19-r64-main/drivers/bluetooth/btmtkuart.c#L122 second from here: https://github.com/frank-w/BPI-R2-4.14/blob/4.19-r64-main/drivers/bluetooth/btmtkuart.c#L168

so mtk_setup_fw calls

mtk_hci_wmt_sync(hdev, MTK_WMT_PATCH_DWNLD, flag, dlen, fw_ptr);

and this calls

wait_on_bit_timeout(&bdev->tx_state, BTMTKUART_TX_WAIT_VND_EVT, TASK_INTERRUPTIBLE, HCI_INIT_TIMEOUT);

which failed with timeout, did i miss anything (btif should be enabled cause of removed disabled-line)

btif: serial@1100c000 {

so i looked here:

root@bpi-iot-ros-ai:~# cat /sys/firmware/devicetree/base/serial@1100c000/status                                      
okay
root@bpi-iot-ros-ai:~# cat /sys/firmware/devicetree/base/serial@1100c000/bluetooth/status
okay

any idea about gpio? official site makes same calculation but with gpio22 which does not exist on 40pin-header (depending on shematic above)