And check. Zaram works on the 4 Gbit KPN line.
Speeds are 4 up and almost 4 down. Cpu load is around 10% at full speed.
temps are around 45 degrees Celcius
I,m happy with it 
There was a renaming in the openwrt device tree, now that the kernel made it possible for openwrt to have those custom names as part of the device tree.
Eth0-X are the default names given by the kernel.
But on the PCB and the case they are called LAN and WAN and since they are sfp modules they decided to call them sfp-lan and sfp-wan, which totally makes sense to me.
it makes sense to me now too
not saying that its a good thing to do without anyone knowing before one is confronted with it.
Thanks for the confirmation! This means that I can savely buy the Zaram 
Yes you can!!
i can,t wait till others will support this router so we can use different router firmwares on it
[My previous deleted reply was due to my adapter malfunctioning, sorry.]
In my case, it’s a Zyxel PMG3000-D20B (a 1000base-x device) that vanishes from 21.04 to 24.10/snapshot.
My R4 already has this soldering mod applied.
It got me from…
ethtool -m sfp-wan
Cannot get Module EEPROM data: No such device
SFP module not in cage?
… to now:
ethtool -m sfp-wan
Cannot get module EEPROM information: Not supported
--- a/package/base-files/files/etc/rc.local
+++ b/package/base-files/files/etc/rc.local
@@ -1,4 +1,7 @@
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
+echo 594 > /sys/class/gpio/export
+echo out > /sys/class/gpio/gpio594/direction
+echo 0 > /sys/class/gpio/gpio594/value
exit 0
diff --git a/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi b/target/linux/mediatek/files-6.6/arch/
index 8dba5b4..fea8ee6 100644
--- a/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
+++ b/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
@@ -36,18 +36,6 @@
reg = <0x00 0x40000000 0x00 0x10000000>;
};
- /* SFP1 cage (WAN) */
- sfp1: sfp1 {
- compatible = "sff,sfp";
- i2c-bus = <&i2c_sfp1>;
- los-gpios = <&pio 54 GPIO_ACTIVE_HIGH>;
- mod-def0-gpios = <&pio 82 GPIO_ACTIVE_LOW>;
- tx-disable-gpios = <&pio 70 GPIO_ACTIVE_HIGH>;
- tx-fault-gpios = <&pio 69 GPIO_ACTIVE_HIGH>;
- rate-select0-gpios = <&pio 21 GPIO_ACTIVE_LOW>;
- maximum-power-milliwatt = <3000>;
- };
-
gpio-keys {
compatible = "gpio-keys";
@@ -86,9 +74,8 @@
};
&gmac2 {
- sfp = <&sfp1>;
managed = "in-band-status";
- phy-mode = "usxgmii";
+ phy-mode = "1000base-x";
status = "okay";
openwrt,netdev-name = "sfp-wan";
};
No idea. sorry.
if i had to guess. if t worked it in kernel 5.4 and fails in kernel 6.6. your problem lies elsewhere
since u already solder mod, the gpio hack is not required. and since u removed the sfp1 dt entries, you expected something from ethtool -m sfp-wan??!!
you need to find the root issue between kernel 5.4 and kernel 6.6.
p.s. modifying dt should be last resort and you need to know what you are trying to achieve.