Add host compatibility table and information about which firmware can modify SN.

[wteiken]

Factored out the new tables in the readme page. I noticed yesterday that the newer firmwares do no allow modifying the SN with ritool which I think is significant.

[wteiken]

The other thing I noticed: Firmwares that used to work in the past no longer boot. They crash in /etc/init.d/sfp_eeprom.sh when executing:

/opt/lantiq/bin/sfp_i2c -a

Without that command they boot up. Once the command is started the module will immediately reboot, and the reboot cause listed is "Wachdog".

It almost seems like after a certain runtime with a specific firmware they stop accepting any other, either newer or older.

I think this is the command that monitors the eeprom for special values (e.g., like described here https://forum.openwrt.org/t/support-ma5671a-sfp-gpon/48042?page=13).

I have not yet tried if the module will still connect to my ISP without that.

[tdmadam]

@wteiken I wonder if the inability to modify the serial number is related to the advice given to me by hwti when the OperatorID is not 0000 or 9999 https://github.com/hwti/G-010S-A/issues/26

There is no consistency between Lantiq-based modules in terms of how to program and read the serial number. Having used modules from several different manufacturers in the past, I counted at least six different ways in which they store the serial number.

1. sfp_2ic is mainly used for programming physical or soft eeprom, useful for displaying values for status page in the switches.
2. U-Boot environment, plain or BASE64 encoded values.
3. ritool, which stores values in a separate "ri" MTD partition
4. UCI system (uci show/set/commit)
5. Hardcoded values in some configuration file.
6. Directly in the /etc/mibs/data1g_8q.ini or equivalent used by OMCI protocol.

[wteiken]

@wteiken I wonder if the inability to modify the serial number is related to the advice given to me by hwti when the OperatorID is not 0000 or 9999 #26

Ack, thanks that is it.

1. sfp_2ic is mainly used for programming physical or soft eeprom, useful for displaying values for status page in the switches.

It also has the "monitor mode" with "-a", that causes the reboot. And I think that is because writing the eeprom from the host can be used to influence the module operation.

2. U-Boot environment, plain or BASE64 encoded values.

Yeah, that is back to the original values.

3. ritool, which stores values in a separate "ri" MTD partition

Yep, also back to original.

4. UCI system (uci show/set/commit)

I think changes here are not persistent for any newer firmware.

5. Hardcoded values in some configuration file.

Which is unmodified as it's the original 3FE46398BFGB18 firmware image on the module.

6. Directly in the /etc/mibs/data1g_8q.ini or equivalent used by OMCI protocol.

Which should also come from the firmware image...

I'll have to double check the config partition to see if it's something there that may be causing it.

I have one module that seems to only accept 3FE47111BFHB32, and one that still accepts 3FE47111BFHB32 and 3FE46398BGCB22. They are the same hardware version and the obvious places are identical in configuration.

I'll dig a bit deeper...

[wteiken]

I'll dig a bit deeper...

Finally found some time, it was the dying gasp issue. It seems that newer versions of sfp_ic2 enable dying gasp based on an eeprom value, even if uci says do not enable. That combined with one messed up version of the eeprom plus hosts behaving differently caused some confusion. I added the issue to the compatibility tables for hosts and firmware versions.

Added host behavior as best as I know.

Given I heard no other comments about newer firmwares I assume the newer firmwares boot properly with your hosts?

Also: I now have a working strace for the module :-)

[tdmadam]

Finally found some time, it was the dying gasp issue. It seems that newer versions of sfp_ic2 enable dying gasp based on an eeprom value, even if uci says do not enable. That combined with one messed up version of the eeprom plus hosts behaving differently caused some confusion. I added the issue to the compatibility tables for hosts and firmware versions.

I have no issues with newer firmware, especially since it allows me to capture initial OMCI exchange. This is something I could not get with older versions. And Dying Gasp can be problematic for some users. Is it possible to disable it with sfp_ic2 ? What is the location in eeprom where this option is stored ? In the worst case, the eeprom A0h/A2h table will have to be changed manually.

Also: I now have a working strace for the module :-)

Would you mind sharing the working process (host platform, correct source, compiler options)? This may prove useful in the future if other binaries are needed.

[wteiken]

Finally found some time, it was the dying gasp issue. It seems that newer versions of sfp_ic2 enable dying gasp based on an eeprom value, even if uci says do not enable. That combined with one messed up version of the eeprom plus hosts behaving differently caused some confusion. I added the issue to the compatibility tables for hosts and firmware versions.

I have no issues with newer firmware, especially since it allows me to capture initial OMCI exchange. This is something I could not get with older versions. And Dying Gasp can be problematic for some users. Is it possible to disable it with sfp_ic2 ? What is the location in eeprom where this option is stored ? In the worst case, the eeprom A0h/A2h table will have to be changed manually.

You need to patch the firmware. The sfp_eeprom.sh boot script sets the eeprom value controlling dying gasp and then starts sfp_i2c -a that reads that value and enables the dying gasp. This causes an immediate reboot on at least two of my sfp hosts (only in the media converter does the sfp not reboot immediately once dying gasp is enabled). I have not yest tested the module with the newer firmware in my CRS305.

Also: I now have a working strace for the module :-)

Would you mind sharing the working process (host platform, correct source, compiler options)? This may prove useful in the future if other binaries are needed.

I basically built a standard buildroot cross compiler chain for mips32 with soft fpu on an x86, and then a standard strace with a static option. I'll write up some more details next week. The main issue with all binary crosscompilers I could find is that they all assume hard fpu. Had I known that buildroot is actually pretty painless I would have not looked as much for a precompiled cross compiler.