The Zaram module is also having huge problems with the BPI R4.
I’m curious, does the zaram even start? If not, maybe you can try this solution from @glassdoor Maybe he can share a compiled image, which you could test?
I’d like to use the zaram for Delta or KPN in a few months (when I move to a new house). For now I’m using a cheap SFP (on my BPI-R4) for a Caiway connection. Works flawless.
I had to do some soldering but it shows now in dmesg. but now i have errors
something with the EEPROM. i,m busy trying to find out how to read and interpretate the data coming from the I2C bus but its really frustrating. 
I want to use the Zaram for KPN., i have a 4 Gbit connection I used another sfp+ to RJ45 module with ethernet and that worked flawless.
But this Zaram in combination with the BPI R4 is for me (noob old and windows man) is undescribable frustrating.
Hmm, I hope this is all fixed before I need the Zaram ONU 
Is it some generic message you see? Does it look like some of the errors reported here?
The message is
root@OpenWrt:/# dmesg |grep sfp
[ 11.507870] sfp sfp1: Host maximum power 3.0W
[ 11.512852] sfp sfp2: Host maximum power 3.0W
[ 11.823979] sfp sfp1: module Zaram ZXOS11NPI rev 1B sn ZRMT23120070 dc 230327
[ 11.841838] sfp sfp1: Module switched to 1.5W power level
[ 11.858659] sfp sfp2: module Uptimed UP-TR-10G-RJ45-C rev 1 sn UPC21TX260039 dc 210630
[ 13.742545] sfp sfp1: module transmit fault indicated
[ 19.182521] sfp sfp1: module persistently indicates fault, disabling
Someone solved this with the same error code but with a different transceiver.
from the logs. the issue is completely different to S800E where it does not get powered up and i2c cannot read the eeprom
the Zaram is powered and detected. 90% of problem solved. all you need is to add a quirk sfp_fixup_ignore_tx_fault to sfp.c and rebuild.
or spoof the module name and id in the boot environment and just follow this solution as suggested to you in another thread. https://forum.banana-pi.org/t/bpi-r4-sfp-gpon-onu-34-20bi-openwrt-tx-fault/21810/12?u=glassdoor
I,m glad 90% of my problem is solved… but for me the devil is in the details.
i have no idea how where and what i would have to do to that sfp.c
Rebuilding i can. but that is as far as my knowledge goes
Is there anywhere some documentation how and where i can add a quirk to the sfp.c ?
I have looked into it and i see nowhere something that resembles my Zaram stick.
If you can rebuild, try inserting this in your sfp.c
// Zaram ZXOS11NPI is a XGS-PON module with broken TX_FAULT indicator
SFP_QUIRK_F("Zaram", "ZXOS11NPI", sfp_fixup_ignore_tx_fault),
I,m going to try that and let you know if that worked.
Thank you so much.
When i build a firmware myself the module is not recognized.
The firmware that recognized the Zaram is the 24.10.0 Release Candidate 5
And now it works…
no error messages anymore… you guys are the best… :))
Great 
! Can you report here if the zaram/bpi-r4 combination works without problems (full speed, low cpu usage etc). Curious!
I will report tomorrow… At this moment it is working without any problems but i have to register the module with KPN tomorrow first to see if it actually connects to the internet.
I,m pretty confidant that it does but i had to compile my own kernel in the process.
i get different network device labels (sfp-wan and sfp-lan) where i was used to having wan lan eth0 eth1 eth2 lan1 lan2 lan3 etc.
hopefully i only have to change the names in the /etc/config/network
But i,m not sure yet simply because i never did this before
Besides that i,m sure it will all work out
i will report speeds and cpu usage… but i,m confidant that it will be pretty much the same as with Sfp+ to Rj45 modules… very low load and cpu usage.
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.