Banana Pi BPI-R4 Wifi 7 router board with MediaTek MT7988A (Filogic 880),4G RAM and 8G eMMC

Thanks for schematics.

It seems that FM350 and T99 uses PCIe lane 0 (pins 41 - 49).

Is it possible to add at least resistors to switch from lane 1 to lane 0 in nice way?

R4_pcie_FM350 http://219.143.15.28:3088/esurfing/tim/pim/20210430172231_100759345.pdf

R4_pcie_T99 http://219.143.15.28:3088/esurfing/tim/pim/20201105162420_100320126.pdf

If BOM could stand one more IC - PCIe MUX could be used, i. e. PI3PCIE3212 https://www.diodes.com/assets/Datasheets/PI3PCIE3212.pdf

SEL pin could be driven by CONFIG_0 signal from M.2 connector : conf0

I am not quite certain how others feel about it but I feel quite disappointed seing a hardware upgrade of a device which hasn’t already received official software support. Namely the BPI-R3.

I do understand that there is a proprietary OpwnWRT but that is not really a solution given the lack of software updates and, quite frankly, very old OpenWRT version the BPR-R3 is shipped with.

The Arm a57 also offers a serious performance increase making the R4 the more future proof choice. Future proofness and open source were my main motivators opting for the BPI-R3.

Really disappointing :disappointed_relieved:

Edit: There is already a great article out there which partially compared the R3 to the R4

Whilst the R3 is not obsolete per se since it still offers one of the most compelling and performant hardware specs compared to off the shelf products, the R4 looks hell of a lot more compelling given the plethora of storage options, doubled RAM, better overall design with the antenna ports moved to the bottom of the PCB.

In particular moving the antenna ports show how much brain power was invested. The LEDs are also better placed enabling properly light carriers instead of the flimsy 1mm at most spacing on the R3. Not to speak of the (presumably) much improved BootStrap switches which, quite frankly, still give me some headache.

1 Like

It’s not the time yet, there’s still a lot to change,it may be released later.

Yes, All have added coupling capacitors. :smiley:

Thank you for your suggestions and datasheet!

Because the PCB layout now has not much space to add additional IC.Maybe we change like this:

DTS changed SSUSB_P0 to PCIE_1L_0, then connected to pins 41-49 of KEYB, and routed the USB3.0 on KEYM to KEYB pins 29-37.

make the voltage of KEYB to 3.6V, so that the 5G module can run more stably.

image

image

Simple and efficient :slight_smile:

I see that there are two M.2 and two miniPCIe connectors. M.2 have one PCIe lane each, miniPCIe two PCIe lanes each. Is that correct?

Are there any limits for PCIe usage or all four PCIe controllers are available?

then the bpi-page is wrong as it states only usb there:

  • 1x M.2 KEY-B slot with USB3.2 interface for 5G
  • 1x M.2 KEY-M slot with PCIe3.0 1lane interface for NVME SSD

how much pcie-controllers has mt7988? 2x1Lane and 2x2lane?

are really 4 pcie3 lanes needed for wifi-nic?

Here just PCIe is added, what is good

I think it is also good, not only for WiFi. There PCIe switch could be connected and then board can be used as NAS.

Yes, 2x1Lane and 2x2lane. and the 2x2lane is for wifi.

If we change the schematic according to what I sayed , then we will add PCIe description to the specification of KEY-B.

image

Could You post schematics around SFP connectors?

Just to check compatability with SFP ONT like Nokia ONT G-010S-A.

1 Like

This is what the next version plans to change to.

image

1A can be not enough for some sfp (like gpon).

Can the gmacs switched between sfp (sgmii/1000baseX/2500baseX) and sfp+ (USXGMII/10GBase-KR for 5000M and 10000M)

3.3VD is connected to MP8759GD like BPI-R3.

The current test is a fixed 10G. We added I2C to read the information of the module. hope that the next version of the board can adjust the switching function

wifi 7 function test ok ,all hardware function test ok .

%E5%BE%AE%E4%BF%A1%E5%9B%BE%E7%89%87_20230719172938

2 Likes

So when will it be released in china, and how much?

1 Like

Sinovoip has previously said Q1 2024 for wifi 7 card. Board itself as early as October.

My ISP (Verizon) uses XFP for NG-PON2 (4 x 10G bandwidth for 16 residential subscribers). Even SFP+ power draw is not enough.

@simon I noticed that wifi card is not recognized by pcie driver on cold boot,but after reboot. Maybe we need a delay in pcie driver. Have you seen this too? Maybe this is fixed by v1.0? Imho change wifi-enable into wifi disable may brick pcie devices except the wifi-module,am i right? Of course i can set the regulator in dts,but before (atf,uboot) 12v are always enabled.

Because MTK’s pcie does not have a hotplug function, the 12V power supply of the NIC must be powered on before initializes pcie, and the power-on sequence of the NIC cannot be controlled by software like the V00.

There are still problems with the current wi-fi driver and DDR driver. When using 4GB DDR, it will always reboot after detecting wi-fi, but it can be used stably after limiting the DDR to 2GB.

Isn’t this a problem for other mPCIe cards? As far as i see,12v it put on pins 6, 28 and 48 of the mPCIe slots (cn12+cn14). Afair there were discussions for r64 where users had bricked mPCI cards because of 5v on pin 48,so these slots are for wifi-module only (or at least 12V tolerant cards).

My 1.0 schematic still says WiFi_12V_EN connected to GPIO4_GPIO_A,but yes - switching it off in linux does not makes sense if it is on from poweron till linux-boot (atf+uboot on sw level).

can we get AXP209 support?