BAR 0: no space for [mem size 0x200000000 64bit pref]

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 pcie

setting 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

[email protected]:~# 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: apex

Also 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

Thanks for your support @frank-w

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

  1. configuration space
  2. I/O space
  3. 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