Ah right that was what I was wondering. Thanks for the link.Do you want a photo of the 1.1 board?
Thx,but i get a v1.2 soon which has not much difference to 1.1 and i take a photo from that. Need to verify bootswitches in hardware…made table from table printed on v1.1 board/shematic
Ah nice.
Is there any hardware difference for 1.2
I’ve asked them on Ali express for the heatsink and /or fan in the photos but not been able to get hold of it yet.I did get the case though but noticed the lights to the front left are not visible (no cut out) so it’s not the best.
In the meantime I’ve ordered a selection of heatsinks to go on top of the chips.
Does anyone have a 1.2 board working reliably and properly tested as a router ?
I did the process described above and I’m booted to snapshot which is great!
I booted to emmc LHXL
I still see tmpfs on /tmp as the highest size mount point. is that correct? 997MB
yes I am just in the construction and should even come today or tomorrow as a main use
I have an v1.1 here. At first glance OpenWRT Snapshot r21301 works. However, PPPoE over eth1 (SFP1) over ISP VLAN does not work. Tcpdump does seem traffic is flowing, but I get:
Fri Nov 18 17:44:11 2022 daemon.info pppd[7741]: Plugin pppoe.so loaded.
Fri Nov 18 17:44:11 2022 daemon.info pppd[7741]: PPPoE plugin from pppd 2.4.9
Fri Nov 18 17:44:12 2022 daemon.notice pppd[7741]: pppd 2.4.9 started by root, uid 0
Fri Nov 18 17:44:27 2022 daemon.warn pppd[7741]: Timeout waiting for PADO packets
Fri Nov 18 17:44:27 2022 daemon.err pppd[7741]: Unable to complete PPPoE Discovery
Fri Nov 18 17:44:27 2022 daemon.info pppd[7741]: Exit.
I noticed a newer version of pppd bumped to 2.4.9. My ER-X-SFP uses 2.4.8 and works w/o issues using a stable build.
Another thing I find a bit annoying is labelling RJ45 wan port as ‘wan’ internally, whereas SFP1 is eth1 but SFP2 is labelled sfp2 internally. Why not just label it eth2 or something equivalent. Same for lan ports, just call them eth1/2/3/4.
This is caused by type of interfaces. Where wan,lan0-lan3 and lan4/sfp2 are dsa user ports which can have a label eth1 is a mac from soc which cannot have a label without additional patch (which was rejected in mainline some time ago). You can rename interfaces in udev or change dsa interfaces in dts.
This was the patch sent some time ago
See this discussion:
https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/
edit: i can confirm, that vlan does not work on eth1 (wan-sfp). it works on wan-port (switch), but not on the gmac…maybe because of sgmii-mode? @dangowrt have you an idea where to look?
steps to reproduce (of course needs to be done on the other side and maybe switch-ports need trunk-mode+allowing the vlans)
ip link set eth1 up
ip link add link eth1 name vlan500 type vlan id 500
ip addr add 192.168.50.1/24 dev vlan500
ip link set vlan500 up
ip link add link wan name vlan600 type vlan id 600
ip link set wan up
ip link set vlan600 up
ip addr add 192.168.60.1/24 dev vlan600
ping 192.168.60.2 #works
ping 192.168.50.2 #does not work
seems like arp-packets do not pass in receving direction, as i see arp request reaching my other end and reply was sent
r3:
12:38:38.340313 ARP, Request who-has 192.168.50.2 tell 192.168.50.1, length 28
laptop:
12:38:38.752589 ARP, Request who-has frank-G5 tell 192.168.50.1, length 42
12:38:38.752609 ARP, Reply frank-G5 is-at e4:b9:7a:f7:c4:8b (oui Unknown), length 28
tried to find something, the only vlan-rx-related code i’ve found is in mtk_rx_poll
https://elixir.bootlin.com/linux/v6.1-rc5/source/drivers/net/ethernet/mediatek/mtk_eth_soc.c#L1933
debugged so far as it looks like MTK_NETSYS_V2 is detected, but (trxd.rxd3 & RX_DMA_VTAG_V2)==0 and so below code is not applied
[ 277.661357] mtk_soc_eth 15100000.ethernet: DEBUG: Passed mtk_poll_rx 1933 feat:0x2010000114993 vlan_ctag:0x100
[ 277.671377] mtk_soc_eth 15100000.ethernet: DEBUG: Passed mtk_poll_rx 1935
[ 277.678154] mtk_soc_eth 15100000.ethernet: DEBUG: Passed mtk_poll_rx 1937 (MTK_NETSYS_V2) 0x0
have not found out where this flag should be set…
1 Like
Can there be a relationship?
ARP-requests not being answered on MediaTek-chipsets · Issue #11218 · openwrt/openwrt · GitHub
It looks for me there is basicly no vlan-support on gmac directly (maybe it needs to be enabled on probe). Maybe it is always stripped because normaly there is a dsa-tag on top…have sent question to mtk,but no response yet.
1 Like
RX to TX …this caught me out 
many thanks
VLAN offloading was broken in mtk_eth_soc driver, Felix now fixed it in OpenWrt (hopefully), try importing the new patches from there: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9b482ee22f3f509880d2420652392971eef3211d
2 Likes
I guess it is this patch i need to port
@dangowrt do you know if felix sent these to netdev mailinglist (possibly net cause these are fixes). Have you tried vlan on lan-sfp? Maybe it’s broken on dsa driver too?
Yes, I assume that Felix will send these upstream once tested a bit by the OpenWrt crowd.
Right,but he has already a patch for 6.1/6.2 (next) i do not need to spend time in porting (+ figuring out depencies) and can test earlier 
edit: tried next with this series:
https://patchwork.kernel.org/project/linux-mediatek/list/?series=698421
and here vlan works on wan and sfp-wan, so this seems to be fixed for 6.2 (which will be no lts) if the sersies goes into it, would be nice to have it fixed in 6.1 too
1 Like
Can confirm that VLAN tagging works on OpenWRT snapshot r21373-aa12a0fdd1 on eth1 (wan-sfp). Haven’t tested sfp2 (lan-sfp) interface yet.
Next issue, IPTV using igmpproxy bridge interface on different vlan tied to same eth1 (wan-sfp interface)) is stuttering. Not sure what causes that now…
I’m also observing random RX problems when using 1Gbit/s SFP module with some link partners. Sometimes speed drops down to kilobits and then never recovers. With other link partners (e.g. Intel NIC) connected via the same SFP it just never happens. With others (e.g. RealTek-based switch) is always happens right away. Which SFP module are you using? Which link mode does it use (SGMII, 1000Base-X or 2500Base-X?)
I thought I was experiencing maybe a config issue. Also noticed random drops in speeds to like max 5 Mbps, but happened after applying configs. Reboot or restarting network stack helped. Wasn’t sure whether it was me applying config changes or some intermittent other issue.
I am using an UBNT UF-SM-1G-S for my 1Gbps FttH. On Ubiquiti ER-X-SFP it is required to fix full duplex and speed and explicitly turn off autoneg: ethtool -s eth5 speed 1000 autoneg off duplex full
On bpi r3 it seems to detect link properly w/o need to configure interface:
Settings for eth1:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: FIBRE
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
An idea of internet speeds now atm using current config:
maybe it is the phylink-patch adding only the mtk_pcs_get_state which misses autoneg/duplex/pause setting… rob posted series applied to upcoming 6.2 which handles also these settings.
you can try to test on linux-next or merge the series to openwrt (i guess it needs some backports).