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>
&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
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
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 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
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
