[banana-pi r2 / dhclient with isp]

you have not to care about DSA, only that it is there and you have to operate on virtual interfaces wan,lan0-3 instead of ethx. vlan have also time (most people don't need it), first get basic network-setup working.

 

so just bring eth0/1 only up and configure the wan/lan-ports

 

btw. it's new to me that there is a DSA-Driver for Bpi-R1, i only have seen swconfig-configurations to access ports separately

[banana-pi r2 / dhclient with isp]

official lede from sinovoip still uses 4.9, but there is imho also a dsa-driver (backported from 4.1x afair),

there is openwrt with 4.14 which includes Patches for bpi-r2 (where i've got my Patches for second gmac).

 

if you have a dsa-driver (you see interfaces wan,lan0-lan3) you cannot work on eth0/eth1 (these are only the ethernet-connections between switch [mt7530] and SOC/Main-CPU [mt7623]), only bring them up...ip-config has to be done on dsa-interfaces.

[BananaPi R2 (.csc mt7623 as new boardfamily)]

i've got second gmac working in 4.19 and with some advice from a DSA-Maintainer, i changed it (back) to mdio_device (johns patch uses platform_device).

 

http://forum.banana-pi.org/t/help-for-testing-4-19-on-r2/7339

[BananaPi R2 (.csc mt7623 as new boardfamily)]

18 hours ago, chwe said:

@frank-w

as far as I understand the purpose for boards which have a SoC link to a DSA is that eth0 should be always up not?

see here for config.. https://github.com/armbian/build/tree/master/packages/bsp/mt7623

i see it right you bridged all dsa-ports (wan+lan) to the same bridge (br0)? how to use it as router if it works as a switch

 

and you enable dhcp on eth0 to bring them up? makes not really sense to me

[BananaPi R2 (.csc mt7623 as new boardfamily)]

The main porting of second gmac was done by john crispin. There was only a small mistake which we fixed (both cpu-ports need to use same mode).

 

I tried to port it to 4.19,but currently i can't get it working (eth1 is visible but dsa-ports got lost) so i stuck here without any help. I've contacted John,but he tells me he is currently busy and has not the time he need to help me.

 

https://github.com/frank-w/BPI-R2-4.14/commits/4.19-gmac

 

Have contacted dave miller as maintainer of network-part,but got no response yet

[BananaPi R2 (.csc mt7623 as new boardfamily)]

I've seen also post from ryder.lee in bananapi.org-forum for uboot-patches and forked uboot-repo on github for testing it.

 

Have you got it booting a kernel from sd/emmc?

[Banana Pi R64]

I had thought that the system is similar to r2 (it is mentioned in r2-forum which is renamed now) and soc have similar number (mt7623 vs. mt7622 1 less).

[BananaPi R2 (.csc mt7623 as new boardfamily)]

Have not tested performance yet, because my freetime is also limited. I also have only a 12mbit adsl internet-connection where this should not be limited by 2nd gmac :)

as i read 4.17 fixes some network-issues....but which/how? @ryder.lee will these ported to 4.14 or can you show me the patches? Currently hang on porting the gmac-patch to 4.18 file dsa2.c which is completely changed with 4.15 (not only new functions). Here i need some help from anybody who knows the new dsa-core. Wifi-driver is already ported (no changes compared to 4.16 where only timers changed).

 

@chwe if you make changes which fixing problems in mainline please send me the patches si can include them in my repo

 

[BananaPi R2 (.csc mt7623 as new boardfamily)]

On 5/27/2018 at 1:05 AM, chwe said:

I got fooled by the dev kernel... booted it once just for fun.. Cause debug UART is on UART2, I expected that in bootargs console=ttyS2, actually this was never true for Franks 4.14 Kernel, as soon as you switch to a 'unpatched mainline' (that's what dev is) the console gets silent as soon as ttyS is initialized.  Rebooted probably to early and messed up something so that the FS was corrupted. I could see that setting bootargs to ttyS2 will work but the Image was too much corrupted to bring it up. So we need to patch either franks kernel to the default behavior or patch mainline to franks behavior (I prefer to patch mainline cause I think most other boards will have debug UART on UART0, similar to the reference board, but dev kernel has no priority for me)

 

Hi,

 

i changed Uart (Uart2=>ttyS0) and MMC (SD=0,emmc=1) from mainline to make my kernels compatible with official images (defined my images same way).

 

i see some definitions...maybe they can be used to define which uart is used for debug-uart without changing the order in dts(i)

aliases {
	serial2 = &uart2;
};

chosen {
	stdout-path = "serial2:115200n8";
};

btw. 2nd gmac, hdmi, poweroff and some other stuff is working now in (my) 4.14...hnat is ported, but i don't know if it is working due to a "strange" test (cpu-interrupts increasing)