[BPI-R2] Newer Kernel Capabilities?

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

This might be a question mostly for frank-w, but I am curious to know any update on more recent kernels regarding some of the open issues identified for 4.14 and 4.19 branches of the kernel. Right now, it seems that the 4.14 kernel is the furthest along, but I’m wondering if there any plans to stabilize any future kernel branch, or just want to know what might be merged into the -main kernel branches beyond 4.19. Is the decision to stabilize just based on volunteer time, or driven by an upstream source?

Also curious if anyone knows what works or doesn’t work in the Armbian kernel. They are using a 4.19 kernel for bionic, and I suspect that it is based on frank-w’s work based on a comment in their build scripts. Perhaps they’ve merged some extra stuff in?

2

feature-branches on non-lts are currently only for porting additional features you can merge it by youself.

Maybe poweroff is mainline with 5.4 (if the current missing parts got applied by maintainers)

regarding instabilities i/we need a way to reproduce it and so can test and fix. I hope that phylink works around the tx-timeout-issue because init of switch (mt7530) is completely rewritten, as it was known to be wrong.

Mainline-instabilities are maintained,but what they don’t know/can’t reproduce can’t be fixed

3

But what branches are lts ?

4

I think the answer to this is that the LTS kernels are decided by upstream mainline Linux devs. Sometimes distributions themselves also decide to stabilize a kernel release and maintain themselves. It looks like LTS kernels in mainline are 4.14, 4.19, and 5.4 (upcoming). (Source: https://www.kernel.org/category/releases.html)

I guess it is up to the BPI-R2 community to decide which kernels to maintain, but it is probably much easier for the community to choose an LTS kernel.

Which branch contains the fixes needed to achieve VLAN support? Is that support in any of the more recent mainline kernels? I could test something, although I might need guidance on how to pull good information from these tests.

5

Which fixes do you mean? I have 4.14 running and vlan works…

6

I should have been more clear. I mean to ask–is there a point at which VLAN starts working (has been fixed in mainline) in the 5.0, 5.1, 5.2, etc branches, or is this still only working in 4.14?

7

Imho vlan works out-of-the-box since 4.14…but havn’t tested in newer versions

8

Maybe I should create a new thread for this, but what tests have you performed with VLAN? I could probably run similar tests on the new kernels.

I’d also like your advice and propose another test, perhaps. I’m trying to add a vlan to ports WAN and LAN3 in order to place the devices in a chain and bridge across this VLAN only. I’m having trouble getting this to work properly. The only way I can get it to work is to bridge wan/lan3 in addition to wan.xx/lan3.xx. This is undesirable because I don’t want untagged broadcast traffic. I’m trying to figure out if this is a problem with the VLAN patch or a configuration error, and I don’t have other hardware to test.

I’ve enabled netplan, and am using the following config:

network:
  version: 2
  renderer: networkd
  ethernets:
    # eth0 and eth1 need to be brought up in order for the other interfaces to come up.
    eth0: { dhcp4: no }
    eth1: { dhcp4: no }
    wan:  
      dhcp4: no
      addresses: [ 192.168.2.101/24 ]
      gateway4: 192.168.2.1
    lan3: { dhcp4: no }
  vlans:
    wan.100:
      id: 100
      link: wan
    lan3.100:
      id: 100
      link: lan3
  bridges:
    br2:
      addresses: [ 10.11.0.101/24 ]
      interfaces:
        - wan.100
        - lan3.100

Again, the above doesn’t work unless I add a bridge between wan/lan3, which I am trying to avoid.

9

I don’t use netplan and don’t know its config.

I have created 2 vlan on wan and running pppoe over it because my provider needs this setup

#bambit-inet
auto wan.140
iface wan.140 inet manual
 
auto bambit-internet
iface bambit-internet inet ppp
  pre-up /bin/ip link set wan.140 address 02:11:02:03:04:05 up # line maintained by pppoeconf
  pre-up ip link set $IFACE up
  provider bambit-internet
  post-down ip link set $IFACE down
 
#bambit-voip
auto wan.110
iface wan.110 inet manual
 
auto bambit-voip
iface bambit-voip inet ppp
  pre-up /bin/ip link set wan.110 address 02:12:02:03:04:06 up # line maintained by pppoeconf
  pre-up ip link set $IFACE up
  provider bambit-voip
  post-down ip link set $IFACE down
10

Had you tried to replicate the setup using barebone tools like iproute2 and/or brctl? Am I correct that you report/suspect that bridging VLAN interfaces belonging to different DSO ports does not work? I might be able to replicate/test this config with my testing board on this weekend. Will report back my findings if any.