[BPI-R64] How to enable BPI PCIe slot 0?

I’m trying to get openwrt working on my bananapi R64. I’m currently using master github branch and compile it myself. I want to use the PCIe slot 0 for my AX card (slot 1 is populated with an 802.11AC card). In the boot log, I see the following:

[    7.779509] devices_kset: Moving 1a143000.pcie to end of list
[    7.789412] platform 1a143000.pcie: Retrying from deferred list
[    7.799627] bus: 'platform': driver_probe_device: matched device 1a143000.pcie with driver mtk-pcie
[    7.816715] bus: 'platform': really_probe: probing driver mtk-pcie with device 1a143000.pcie
[    7.832663] mtk-pcie 1a143000.pcie: no init pinctrl state
[    7.843149] mtk-pcie 1a143000.pcie: no sleep pinctrl state
[    7.848636] mtk-pcie 1a143000.pcie: no idle pinctrl state
[    7.858590] mtk-pcie 1a143000.pcie: adding to PM domain hif0
[    7.870117] mtk-pcie 1a143000.pcie: genpd_add_device()
[    7.881179] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
[    7.892030] mtk-pcie 1a143000.pcie: Parsing ranges property...
[    7.902726] mtk-pcie 1a143000.pcie:      MEM 0x0020000000..0x0027ffffff -> 0x0020000000
[    7.910982] mtk-pcie 1a143000.pcie: genpd_runtime_resume()
[    7.923508] mtk-pcie 1a143000.pcie: resume latency exceeded, 1440 ns
[    7.969643] FIT:          flat_dt sub-image 0x00521000..0x0052111a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-pcie1)
[    8.033715] mtk-pcie 1a143000.pcie: Port0 link down
[    8.041634] mtk-pcie 1a143000.pcie: genpd_runtime_suspend()
[    8.051435] mtk-pcie 1a143000.pcie: suspend latency exceeded, 1200 ns

In the DTS file, GPIO 90 is set (as required) to enable the PCIe slot: #include <dt-bindings/gpio/gpio.h>

/dts-v1/;
/plugin/;

/ {                                                                                                                                                          
compatible = "bananapi,bpi-r64", "mediatek,mt7622";                                                                                          
        fragment@0 {
                target = <&asmsel>;                                                                                                                                  
                     __overlay__ {                                                                                                                                                
                               gpios = <90 GPIO_ACTIVE_HIGH>;                                                                                                               
                      };                                                                                                                                           
         };                                                                                                                                           
 };

and the non-overlay declaration is done here:

  &pcie0 {
          pinctrl-names = "default";                                                                                                                           
  pinctrl-0 = <&pcie0_pins>;                                                                                                                           
  status = "okay";                                                                                                                             
  };
  &pio {
            /* Attention: GPIO 90 is used to switch between PCIe@1,0 and
           * SATA functions. i.e. output-high: PCIe, output-low: SATA
           */
          asmsel: asm_sel {
                  gpio-hog;                                                                                                                                            
                gpios = <90 GPIO_ACTIVE_HIGH>;
                output-high;                                                                                                                                 
        };
 }

So why is the link still down? what’s going wrong?

EDIT: FYI: I removed the sata overlay dts in openwrt, it is added to the FDT by default, but I removed that overlay, as I do not intend to use the sata controller at all

Hi,

The key-property is output-high (pcie) vs. output-low (sata),so the overlay is useless as it sets the gpio to same value as in base dts.

But in base dts the output-high is set,so pcie should work. I guess ax card needs more power and this is the cause that card does not came up.can you try the ac card (recognized in the other slot) in the slot shared with sata (cn8)?

And please add BPI-R64 at beginning of your Topic because in the category there are 3 different boards now

Interesting … do we have any limits concerning power requirements in this slot?

This card requires 8.5W max operating power consumption :s When I look at electrical specs (2A at 12V), this is probably the reason: the wifi card itself takes all of it from the 3.3V line, being 2.7A, and as such it would actually take almost 50% of the max power on the 3.3V (5.5A) line. Taking into account we’re also putting a 2nd card on it, I am probably out of luck

I was as brave as I could be (‘let’s just take it into production, we’ll see about this software issue later on’), but I guess you’re right. I’ll have to wait for more energy-efficient AX chips then :frowning:

Mostly ax cards need a higher current at 3v3 at startup (peak) and this is limited afaik on both slots by resistors (and maybe the power converter on board too). So the ax card will not work in both slots. But for testing the slot you can try the card known as working in the cn8 slot

But i cannot tell you exact numbers,but i have seen some threads about

I replaced the 2 cards with a Mediatek AW7915-NPD (for AX) and QCA8888 module (for AC), those seemed pretty power-efficient. Unfortunately, the story doesn’t end here: lspci is empty :frowning: both ports are down

Any clues what may be wrong here?

[    1.135852] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
[    1.142415] mtk-pcie 1a143000.pcie: Parsing ranges property...
[    1.148249] mtk-pcie 1a143000.pcie:      MEM 0x0020000000..0x0027ffffff -> 0x0020000000
[    1.256585] mtk-pcie 1a143000.pcie: Port0 link down
[    1.263449] mtk-pcie 1a143000.pcie: PCI host bridge to bus 0000:00
[    1.274568] FIT:          flat_dt sub-image 0x0055a000..0x0055a11a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-pcie1)
[    1.280725] pci_bus 0000:00: root bus resource [bus 00-ff]
[    1.302791] pci_bus 0000:00: root bus resource [mem 0x20000000-0x27ffffff]
[    1.320340] pci_bus 0000:00: scanning bus
[    1.332879] pci_bus 0000:00: fixups for bus
[    1.342781] pci_bus 0000:00: bus scan returning with max=00
[    1.349178] mtk-pcie 1a145000.pcie: host bridge /pcie@1a145000 ranges:
[    1.355727] mtk-pcie 1a145000.pcie: Parsing ranges property...
[    1.361577] mtk-pcie 1a145000.pcie:      MEM 0x0028000000..0x002fffffff -> 0x0028000000
[    1.469908] mtk-pcie 1a145000.pcie: Port1 link down
[    1.474925] mtk-pcie 1a145000.pcie: PCI host bridge to bus 0001:00
[    1.481117] pci_bus 0001:00: root bus resource [bus 00-ff]
[    1.486595] pci_bus 0001:00: root bus resource [mem 0x28000000-0x2fffffff]
[    1.493466] pci_bus 0001:00: scanning bus
[    1.498699] pci_bus 0001:00: fixups for bus
[    1.502882] pci_bus 0001:00: bus scan returning with max=00

Any ideas?

Ok, apparently it was not as bad as above: when applying the default kernel config (minus sata overlay), lspci shows something …

00:00.0 PCI bridge: MEDIATEK Corp. Device 3258
01:00.0 Network controller: Qualcomm Atheros Device 0056

and dmesg says:

[    1.138596] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
[    1.145131] mtk-pcie 1a143000.pcie: Parsing ranges property...
[    1.151019] mtk-pcie 1a143000.pcie:      MEM 0x0020000000..0x0027ffffff -> 0x0020000000
[    1.185630] mtk-pcie 1a143000.pcie: PCI host bridge to bus 0000:00
[    1.191842] pci_bus 0000:00: root bus resource [bus 00-ff]
[    1.197333] pci_bus 0000:00: root bus resource [mem 0x20000000-0x27ffffff]
[    1.204454] pci_bus 0000:00: scanning bus
[    1.208743] pci 0000:00:00.0: [14c3:3258] type 01 class 0x060400
[    1.214791] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x1ffffffff 64bit pref]
[    1.224199] pci_bus 0000:00: fixups for bus
[    1.228641] pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 0
[    1.235594] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    1.243870] pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
[    1.250997] pci_bus 0000:01: scanning bus
[    1.255485] pci 0000:01:00.0: [168c:0056] type 00 class 0x028000
[    1.261934] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit]
[    1.270371] pci 0000:01:00.0: PME# supported from D0 D3hot
[    1.275902] pci 0000:01:00.0: PME# disabled
[    1.282178] pci_bus 0000:01: fixups for bus
[    1.286413] pci_bus 0000:01: bus scan returning with max=01
[    1.292017] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[    1.299188] pci_bus 0000:00: bus scan returning with max=01
[    1.305224] pci 0000:00:00.0: BAR 0: no space for [mem size 0x200000000 64bit pref]
[    1.319623] pci 0000:00:00.0: BAR 0: failed to assign [mem size 0x200000000 64bit pref]
[    1.328104] pci 0000:00:00.0: BAR 8: assigned [mem 0x20000000-0x201fffff]
[    1.335366] pci 0000:01:00.0: BAR 0: assigned [mem 0x20000000-0x201fffff 64bit]
[    1.348679] pci 0000:00:00.0: PCI bridge to [bus 01]
[    1.358112] pci 0000:00:00.0:   bridge window [mem 0x20000000-0x201fffff]
[    1.370924] pcieport 0000:00:00.0: of_irq_parse_pci: failed with rc=-22
[    1.383330] pcieport 0000:00:00.0: assign IRQ: got 0
[    1.388791] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
[    1.402215] pcieport 0000:00:00.0: enabling bus mastering
[    1.408657] mtk-pcie 1a145000.pcie: host bridge /pcie@1a145000 ranges:
[    1.415196] mtk-pcie 1a145000.pcie: Parsing ranges property...
[    1.421046] mtk-pcie 1a145000.pcie:      MEM 0x0028000000..0x002fffffff -> 0x0028000000
[    1.460650] FIT:          flat_dt sub-image 0x0055a000..0x0055a11a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-pcie1)
[    1.529262] mtk-pcie 1a145000.pcie: Port1 link down
[    1.534300] mtk-pcie 1a145000.pcie: PCI host bridge to bus 0001:00
[    1.540498] pci_bus 0001:00: root bus resource [bus 00-ff]
[    1.545977] pci_bus 0001:00: root bus resource [mem 0x28000000-0x2fffffff]
[    1.552866] pci_bus 0001:00: scanning bus
[    1.558116] pci_bus 0001:00: fixups for bus
[    1.562295] pci_bus 0001:00: bus scan returning with max=00
[    2.323789] FIT:          flat_dt sub-image 0x0051c000..0x0051c11a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-pcie1)

So we got PCIe slot 0 working … but PCIe slot 1 doesn’t any longer. Any possibility to get that one up and running as well?

which kernel-version do you use? make sure the pcie-splitting-patch is applied

looks like ( pcie@1a143000, pcie@1a145000), but have no other idea yet :stuck_out_tongue:

maybe @dangowrt have an idea

but this looks strange:

of_irq_parse_pci: failed with rc=-22

maybe you can add some debug-code for this

Debug code (with driver code verbose debug compiled in):

maybe the suspend / resume latency causes the issue?

and some info about current status (sysfs parameters):

find /sys/devices/platform/1a14* -type f -maxdepth 4 | while read r; do echo " $r:" >> /tmp/pastebin.txt; cat “$r” >> /tmp/pastebin.txt; done

7915 in slot 1? This card needs higher peak at bootup and so this maybe is the cause.

Please test with 2 non-ax cards

yes indeed … to bad, I bought this ax card for nothing then :frowning: when I install a ax210 (which currently has no AP functionality), it is listed.

there is maybe a way by dropping 2 resistors, but i have not tried it…then the current is only limited by the voltage regulator

[BPI-R64] Possible hardware improvements (step 2)

Any option if you don’t want to solder the board?

Afaik only using another board or maybe a newer hw rev of r64 if there is any where this is fixed. But i cannot answer this.

Just to be sure:

If I understand correctly, there’s some kind of power regulator deciding the required power of the MT7915 is too high, right? What would the maximum power be then? The 7915 has a dual-band radio, maybe a single band radio (like the AX210) could work

See the thread i linked…

The regulator (SY6280A) has a 2A limit on 3v3. This current is limited on board to 1.44A.

3K for a 3.3V/2.26A current limit (above the recommended 2A maximum limit) versus the old 4K7 for a 3.3V/1.44A current limit

I was told that card needs peak of 3A on 3v3

My mt7915 card works on r2, and afaik there is no 3A on 3v3 too,but maybe a bit more as on r64

And you cannot bootup with only half card enabled to reduce poweron peak