This laser driver acts as a phy for the BOSA. The control interface is 16 bit (rather unusual io) i2c. We need a driver that can load the firmware to the chip and can expose DDM compliant data.
This laser driver acts as a phy for the BOSA. The control interface is 16 bit (rather unusual io) i2c. We need a driver that can load the firmware to the chip and can expose DDM compliant data.
Yes, so I have a design that uses PTP ethernet with the EN7571. I will use that to validate the laser drive. To get XPON working it is a long long long way until it is of interest to work on.
Yes, so I have a design that uses PTP ethernet with the EN7571. I will use that to validate the laser drive. To get XPON working it is a long long long way until it is of interest to work on.
The serdes (pon port) can do xpon or active ethernet. The first thing to get working is active ethernet. Pon stuff will have to wait until the Econet tasks from Caleb is taking shape.
The serdes (pon port) can do xpon or active ethernet. The first thing to get working is active ethernet. Pon stuff will have to wait until the Econet tasks from Caleb is taking shape.
The serdes (pon port) can do xpon or active ethernet. The first thing to get working is active ethernet. Pon stuff will have to wait until the Econet tasks from Caleb is taking shape.
I think we can do this ourselves; a large part of the SoCs are shared, many things are the same between them, and the airoha SoCs are already well-structured in the mainline kernel. The econet SoCs will share much of the airoha structure, so only a few adaptations will be needed
> The serdes (pon port) can do xpon or active ethernet. The first thing to get working is active ethernet. Pon stuff will have to wait until the Econet tasks from Caleb is taking shape.
I think we can do this ourselves; a large part of the SoCs are shared, many things are the same between them, and the airoha SoCs are already well-structured in the mainline kernel. The econet SoCs will share much of the airoha structure, so only a few adaptations will be needed
Well the problem is the testing part. It is easy to test if you have everything working, now it is the serdes, laser driver, omci stack and the external OLT. Debugging that is hard. We need to divide the task in small small components. But we'll figure that out when we get there.
Well the problem is the testing part. It is easy to test if you have everything working, now it is the serdes, laser driver, omci stack and the external OLT. Debugging that is hard. We need to divide the task in small small components. But we'll figure that out when we get there.
I'm thinking about how I can improve the private PON driver. Is it possible to run the OMCI server in the kernel on the driver, and map a partition to store the configurations? I could also create an integration with generic netlink for communication with OMCI for configuration
I'm thinking about how I can improve the private PON driver. Is it possible to run the OMCI server in the kernel on the driver, and map a partition to store the configurations? I could also create an integration with `generic netlink` for communication with OMCI for configuration
The OMCI "server" is on the other side of the optical link. Anyway it is a really complex world on its own. I added an introduction document here. It is a real uphill battle and it would need serious development man power.
The OMCI "server" is on the other side of the optical link. Anyway it is a really complex world on its own. I added an introduction document here. It is a real uphill battle and it would need serious development man power.
@merbanan, given the way this phy is currently structured, would it be faster to integrate it into the Linux kernel and develop an eth driver for it?
We managed to recover some things from the pre-processed files that are on the GPLs; much hasn't changed between the chips, Many driver components can now be reduced to a single file with minor modifications
@merbanan, given the way this phy is currently structured, would it be faster to integrate it into the Linux kernel and develop an eth driver for it?
We managed to recover some things from the pre-processed files that are on the GPLs; much hasn't changed between the chips, Many driver components can now be reduced to a single file with minor modifications
https://sirherobrine23.com.br/airoha_en7523/xPON/src/commit/190bf1f79c7590428051b9bfc50e1f7172cb76c6/econet_private/xpon_phy
One could make this really complicated but basically this is a SFP module on the pcb. IMO we should emulate how a real sfp module interfaces with a system. SFF-8472 describes the values that should be provided and the phy.c file also references alot of values.
Besides emulating the SFF-8472 interfaces we need the driver to load the calibration data and to support setting different modes during init (AE,EPON,GPON). This should be possible to configure in the dts.
If I understand the code correctly we should be able to wrap all mt7570/en7571 calls to SFF-8472 compatible i2c calls. If we are able to do that properly we have the perfect abi/api for the pon phy to integrate into.
A pon phy and pon mac and its integration into the soc eth driver will be a beast of its own. But lets not involve that in the laser driver.
My answer here is not complete enough to build a final driver. But we need the parts that can load the calibration data and perform internal calibration and also methods to extract the SFF-8472 data.
I'll try to post some logs that can describe this in more details.
One could make this really complicated but basically this is a SFP module on the pcb. IMO we should emulate how a real sfp module interfaces with a system. SFF-8472 describes the values that should be provided and the phy.c file also references alot of values.
Besides emulating the SFF-8472 interfaces we need the driver to load the calibration data and to support setting different modes during init (AE,EPON,GPON). This should be possible to configure in the dts.
If I understand the code correctly we should be able to wrap all mt7570/en7571 calls to SFF-8472 compatible i2c calls. If we are able to do that properly we have the perfect abi/api for the pon phy to integrate into.
A pon phy and pon mac and its integration into the soc eth driver will be a beast of its own. But lets not involve that in the laser driver.
My answer here is not complete enough to build a final driver. But we need the parts that can load the calibration data and perform internal calibration and also methods to extract the SFF-8472 data.
I'll try to post some logs that can describe this in more details.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This laser driver acts as a phy for the BOSA. The control interface is 16 bit (rather unusual io) i2c. We need a driver that can load the firmware to the chip and can expose DDM compliant data.
Let's leave that for later, let's solve the PSE problem first
From what I'm seeing in the private code, we'll need to have the functional serdes first
Yes, so I have a design that uses PTP ethernet with the EN7571. I will use that to validate the laser drive. To get XPON working it is a long long long way until it is of interest to work on.
I added this issue for tracking.
The serdes (pon port) can do xpon or active ethernet. The first thing to get working is active ethernet. Pon stuff will have to wait until the Econet tasks from Caleb is taking shape.
I am compiling a new tree now based on your code.
I think we can do this ourselves; a large part of the SoCs are shared, many things are the same between them, and the airoha SoCs are already well-structured in the mainline kernel. The econet SoCs will share much of the airoha structure, so only a few adaptations will be needed
Well the problem is the testing part. It is easy to test if you have everything working, now it is the serdes, laser driver, omci stack and the external OLT. Debugging that is hard. We need to divide the task in small small components. But we'll figure that out when we get there.
I'm thinking about how I can improve the private PON driver. Is it possible to run the OMCI server in the kernel on the driver, and map a partition to store the configurations? I could also create an integration with
generic netlinkfor communication with OMCI for configurationThe OMCI "server" is on the other side of the optical link. Anyway it is a really complex world on its own. I added an introduction document here. It is a real uphill battle and it would need serious development man power.
have this docs for PON protocols
@merbanan, given the way this phy is currently structured, would it be faster to integrate it into the Linux kernel and develop an eth driver for it?
We managed to recover some things from the pre-processed files that are on the GPLs; much hasn't changed between the chips, Many driver components can now be reduced to a single file with minor modifications
190bf1f79c/econet_private/xpon_phyOne could make this really complicated but basically this is a SFP module on the pcb. IMO we should emulate how a real sfp module interfaces with a system. SFF-8472 describes the values that should be provided and the phy.c file also references alot of values.
Besides emulating the SFF-8472 interfaces we need the driver to load the calibration data and to support setting different modes during init (AE,EPON,GPON). This should be possible to configure in the dts.
If I understand the code correctly we should be able to wrap all mt7570/en7571 calls to SFF-8472 compatible i2c calls. If we are able to do that properly we have the perfect abi/api for the pon phy to integrate into.
A pon phy and pon mac and its integration into the soc eth driver will be a beast of its own. But lets not involve that in the laser driver.
My answer here is not complete enough to build a final driver. But we need the parts that can load the calibration data and perform internal calibration and also methods to extract the SFF-8472 data.
I'll try to post some logs that can describe this in more details.
I will close this issue as it is merely an extension of #5.