PPE works on my bpi-r4 branch, but even without it I was able to get 9.5gbps~ with Mellanox connectx3 on the other end
Can you share a link
Iāve looked at the patch and the part relevant to get PPE working with 4 GiB boils down to
Using all 3 PPE units is still on another page, of courseā¦
Iāve also figured out why 100M/10M speeds were not working and got a fix for that as well
Please re-test with my updated tree on [WIP/RFC] mediatek: switch to Linux 6.1 and add BananaPi BPi-R4 by dangowrt Ā· Pull Request #14140 Ā· openwrt/openwrt Ā· GitHub or build from mt7988-for-next branch of GitHub - dangowrt/linux: Linux kernel source tree .
Oooh, youāre getting real close lol
I modified mtk_gdm_condig to work on a targeted mac instead of all devices, but then something becomes unresponsiveā¦ need to debug it further
Hi! I want to make sure I understand powering the board via the DC in barrel connector.
- On the PCB next to the connector is printed āDC12Vā.
- But in the wiki it says 12V or 19V/3.2A (I understand the full aperage will not be needed without peripherals)
- And on the forum here it says it can tolerate 9-24V
I can just power the BPI-R4 with a 20V supply? And I donāt have to set any jumpers or sw4 assuming I am not using the WiFi extension card? Can I simply input 20V at the barrel connector where it says 12V? And the polarity of the connector should be inside positive?
Yes, I supply it with 20V USB PD charger
Thanks for the reply! Just to confirm so I donāt blow up my board accidentally:
I know that the USB Type C port will trigger 20V from the USB supply and this works. But I can also input 20V directly into the barrel jack (5.5x2.1mm) which has 12V printed next to it on the PCB? And the inside is positive polarity?
The voltage that the DC12V socket can accept is 9~24V, so a 20V power adapter can be plugged in.
YESļ¼inside is positive polarity
Except the 3 PPE, it looks like WED is also not working, at least with a 7915 card. I think we are missing the 3 firmwares required and also some dts entries to enable it.
I think dts changes would be something like this
diff --git a/target/linux/mediatek/files-6.1/arch/arm64/boot/dts/mediatek/mt7988a.dtsi b/target/linux/mediatek/files-6.1/arch/arm64/boot/dts/mediatek/mt7988a.dtsi
index 15a1bdd..8606592 100644
--- a/target/linux/mediatek/files-6.1/arch/arm64/boot/dts/mediatek/mt7988a.dtsi
+++ b/target/linux/mediatek/files-6.1/arch/arm64/boot/dts/mediatek/mt7988a.dtsi
@@ -168,6 +168,78 @@
reg = <0 0x43000000 0 0x50000>;
no-map;
};
+
+ wmcpu_emi: wmcpu-reserved@47CC0000 {
+ reg = <0 0x47CC0000 0 0x00100000>;
+ no-map;
+ };
+
+ wo_emi0: wo-emi@4F600000 {
+ reg = <0 0x4F600000 0 0x40000>;
+ no-map;
+ };
+
+ wo_emi1: wo-emi@4F640000 {
+ reg = <0 0x4F640000 0 0x40000>;
+ no-map;
+ };
+
+ wo_emi2: wo-emi@4F680000 {
+ reg = <0 0x4F680000 0 0x40000>;
+ no-map;
+ };
+
+ wo_data: wo-data@4F700000 {
+ reg = <0 0x4F700000 0 0x800000>;
+ no-map;
+ };
+
+ wo_ilm0: wo-ilm@151E0000 {
+ reg = <0 0x151E0000 0 0x8000>;
+ no-map;
+ };
+
+ wo_ilm1: wo-ilm@152E0000 {
+ reg = <0 0x152E0000 0 0x8000>;
+ no-map;
+ };
+
+ wo_ilm2: wo-ilm@153E0000 {
+ reg = <0 0x153E0000 0 0x8000>;
+ no-map;
+ };
+
+
+ wo_dlm0: wo-dlm@151e8000 {
+ reg = <0 0x151e8000 0 0x2000>;
+ no-map;
+ };
+
+ wo_dlm1: wo-dlm@152E8000 {
+ reg = <0 0x152E8000 0 0x2000>;
+ no-map;
+ };
+
+ wo_dlm2: wo-dlm@153E8000 {
+ reg = <0 0x153E8000 0 0x2000>;
+ no-map;
+ };
+
+ wo_boot0: wo-boot@15194000 {
+ reg = <0 0x15194000 0 0x1000>;
+ no-map;
+ };
+
+ wo_boot1: wo-boot@15294000 {
+ reg = <0 0x15294000 0 0x1000>;
+ no-map;
+ };
+
+ wo_boot2: wo-boot@15394000 {
+ reg = <0 0x15394000 0 0x1000>;
+ no-map;
+ };
+
};
soc {
@@ -1055,6 +1127,72 @@
};
};
+ wed0: wed@15010000 {
+ compatible = "mediatek,mt7988-wed",
+ "syscon";
+ reg = <0 0x15010000 0 0x2000>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
+ memory-region = <&wo_emi0>, <&wo_ilm0>, <&wo_dlm0>,
+ <&wo_data>, <&wo_boot0>;
+ memory-region-names = "wo-emi", "wo-ilm", "wo-dlm",
+ "wo-data", "wo-boot";
+ mediatek,wo-ccif = <&wo_ccif0>;
+ };
+
+ wed1: wed@15012000 {
+ compatible = "mediatek,mt7988-wed",
+ "syscon";
+ reg = <0 0x15012000 0 0x2000>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>;
+ memory-region = <&wo_emi1>, <&wo_ilm1>, <&wo_dlm1>,
+ <&wo_data>, <&wo_boot1>;
+ memory-region-names = "wo-emi", "wo-ilm", "wo-dlm",
+ "wo-data", "wo-boot";
+ mediatek,wo-ccif = <&wo_ccif1>;
+ };
+
+ wed2: wed@15014000 {
+ compatible = "mediatek,mt7988-wed",
+ "syscon";
+ reg = <0 0x15014000 0 0x2000>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH>;
+ memory-region = <&wo_emi2>, <&wo_ilm2>, <&wo_dlm2>,
+ <&wo_data>, <&wo_boot2>;
+ memory-region-names = "wo-emi", "wo-ilm", "wo-dlm",
+ "wo-data", "wo-boot";
+ mediatek,wo-ccif = <&wo_ccif2>;
+ };
+
+ wed_pcie: wed_pcie@10003000 {
+ compatible = "mediatek,mt7988-wed-pcie",
+ "syscon";
+ reg = <0 0x10003000 0 0x10>;
+ };
+
+ wo_ccif0: syscon@151A5000 {
+ compatible = "mediatek,mt7988-wo-ccif", "syscon";
+ reg = <0 0x151A5000 0 0x1000>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ wo_ccif1: syscon@152A5000 {
+ compatible = "mediatek,mt7988-wo-ccif", "syscon";
+ reg = <0 0x152A5000 0 0x1000>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ wo_ccif2: syscon@153A5000 {
+ compatible = "mediatek,mt7988-wo-ccif", "syscon";
+ reg = <0 0x153A5000 0 0x1000>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
ethsys: syscon@15000000 {
#address-cells = <1>;
#size-cells = <1>;
@@ -1317,6 +1455,8 @@
mediatek,xfi-pll = <&xfi_pll>;
mediatek,infracfg = <&topmisc>;
mediatek,toprgu = <&watchdog>;
+ mediatek,wed-pcie = <&wed_pcie>;
+ mediatek,wed = <&wed0>, <&wed1>, <&wed2>;
#reset-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
--
libgit2 1.7.1
And possibly this check in mtk_wed_mcu
if(wo->hw->index == 0)
fw_name = MT7988_FIRMWARE_WO0;
else if (wo->hw->index == 1)
fw_name = MT7988_FIRMWARE_WO1;
else
fw_name = MT7988_FIRMWARE_WO2;
break;
Tried applying it but there are some errors. Disabling wed in modules.conf makes the card initialize.
[ 11.291280] mt7915e 0000:01:00.0: assign IRQ: got 115
[ 11.296356] mt7915e 0000:01:00.0: enabling device (0000 -> 0002)
[ 11.302402] mt7915e 0000:01:00.0: enabling bus mastering
[ 11.427032] mt7915e 0000:01:00.0: attaching wed device 0 version 3
[ 11.541597] platform 15010000.wed: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[ 11.552059] platform 15010000.wed: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[ 11.562487] platform 15010000.wed: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[ 11.572909] platform 15010000.wed: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[ 11.583331] platform 15010000.wed: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[ 11.593752] platform 15010000.wed: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[ 11.604174] platform 15010000.wed: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[ 11.614595] platform 15010000.wed: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[ 11.625017] platform 15010000.wed: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[ 11.635438] platform 15010000.wed: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[ 11.677046] mt7915e 0000:01:00.0: Failed to get patch semaphore
[ 11.737575] mt7915e: probe of 0000:01:00.0 failed with error -11
EDIT: Donāt try this, it might have broken something at hardware level, now flow offload does not pass traffic correctly even after reverting all changes.
Thanks for your reply , just wanted to know or if i can know current status of development, i need to buy the new boardā¦you see excited.
Wifi7 spec is not finalised yet , and not many devices around, so relax still a year away, people havenāt move to wifi6e yet .
I got multiple PPEs to work, one for each GMAC. I forgot that mtk_gdm_config only called once, thatās why it didnāt work at first. the patch is a huge mess, iāll split it and clean up tomorrow filogic: fix multiple PPEs, add RSS+LRO Ā· eladwf/openwrt@78aa8d5 Ā· GitHub
I had these errors before 4g ram support was added to switch driver.
Try limiting ram to 3G (kernel cmdline) and test again
Nice,have you tried getting 10g throughput with lro enabled over one of the sfp slots?
LRO still doesnāt work for me.
@dangowrt Iām assuming weāre not event at the point yet for any 6 Ghz testing with your build on the R4? Iāve been messing around with different packages/configs with a 7916 module but no luck yet.
I have been using 2 R4 running the code from the WIP on github with one AsiaRF MT7916 card each on 6GHz and achieved stable performance of ~1.5Gbps across the table (also tested the same setup with one AX210 card as client on the R4 and worked perfectly but slightly lower performance of ~1.2Gbps and a Pixel 7 also with similar results).
Was there any configs/packages you needed to configure to get it working on that build? I canāt get 6ghz enabled