Hy 
The m2 slot is a Key m, isn’t it?
It should be key-e…
need to use an adaptater, what you want to say?
As you’ve wrote that your wifi-card is mpcie…yes you need an m.2 key-e adapter
I have a mpcie card wifi but i can buy an m2 version like this one https://www.sparklan.com/product/wnfq-269axbt-wifi6-wifi6e-11ax-triband-m-2-dbdc-module/
The bananapi i have has a m2 key m slot (written on the board). So if i want to keep my mpci, i need an m2 key m adaptateur. Also if i take a card m2 key e, i need an m2 key m to key e adaptator,isn’t it?
https://wiki.banana-pi.org/Banana_Pi_BPI-R3
M.2 KEY-E PCIe inerface
Key-m is m-sata afaik,but afair also key-m cards were matching. I have a nvme in my slot.
you’re right, slot is a key-m (4/5 pins on small side till separator). but only pcie is connected and no sata lanes. and bpi wiki is the wrong
lower image taken from https://www.delock.de/infothek/M.2/M.2.html
nvme imho use key b+m (centered in image)
updated my wiki with this information
Do you thank i Can use this adaptator https://amzn.eu/d/eY73lCQ
Hope it will be a r3 pro version with m2 Key e and more ram ^^
i’m no expert in m.2, only use it for nvme 
imho it will be better to replace mPCIe with m2 too (and usb3 there instead of usb2 wit use 5g modems too without dropping the usb3 port in front => usb3-hub instead of usb2 hub)
and yes more RAM will be better
here is the pcie-patch i’m talking about (if card in m.2 slot is not recognized): 611-pcie-mediatek-gen3-PERST-for-100ms.patch (677 Bytes)
Took from here and asked author for his data to sent it upstream on 2023-04-01
1 Like
A bit off-topic maybe, but since we are also talking about more RAM…
I also found it strange why Banana Pi didn’t go for 4GB RAM chip instead.
That being said, how is your RAM usage overall? Are you hitting any limits regarding the RAM?
Hello! I,m noob.Please tell me how to apply this patch.I have one Adata Legend710 512GB x3 and not recognized. Thank you!! PS Use openwrt last snapshot version.
You need to rebuild openwrt by yourself. Afaik you have to put patch into patches directory
https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/mediatek/patches-5.15;hb=HEAD
1 Like
I applied a kernel patch and compile a new openwrt image ,creat partition,mount and now my SSD M,2 Adata Legend 710 (PCIe Gen3 x4) work perfectly. Thank you !
you have applied the patch i’ve mentioned above?
btw. bpi-r3 is only pcie3 x2, so it will not completely use the speed from this SSD
Yes i applied the patch , thanks again! I tested whit hdparm and speed is ~650MB/s .
sent Patch to mainline
https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/
1 Like
Can you please tell me which pcie devices failing (without patch) with full dmesg?
Mtk responded to patch
- patch cause regression on platforms with multiple pcie-ports
- r3 seem to miss coupling capacitors and so problem seems to be caused by signal quality
https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/#25317833
@sinovoip @simon can you confirm this or give mtk (Jianjun Wang) the full shematic?
Can anyone (maybe @RRKh61 @f11 @doudootiana ) please try to remove the existing msleep(100) above the patch and test if the issue is still fixed? As i do not had the issue i cannot verify it…seems to only happen with some special m.2 devices
Hello Frank.
I tested the patch with removing the existing msleep(100), it gave the same result as without the patch, i.e. no disk detection on cold start.
In attach modified patch and “Kernel Log” for cold start with original patch and cold/hot start with modified patch (no existing msleep(100)).
modified_bad.patch (702 Байта) good_patch_cold_start.txt (31.5 КБ) bad_patch_cold_start.txt (22.3 КБ) bad_patch_hot_start.txt (31.2 КБ)
P.S. My NVME SSD Patriot P300P1TBM28, probably NVME controller - Maxio MAP1202A-F1C
1 Like
Hi RRKh61,
Can you please try if the following changes work for your case?
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -341,16 +341,22 @@ static int mtk_pcie_startup_port(struct mtk_gen3_pcie *pcie)
val |= PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB | PCIE_PE_RSTB;
writel_relaxed(val, pcie->base + PCIE_RST_CTRL_REG);
+ usleep_range(10 * 1000, 15 * 1000);
+
+ /* De-assert reset signals */
+ val &= ~(PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB);
/*
* Described in PCIe CEM specification sections 2.2 (PERST# Signal)
* and 2.2.1 (Initial Power-Up (G3 to S0)).
* The deassertion of PERST# should be delayed 100ms (TPVPERL)
* for the power and clock to become stable.
*/
- msleep(100);
+ msleep(90);
- /* De-assert reset signals */
- val &= ~(PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB | PCIE_PE_RSTB);
+ /* De-assert PERST# signals */
+ val &= ~PCIE_PE_RSTB;
writel_relaxed(val, pcie->base + PCIE_RST_CTRL_REG);
1 Like
I’m able to reproduce this behaviour as well, and my hardware is similar to RRKh61.
NVMe: Patriot P310P240GM28, reported as MAXIO Technology (Hangzhou) Ltd. NVMe SSD Controller MAP1202 (rev 01)
For the dmesg output attached I’ve taken notes and placed those at the beginning of those files to attempt to make it clear what each dmesg output pertains to. This includes noting if the PCI root is visible in lspci on cold boot as well as the nvme drive, and including the patch used on the kernel that the output was produced from.
-
No patch In general, the PCI root doesn’t appear, but sometimes it and the nvme drive will show up on a cold boot, it’s exceedingly rare though. bpir3-dmesg-and-notes.txt (27.1 KB)
-
frank-w’s original patch Two dmesg are included. One where the PCI root exists, but no NVMe and the other with both. The nvme worked once out of over 20 cold boots. bpir3-frankw-coldboot1-dmesg-and-notes.txt (28.1 KB) bpir3-frankw-coldboot2-dmesg-and-notes.txt (29.7 KB)
-
jianjun’s patch, as posted. This was the same as no-patch. It looks to me that the patch is missing a write to the device registers between
/* De-assert reset signals */and themsleep(90). bpir3-jianjun-patch-dmesg-and-notes.txt (28.0 KB) -
jianjun’s patch with
writel_relaxed(val, pcie->base + PCIE_RST_CTRL_REG);inserted afterval &= ~(PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB);, patch included in the attached dmesg, which should retain formatting. I cold-booted this one 5 times and each time received the PCI root, but no NVMe device. bpir3-jianjun-patch-modified-dmesg-and-notes.txt (28.9 KB)