[BPI-R2] Kernel Development

Banana Pi BPI-R4/BPI-R3 Mini/BPI-R3/BPI-R64/BPI-R2
314

I started work on 5.9

This commit breaks bootup of r2 and r64 f97dbf48ca43009e8b8bcdf07f47fc9f06149b36 irqchip/mtk-sysirq: Convert to a platform driver

I got this fix that works https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-next&id=7828a3ef8646fb2e69ed45616c8453a037ca7867 but leaves some errors in bootlog…it looks like the full irq-series gets reverted in one of the next rc’s

Updated 5.9-rc branch. Hdmi and wifi are working so far (5.9-hdmi, 5.9-wifi)

315

Got new traceback on 5.8-main: dmesg.txt (7.0 КБ)

It appears on large file copying using mc (tens on GB), swap presence and amount doesn’t has any effect.

Looks like it doesn’t affects the OS.

Average free mem:

top - 23:16:34 up 1 day,  2:13,  4 users,  load average: 1,26, 0,92, 1,39
Tasks: 152 total,   1 running, 151 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,5 us, 18,3 sy,  0,0 ni, 61,2 id, 18,7 wa,  0,0 hi,  1,3 si,  0,0 st
MiB Mem :   2008,0 total,      6,7 free,    110,4 used,   1890,9 buff/cache
MiB Swap:      0,0 total,      0,0 free,      0,0 used.   1834,7 avail Mem

P.S. I do not remember such messages on earlier kernels, but i can’t exclude that.

P.S.S. Looks like some general kernel issue, not R2 specific,

316

Looks like bug in mt76 driver

mt76x02_update_beacon_iter [mt76x02_lib]

You can try opening issue on github.com/openwrt/mt76 but write that you’re using mainline 5.9-rc1…i don’t know if they snc mt76 on every mergewindow

Mhm…you copy locally? Should not be affected by mc file copy…i guess it is caused by any limitation (cpu/ram) if related to copy

Btw for git i have created swap file to extend ram…else i got oom reaper messages. Tried different git configs (windowsize,threads,…) but only swapfile works

318

Dts-patches (hdmi and pause fix) are now merged to linux-next.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts

mtk drm patches afaik need to be merged to drm-next first => done, waiting to be visible in linux-next

as the tdms patch is based on hdmi-phy-move file drivers/phy/mediatek/phy-mtk-hdmi.c does not exit yet, so we can use mtk_dpi.c to show changes done by commit “Change the getting possible_crtc way”

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/gpu/drm/mediatek/mtk_dpi.c

Edit: linux-next from 2020-09-29 contains the mtk-drm patches

2 Likes
319

hi, i booted 5.10 the first time after adding the basic patches (adding build.sh,defconfigs,…) and noticed at leats a warning

[    6.151110] ahci 0000:02:00.0: version 3.0                                   
[    6.151136] ahci 0000:02:00.0: enabling device (0140 -> 0143)                
[    6.157056] ------------[ cut here ]------------                             
[    6.161730] WARNING: CPU: 2 PID: 73 at include/linux/msi.h:213 pci_msi_setup_
msi_irqs.constprop.0+0x78/0x80                                                  
....
[    6.724607] WARNING: CPU: 2 PID: 73 at include/linux/msi.h:219 free_msi_irqs+

https://elixir.bootlin.com/linux/v5.10-rc1/source/include/linux/msi.h#L219

which comes from commit 077ee78e392869e46ae6bdc6ba2a3c4249d0b5e1 (PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable)

dmesg_5.10.log (47,6 KB)

I send patch for fixing it…patchwork => Patch only suppress warning, but does not fix the root cause…see comment from Thomas Gleixner…have not found the root-cause yet ;( i guess ahci/mtk_pcie-driver or missing option in dts It looks like pcie driver does not setup a msi-domain for mt7623/mt2701, reverted my patch and booted on bpi-r64, and got no warning…this confirms my assumption, that this warning is caused only on mt2701/mt7623 where no msi-domain is setup.

Patch from Marc Zyngier seems to work, at least i get no warning

1 Like
320

after getting hnat working on last lts (5.10) i got also second gmac working with the help of deng qingfang and Marek Behún. Switching CPU-Port of ports needs modified ip-tool (iproute2)

root@bpi-r2:~# ip link show wan                                                                                                                
5: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000                            
    link/ether 08:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff                                                                                         
root@bpi-r2:~# ip link set wan link eth1                                                                                                       
root@bpi-r2:~# ip link show wan                                                                                                                
5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000                            
    link/ether 08:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff                                                                                         
root@bpi-r2:~#

references:

modified iproute2-tool can be found here:

second gmac is working on both devices (r2+r64) on quick-test, now also with default-cpu via dts, changing gmac via IP works

have uploaded compiled iproute2 binaries here: https://drive.google.com/drive/folders/1Zkxs_gglxxWCvVyY3HwPNNUmhR3DqW_h?usp=sharing

i have uploaded compiled kernel 5.10 with hnat+gmac patches here:

https://drive.google.com/drive/folders/17MoFc3vIuGHDEV5SsCmGegJDr009IXls?usp=sharing

compiled nftables can be found here: https://drive.google.com/drive/folders/1hajKvqQa96WRrAy52fQX90i59I1s0h-i?usp=sharing

second gmac seems to not work stable…i see massive retransmitts when doing iperf3.asked network-specialists from mtk if they can help

321

Does R64openwrt source(https://wiki.banana-pi.org/Banana_Pi_BPI-R64) support HW NAT? I can only find it in R2, how to add this module, throughput test is not high

322

You should use newer source,not the old vendor openwrt. Afaik hw-nat ia mainline till 5.12. My 5.10-hnat branch has support but it is no openwrt,but you can use the commits to add patches to openwrt…maybe mainline openwrt has already backported it to 5.10

Btw.this thread is about r2,not r64

323

Hi Does somebody try to use 2-nd gmac to wan directly? Gmac1 -> port 5 -> PHY port 4. I think this mode is better for routers.

324

I made tests with vlan aware bridge (bridging aux/p5 and gmac) some time ago for r2 and r64.

See second ethernet lane here

https://wiki.fw-web.de/doku.php?id=en:bpi-r2:network:start#permanent

325

I made it through dts for kernel 5.10.

    &eth {
    status = "okay";

    gmac0: mac@0 {
            compatible = "mediatek,eth-mac";
            mac-address = [fe dc ba 98 76 54];
            reg = <0>;
            phy-mode = "trgmii";

            fixed-link {
                    speed = <1000>;
                    full-duplex;
                    pause;
            };
    };

    gmac1: mac@1 {
            compatible = "mediatek,eth-mac";
            mac-address = [01 23 45 67 89 ab];
            reg = <1>;
            phy-mode = "rgmii";
            phy-handle = <&phy0>;

    };

    mdio: mdio-bus {
            #address-cells = <1>;
            #size-cells = <0>;

            /* Internal phy */
            phy0: eth-phy@0 {
                    reg = <0>;
            };

            mt7530: switch@1 {
                    compatible = "mediatek,mt7530";
                    reg = <1>;
                    /* reset-gpios = <&pio 33 0>; */
                    core-supply = <&mt6323_vpa_reg>;
                    io-supply = <&mt6323_vemc3v3_reg>;
                    mediatek,mcm;

                    resets = <&ethsys MT2701_ETHSYS_MCM_RST> ; /* 2>; */
                    reset-names = "mcm";

                    ports {
                            #address-cells = <1>;
                            #size-cells = <0>;
/*
                            port@0 {
                                    reg = <0>;
                                    label = "wan";
                            };
*/
                            port@1 {
                                    reg = <1>;
                                    label = "lan0";
                            };

                            port@2 {
                                    reg = <2>;
                                    label = "lan1";
                            };

                            port@3 {
                                    reg = <3>;
                                    label = "lan2";
                            };

                            port@4 {
                                    reg = <4>;
                                    label = "lan3";
                            };

                            cpu_port0: port@6 {
                                    reg = <6>;
                                    label = "cpu";
                                    ethernet = <&gmac0>;
                                    phy-mode = "trgmii";

                                    fixed-link {
                                            speed = <1000>;
                                            full-duplex;
                                            pause;
                                    };
                            };
                    };
            };
    };
};

It’s working for port0 as wan.

1 Like
326

Ok, did not know it is possible this way…does it work with full speed?

327

I don’t test speed yet. But I’m looking for an opportunity test it by available resources.

328

this seems not working on r64

+++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
@@ -136,6 +136,7 @@ gmac1: mac@1 {
                compatible = "mediatek,eth-mac";
                reg = <1>;
                phy-mode = "rgmii";
+               phy-handle = <&phy0>;
 
                fixed-link {
                        speed = <1000>;
@@ -148,6 +149,11 @@ mdio: mdio-bus {
                #address-cells = <1>;
                #size-cells = <0>;
 
+               /* Internal phy */
+               phy0: eth-phy@0 {
+                       reg = <0>;
+               };
+
                switch@0 {
                        compatible = "mediatek,mt7531";
                        reg = <0>;
@@ -157,10 +163,10 @@ ports {
                                #address-cells = <1>;
                                #size-cells = <0>;
 
-                               port@0 {
+                               /*port@0 {
                                        reg = <0>;
                                        label = "wan";
-                               };
+                               };*/

results in probe error of mtk_soc_eth driver

mtk_soc_eth: probe of 1b100000.ethernet failed with error -16

but i see you have address 1 for switch on mdio bus, how did you get this address (imho this have not to be 1 and 0 is broadcast)?

329

I tried to modify configuration from example 2 of https://github.com/frank-w/BPI-R2-4.14/blob/5.10-main/Documentation/devicetree/bindings/net/dsa/mt7530.txt . And with phy0: eth-phy@0 { reg = <4>; and mt7530: switch@0 { reg = <0>; all worked, using port 4 as eth1. Changing phy reg = <0> disabled mt7530 init. I thought it was reg conflict (phy makes switch0) and tried to change reg of switch to 1. Also, mt7530 require mediatek,mcm flag and mcm reset for external phy. I don’t know to mt7531 needs it.

330
  • the original r64 dts works (wan with reg=0 over eth0)
  • why changing reg to 4 for internal phy as 4 is another port (lan3)

i don’t think it is related to mcm, problem is more that internal phy maps to phy-id 0 (broadcast) and switch too…imho mt7531 on r64 does not have real phy-id…tried to read out via mii-tool but got warning with stacktrace

WARNING: CPU: 0 PID: 1961 at drivers/net/phy/swphy.c:127 swphy_read_reg
331

I don’t know how it works on r2 because I don’t understand what reg means on mdio bus. As i mind mdio is setup interface for switch only. And those settings will not work on mt6531. This switch have considerably different init procedure in /drivers/net/dsa/mt7530.c

332

mdio is bus system comparable to i2c where multiple devices can be attached with different adresses (phy-ids).

the top reg (below switch compatible) is normally the phy-id on mdio-but, where 0 is broadcast. in my example above 2 nodes have broadcast-adress so it is invalid (which device is meant when get a response to broadcast). Ports having their own reg-property which are handled by switch driver.

yes init is different, but the reg-property handling (top by mdio-probe, ports by switch-driver/dsa-core) should be same/similar

333

Now I absolutely do not understand why it works …

334

And I don’t have a mt7530 manual