Hi,
As described [here](http://forum.banana-pi.org/t/bpi-r64-pcie-issues/10284/10) after support from @frank-w. I have used the [GIT ref](https://github.com/frank-w/BPI-R2-4.14/tree/5.4-r64-dsa).
The PCIE coral module gets detected.
O/P of lspci -v -->
00:00.0 PCI bridge: MEDIATEK Corp. Device 3258 (prog-if 00 [Normal decode])
Flags: fast devsel
Memory at <unassigned> (64-bit, prefetchable) [disabled]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 00000000-00000fff
Memory behind bridge: 20000000-201fffff
Prefetchable memory behind bridge: 00000000-000fffff
Capabilities: <access denied>
01:00.0 Non-VGA unclassified device: Device 1ac1:089a (prog-if ff)
Subsystem: Device 1ac1:089a
Flags: fast devsel
Memory at <unassigned> (64-bit, prefetchable) [disabled] [size=16K]
Memory at <unassigned> (64-bit, prefetchable) [disabled] [size=1M]
Capabilities: <access denied>
However, dmesg shows some errors related to pcie
**pci 0000:00:00.0: BAR 0: no space for [mem size 0x200000000 64bit pref]**
**pci 0000:00:00.0: BAR 0: failed to assign [mem size 0x200000000 64bit pref]**
Snapshot of dmesg
[log.txt|attachment](upload://kk6kAgSAo80jlvS4AGHcRZjhYaa.txt) (5.7 KB)
1. What does this error imply ?
2. Can the PCIe device work properly even if this error persits
3. How to get rid of this error ?which pcie-slot do you use?
pcie1/CN8 is shared with sata which is enabled in my dsa-kernel…maybe i need to disable pcie1 to not print error on initialization
you can try the front slot (near sd-slot)…but i guess you already use it…i think lspci will not show it if your on pcie1-slot cause of sata-activation
Currently, I am using miniPCIe(CN25) for Google coral. But I need to use the other slot(CN8) to plug Quectel( EC25) miniPCIe GPRS module.
Can you please suggest the modifications that I need to make in the existing kernel to enable both the pciesetting this to high…but other slot has problems with gen2-cards…so it’s easier to try first one
Can you provide full bootlog for pcie-problem?
Hi Frank,
The boot up log is [dmesg_dtsiOriginal.txt|attachment](upload://oLiTBLviSVfYPePu9cNXaY6IvDz.txt) (42.0 KB) .
As per your suggestions on [ link](http://forum.banana-pi.org/t/bpi-r64-pcie-issues/10284/9),
we modified the dtsi file as
//pcie0
ranges = <0x82000000 0 0x2000000 0x0 0x20000000 0 0x8000000>;
//pcie1
ranges = <0x84000000 0 0x2000000 0x0 0x28000000 0 0x8000000>;
The boot-up logs with these changes are [dmesg_dtsiModified.txt|attachment](upload://wcLjeIRltH9Z1UNSakFa14bByg8.txt) (42.7 KB) .Hi,
I am also working on the same issue. With original dtsi file (no modification in ranges) when I do a lspci I can see some memory is assigned as follows
root@bpi-iot-ros-ai:~# lspci -v
00:00.0 PCI bridge: MEDIATEK Corp. Device 3258 (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Memory at <unassigned> (64-bit, prefetchable)
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 00000000-00000fff
Memory behind bridge: 20000000-201fffff
Prefetchable memory behind bridge: 00000000-000fffff
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Power Management version 3
Capabilities: [80] Express Root Port (Slot+), MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [400] L1 PM Substates
Capabilities: [600] Latency Tolerance Reporting
01:00.0 System peripheral: Device 1ac1:089a (prog-if ff)
Subsystem: Device 1ac1:089a
Flags: bus master, fast devsel, latency 0, IRQ 140
Memory at 20100000 (64-bit, prefetchable) [size=16K]
Memory at 20000000 (64-bit, prefetchable) [size=1M]
Capabilities: [80] Express Endpoint, MSI 00
Capabilities: [d0] MSI-X: Enable+ Count=128 Masked-
Capabilities: [e0] MSI: Enable- Count=1/32 Maskable- 64bit+
Capabilities: [f8] Power Management version 3
Capabilities: [100] Vendor Specific Information: ID=1556 Rev=1 Len=008 <?>
Capabilities: [108] Latency Tolerance Reporting
Capabilities: [110] L1 PM Substates
Capabilities: [200] Advanced Error Reporting
Kernel driver in use: apex
Kernel modules: apexAlso I have a query.
What does the range signify? Is it the memory assigned to PCI ? OR is it mapping PCI memory to physical memory?
Can you move upload/text out of code-block? Else i cannot download it…
Imho first (without 0/0x0) are options/flags, second offset in hosts virtual memory,3rd client offset and 4th size (client).
So original values after splitting should be ok
//pcie0
ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x8000000>;
//pcie1
ranges = <0x82000000 0 0x28000000 0x0 0x28000000 0 0x8000000>;
Hi Frank,
Please find the attachments. File without modifications to dtsi dmesg_dtsiOriginal.txt (42.0 KB) File with modifications to dtsi dmesg_dtsiModified.txt (42.7 KB)
Thank you,have send it to mtk…you can drop my changes,they are wrong. Pcie ranges are bit different
https://elinux.org/Device_Tree_Usage#PCI_Host_Bridge
@batul.rangwala Afaik due to a hardware-issue the slot cn8 does not recognize gen2 cards…just to remember
Hi,
Sharing Additional info that may prove to be useful The module of interest for us is apex module which is used by Google coral mini pcie.
When I try to load that module, it gives the error as [ 8.404060] apex 0000:01:00.0: can’t enable device: BAR 0 [mem 0x00000000-0x00003fff 64bit pref] not claimed [ 8.404079] apex 0000:01:00.0: BAR 2: assigned [mem 0x20000000-0x200fffff 64bit pref] [ 8.404173] apex 0000:01:00.0: BAR 0: assigned [mem 0x20100000-0x20103fff 64bit pref] [ 8.404290] apex 0000:01:00.0: enabling device (0000 -> 0002)
The line [ 8.404060] apex 0000:01:00.0: can’t enable device: BAR 0 [mem 0x00000000-0x00003fff 64bit pref] not claimed mentions about device not claimed.
Any idea what does it imply
Hi Frank https://elinux.org/Device_Tree_Usage#PCI_Host_Bridge Going through the above link I understand we might have to assign range for 3 different spaces as follows
- configuration space
- I/O space
- 32/64 bit memory space
I have tried changing the first part of the range, viz the option/flag. With option = 0x83000000 dmesg_83000000.txt (42.1 KB) With option = 0x43000000 dmesg_43000000.txt (42.5 KB) With option = 0x03000000dmesg_03000000.txt (42.0 KB)
Do we need to look in this direction? By adding ranges for the different memory spaces?
the error is still the same in all 3 dumps
BAR 0: failed to assign [mem size 0x200000000 64bit pref]
we should wait for answer from MTK…
Yes that is right.
Awaiting the response.
Hi Frank,
I have found something on this link https://patchwork.kernel.org/patch/10715171/
There is a similar issue for BAR0 on another processor MT7629. What ever fixes they have added to support PCI with MT7629 are already there in pcie_mediatek.c apart from
+static void mtk_fixup_bar_size(struct pci_dev *dev)
+{
+ struct resource *dev_res = &dev->resource[0];
+ /* 32bit resource length will calculate size to 0, set it smaller */
+ dev_res->end = 0xfffffffe;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MEDIATEK, PCI_DEVICE_ID_MEDIATEK_7629,
+ mtk_fixup_bar_size);
+
Do we have to do something similar for mt7622?
I don’t know,but there is not much magic
You can look if there is a
PCI_DEVICE_ID_MEDIATEK_7622
and just repeat the declare line
patch add it too…
+#define PCI_DEVICE_ID_MEDIATEK_7622 0x7622
So try adding self and look at comments
Especially
res->end = res->start + size - 1;
instead of the bogus value…I guess you need to modify patch to add the
need_fix_device_id = true,
And setting val above
Maybe there is a newer version…
Yes I am trying do the same However the DECLARE line and mtk_fixup_bar_size funtion are not defined in the 5.4 kernel.
Also there is no mention of the git repo where these are actually implemented.
https://elixir.bootlin.com/linux/v5.4/ident/DECLARE_PCI_FIXUP_HEADER
And the function is part of the patch
Btw this sounds similar
https://patchwork.kernel.org/project/linux-mediatek/list/?series=74511