My OMCI layer is being written as generically as possible, with some optional features, so if any vendor is added in the future, it can be integrated, probably some Realtek SoC
Amazing. As for the DSL, I don't know how portable will that be for other platforms like Lantiq XRX200 which already has OpenWrt DSL. Also, is there any provision for VoIP?
Not yet, I have two devices with FXS, but I have no idea how to implement it, and the EN7523 doesn't have the PCM drivers to control this part now
I guess we will have to do what the Lantiq folks do and create a fork of asterisk. But not before a SLIC driver is available. Still, amazing work so far.
Data-path gate on Nokia/DZS OLTs: the OLT won't create the data GEM-CTP unless the ONU returns complete Priority-Queue (277) and Traffic-Scheduler (278) in MIB Upload
▎
▎ Sharing a finding from reverse-engineering an EcoNet EN7528 ONT (H660GM-A) against a live Nokia/DZS GPON OLT, since #5 is heading toward testing against a real Nokia OLT and this one cost us several sessions.
▎
▎ Symptom: ONU reaches O5, authenticates, answers every OMCI frame, and the OLT runs its provisioning — but it only ever creates the management/OMCC GEM, never the data GEM-CTP. Result: O5 + full OMCI but no upstream data path, and (on a carrier OLT) 0 PADO. It looks like a datapath bug but the OLT is deliberately withholding the data GEM.
▎
▎ Root cause: the Nokia (DZS) OLT is Create-driven, but before it issues Create GEM port network CTP for the data GEM it reads the ONU's Priority-Queue (ME 277) and Traffic-Scheduler (ME 278) instances via MIB Upload and gates on their completeness. If the ONU returns those MEs with a partial attribute mask, the OLT concludes it can't bind a GEM → queue → scheduler → T-CONT and silently never creates the data GEM.
▎
▎ Concretely, what made the OLT create the data GEM-CTP for us was returning, in MIB_Upload_Next:
▎ - Priority-Queue (277) with attribute mask 0xfff0 — i.e. all 12 baseline attributes, critically Related port (attr 6, bit 10) and Traffic-scheduler pointer (attr 7, bit 9). A thin default (e.g. only Maximum queue size) is what the OLT rejects.
▎ - Traffic-Scheduler (278) with attribute mask 0xf000 — all 4 attributes, critically T-CONT pointer (attr 1, bit 15).
▎ The Related port and the T-CONT pointer have to reflect the real queue↔scheduler↔T-CONT topology of the ONU hardware, not placeholders.
▎
▎ Why this bites a generic OMCI agent specifically: 277/278 are pre-existing hardware resources discovered by the OLT via MIB Upload — they are not created by the OLT. So the agent's default/pre-provisioning MIB has to seed these instances complete (with correct related-port / T-CONT pointers) before the OLT ever talks. An opaque-attribute store that returns a minimal default will pass a permissive lab OLT and then fail exactly here on Nokia.
▎
▎ Diagnostic tell: capture the OLT's Create/Set sequence at registration. If you see the T-CONT, GEM-IW-TP and Priority-Queue Sets go by but never a Create GEM port network CTP for the data GEM (only the OMCC GEM), you're hitting this — check what mask your agent returns for 277/278 in MIB Upload.
▎
▎ Separate but related caveat for testing against a carrier Nokia OLT: even with perfect OMCI, a carrier OLT won't forward upstream traffic unless the ONU's serial number is provisioned as a subscriber in the operator's OSS — that gate is off-device and not expressible on the wire (we confirmed this by getting a port byte-identical to a served stock unit on the same fiber and still getting 0 PADO). So I'd validate the datapath against the SFP-stick/lab OLT (no OSS gate); if a carrier OLT reaches O5 + does OMCI but passes no traffic, suspect OSS provisioning, not your OMCI stack.
▎
▎ Happy to share the stock-vs-port OMCI captures and the exact 277/278 attribute dumps if useful.
The xr500v-openwrt tree contains pcm and slic drivers. And a voice stack.
OMCI should be at the user land level. The code gets quite ugly when you have to call user land stuff from kernel space.
At least that is how all other implementations I have seen have been done.
I'm working with the PCM here on the XX230V, first, I'm fixing the boot process with RouterBoot on the Mikrotik hEX S 2025
We can keep the form that's in the SDK, we'll have to export several functions, put some things in the debugfs, a good part of the code that's in my repository can be corrected, but I plan to keep a good part of the OMCI code integrated into the kernel. Releasing a patch in the kernel is easier than in 3 packages, which could be one for each future/present architecture, or implement a generic interface that you can use later in ADSL with minor corrections. I don't mind taking everything that's already been written and throwing it away, but we can start a standard, or maintain a closed base for each architecture. If you think the way I'm implementing it is bad, I'll take everything that's been written and throw it away, stop the OMCI part and focus only on the MAC and PHY part. But the way I'm implementing it, maintenance with the driver is easy. I'm just defining and testing things, besides the tests.
Being a little different from the SDK can be a good thing, if we send it to the upstream kernel and it's rejected, we can revert to Userspace, I wouldn't mind that.
I'm thinking long term and with a maintenance perspective. But right now we are in the early phase. It doesnt really matter how things are to begin with as long as we get development velocity.
First I like the device approach Airoha has, you can see that there is an omci interface with traffic sent and received. And I would like to have tooling where we can sniff/record omci traffic and get a textual representation of it. Then we could keep those traces as a OLT compatibility corpus. It should also be possible to test "our" OMCI stack against this corpus to make sure that it doesnt regress. OLT compatibility is a complex thing and we need to build structure around it to be able to handle it.
But I've had a change of mind slightly. Maybe the OMCI stack should be a hybrid stack. Some parts/MIBs could be handled in the kernel and some parts could be handled in user space.
And regarding what you should focus on that is up to you. Focus on some fun stuff. Until I have sorted out the wifi stuff, then I will need help cleaning that up.
My initial approach was to maintain a hybrid communication, but if one part fails, everything could stop working this way. So I thought about keeping everything in the kernel. In userspace, we can create tools with the standard already defined in the kernel, using the netlink generic, and in some cases we can add some things inside /sys/class to not depend heavily on netlink, and we can create shell scripts. I'm trying to avoid creating a network interface where a novice user could connect somewhere and start crashing the entire stack due to filtering processing.
In the future, we can integrate xpon into netifd.
Now I'm trying to get the Si32192FM1 to show some sign of life to test my driver
If any part of a system fails, the system stops to work (ideally it should recover, but anyway)
Userspace is a great place for massive vendor-agnostic parts (hostapd might be an example), or, on the other hand, vendor-specific parts, like what OLT router connected to (it would be weird if driver will make decisions based on OLT vendor; it should be passed down from userspace)
Hi all i have a tplink archer VR2100 (EN7516 / EN751627 chip with MT7615 and MT7603 radios and an ESMT F50L1G41LB NAND) booting OpenWrt from flash and the wifi is working. I just want to clarify i dont know that much about this but I wanted to share my findings here because this seems to be the only OpenWrt progress for the EN7516 family of chips.
What ive got working so far is:
A custom dts, it boots from flash, i preserved the dualboot via the reserve partition boot flag, both radios work, usb works, and i have a serial console via tcboot over UART.
Ive found that the bootloader wants the legacy header not 2RDH. The VR2100 bootloader reports version 1.1 free bootbase and does not parse the 2RDH header from tclinux-trx.sh and it needs the old '55 aa 55 aa' tag. I worked around it by copying the stock 512 byte header and patching in the openwrt kernal/rootfs offsets (script attached).
Right now wifi wont come up via netifd 'command failed: Not Supported (-122)' during phy config and hostapd gets an empty interface config repeated Set MLD config: [ ] in the log). Creating the AP manually (iw phy phy0 interface add wlan0 type ap + manual hostapd) works perfectly, so the radios/driver are fine its something in wifi-scripts config generation. Is this a known issue on mt7615/mt7603 in current snapshots?
I have a uboot chainload with the Ethernet + spi-nand draft for the en7526gt, but I don't quite understand how the tcboot.bin file from econet sdk
GA IC
Xtal:1
DDR3 init.
DRAMC init done.
Calculate size.
DRAM size=256MB
Set new TRFC.
ddr-1066
7512DRAMC V1.2.2 (0)
Set SPI Flash Clock to 25 Mhz
U-Boot 1.1.5 (Oct 30 2018 - 15:58:06)
CPU: EN751221
DRAM: Memory Size: 256 MB
Set SPI Flash Clock to 25 Mhz
spi_nand_probe: mfr_id=0xef, dev_id=0xaa
Dected SPI NAND Flash : _SPI_NAND_DEVICE_ID_W25N01G, Flash Size=0x8000000
bmt pool size: 81
BMT & BBT Init Success
DEBUG FLAG : 1
Using default environment
In: serial
Out: serial
Err: serial
Net: MTK Switch
MAC addresses in MRD and Env don't match.
Use MAC in MRD: C0:3D:D9:AD:6F:98
## Starting application at 0x81F00000 ...
OK
Hit any key to stop autoboot: 5
ZHAL> atgu
=>## Application terminated, rc = 0x0
u-boot # loadx 81000000
## Ready for binary (xmodem) download to 0x81000000 at 115200 bps...
C
[console] XMODEM send: select a host file; append `1k` to use XMODEM-1K
console> xmodem-send /mnt/Data/airoha_en7523/u-boot/u-boot-dtb.bin
XMODEM send [############################] 100% 322.4 KiB/322.4 KiB 9.8 KiB/s ETA 00:00
sent 330159 bytes
[console] resumed
xyzModem - CRC mode, 2580(SOH)/0(STX)/0(CAN) packets, 6 retries
## Total Size = 0x00050a00 = 330240 Bytes
u-boot # crc32 81000000 50a00
u-boot # go 81000000
## Starting application at 0x81000000 ...
U-Boot 2026.07-00055-g4ecaa2db5686-dirty (Jul 29 2026 - 17:46:20 +0000)
CPU: EcoNet/Airoha EN7512/EN7521 MIPS34K
Clock: 225 MHz
Model: EcoNet EN7512/EN7521 reference board
DRAM: 256 MiB
Core: 6 devices, 6 uclasses, devicetree: separate
Loading Environment from nowhere... OK
In: serial@1fbf0000
Out: serial@1fbf0000
Err: serial@1fbf0000
Net:
Warning: airoha-gdm1 (eth0) using random MAC address - 6a:0d:29:90:6c:33
eth0: airoha-gdm1
=> md
md - memory display
Usage:
md [.b, .w, .l] address [# of objects]
=> dm
Unknown command 'dm' - try 'help'
=> mtd list
List of MTD devices:
* spi-nand0
- device: nand@0
- parent: spi@1fa10000
- driver: spi_nand
- path: /soc/spi@1fa10000/nand@0
- type: NAND flash
- block size: 0x20000 bytes
- min I/O: 0x800 bytes
- OOB size: 64 bytes
- OOB available: 24 bytes
- ECC strength: 1 bits
- ECC step size: 512 bytes
- bitflip threshold: 1 bits
- 0x000000000000-0x000008000000 : "spi-nand0"
=> ping 192.168.1.10
*** ERROR: `ipaddr' not set
ping failed; host 192.168.1.10 is not alive
=> setenv ipaddr 192.168.1.1
=> ping 192.168.1.10
Using airoha-gdm1 device
ping failed; host 192.168.1.10 is not alive
=> ping 192.168.1.10
Using airoha-gdm1 device
ping failed; host 192.168.1.10 is not alive
=> ping 192.168.1.10
Using airoha-gdm1 device
host 192.168.1.10 is alive
=>
Today I have a slightly more stable xpon driver on the en7523. Tests were performed using a Nokia OLT (my ISP) and a "generic" OLT in a bench test (where these iperf3 tests were done). DHCP and PPPoE connections are stable with hardware offload working
╭─sirherobrine23@matheus-note ~
╰─$ iperf3 -c 172.16.0.1 -R 1 ↵
Connecting to host 172.16.0.1, port 5201
Reverse mode, remote host 172.16.0.1 is sending
[ 5] local 192.168.1.220 port 42492 connected to 172.16.0.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 18.9 MBytes 158 Mbits/sec
[ 5] 1.00-2.00 sec 20.5 MBytes 172 Mbits/sec
[ 5] 2.00-3.00 sec 22.2 MBytes 187 Mbits/sec
[ 5] 3.00-4.00 sec 24.4 MBytes 204 Mbits/sec
[ 5] 4.00-5.00 sec 22.6 MBytes 190 Mbits/sec
[ 5] 5.00-6.00 sec 22.0 MBytes 185 Mbits/sec
[ 5] 6.00-7.00 sec 20.6 MBytes 173 Mbits/sec
[ 5] 7.00-8.00 sec 17.9 MBytes 150 Mbits/sec
[ 5] 8.00-9.00 sec 20.6 MBytes 173 Mbits/sec
[ 5] 9.00-10.00 sec 22.9 MBytes 192 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 213 MBytes 179 Mbits/sec 2 sender
[ 5] 0.00-10.00 sec 213 MBytes 178 Mbits/sec receiver
iperf Done.
╭─sirherobrine23@matheus-note ~
╰─$ iperf3 -c 172.16.0.1
Connecting to host 172.16.0.1, port 5201
[ 5] local 192.168.1.220 port 51628 connected to 172.16.0.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 78.2 MBytes 655 Mbits/sec 0 1000 KBytes
[ 5] 1.00-2.00 sec 78.8 MBytes 661 Mbits/sec 0 1.04 MBytes
[ 5] 2.00-3.00 sec 88.5 MBytes 743 Mbits/sec 0 1.04 MBytes
[ 5] 3.00-4.00 sec 77.8 MBytes 652 Mbits/sec 0 1.04 MBytes
[ 5] 4.00-5.00 sec 71.4 MBytes 599 Mbits/sec 278 796 KBytes
[ 5] 5.00-6.00 sec 74.8 MBytes 627 Mbits/sec 0 861 KBytes
[ 5] 6.00-7.00 sec 89.0 MBytes 746 Mbits/sec 0 861 KBytes
[ 5] 7.00-8.00 sec 89.1 MBytes 748 Mbits/sec 0 862 KBytes
[ 5] 8.00-9.00 sec 79.2 MBytes 665 Mbits/sec 0 870 KBytes
[ 5] 9.00-10.00 sec 70.2 MBytes 589 Mbits/sec 0 886 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 797 MBytes 669 Mbits/sec 278 sender
[ 5] 0.00-10.01 sec 795 MBytes 666 Mbits/sec receiver
iperf Done.
root@OpenWrt:~# iperf3 -c 172.16.0.1
Connecting to host 172.16.0.1, port 5201
[ 5] local 10.67.15.43 port 52416 connected to 172.16.0.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 54.1 MBytes 453 Mbits/sec 0 862 KBytes
[ 5] 1.00-2.00 sec 55.1 MBytes 462 Mbits/sec 0 862 KBytes
[ 5] 2.00-3.00 sec 57.0 MBytes 479 Mbits/sec 0 1.05 MBytes
[ 5] 3.00-4.00 sec 58.9 MBytes 493 Mbits/sec 0 1.05 MBytes
[ 5] 4.00-5.00 sec 81.9 MBytes 688 Mbits/sec 0 1.05 MBytes
[ 5] 5.00-6.00 sec 61.2 MBytes 513 Mbits/sec 0 1.05 MBytes
[ 5] 6.00-7.00 sec 53.0 MBytes 445 Mbits/sec 0 1.05 MBytes
[ 5] 7.00-8.00 sec 69.8 MBytes 585 Mbits/sec 0 1.05 MBytes
[ 5] 8.00-9.00 sec 61.5 MBytes 516 Mbits/sec 0 1.05 MBytes
[ 5] 9.00-10.00 sec 58.2 MBytes 488 Mbits/sec 0 1.05 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 611 MBytes 513 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 611 MBytes 512 Mbits/sec receiver
iperf Done.
root@OpenWrt:~# iperf3 -c 172.16.0.1 --bidir
Connecting to host 172.16.0.1, port 5201
[ 5] local 10.67.15.43 port 49466 connected to 172.16.0.1 port 5201
[ 7] local 10.67.15.43 port 49482 connected to 172.16.0.1 port 5201
[ ID][Role] Interval Transfer Bitrate Retr Cwnd
[ 5][TX-C] 0.00-1.01 sec 43.1 MBytes 359 Mbits/sec 0 802 KBytes
[ 7][RX-C] 0.00-1.01 sec 19.1 MBytes 159 Mbits/sec
[ 5][TX-C] 1.01-2.00 sec 50.4 MBytes 426 Mbits/sec 0 1.04 MBytes
[ 7][RX-C] 1.01-2.00 sec 18.2 MBytes 154 Mbits/sec
[ 5][TX-C] 2.00-3.00 sec 51.9 MBytes 435 Mbits/sec 0 1.10 MBytes
[ 7][RX-C] 2.00-3.00 sec 18.5 MBytes 155 Mbits/sec
[ 5][TX-C] 3.00-4.00 sec 52.6 MBytes 441 Mbits/sec 0 1.10 MBytes
[ 7][RX-C] 3.00-4.00 sec 18.4 MBytes 154 Mbits/sec
[ 5][TX-C] 4.00-5.00 sec 45.1 MBytes 379 Mbits/sec 0 1.10 MBytes
[ 7][RX-C] 4.00-5.00 sec 17.9 MBytes 150 Mbits/sec
[ 5][TX-C] 5.00-6.00 sec 40.6 MBytes 341 Mbits/sec 0 1.10 MBytes
[ 7][RX-C] 5.00-6.00 sec 17.8 MBytes 149 Mbits/sec
[ 5][TX-C] 6.00-7.00 sec 43.4 MBytes 364 Mbits/sec 0 1.10 MBytes
[ 7][RX-C] 6.00-7.00 sec 15.6 MBytes 131 Mbits/sec
[ 5][TX-C] 7.00-8.00 sec 50.2 MBytes 422 Mbits/sec 0 1.10 MBytes
[ 7][RX-C] 7.00-8.00 sec 17.9 MBytes 150 Mbits/sec
[ 5][TX-C] 8.00-9.00 sec 48.5 MBytes 407 Mbits/sec 0 1.10 MBytes
[ 7][RX-C] 8.00-9.00 sec 19.0 MBytes 159 Mbits/sec
[ 5][TX-C] 9.00-10.00 sec 51.0 MBytes 427 Mbits/sec 0 1.10 MBytes
[ 7][RX-C] 9.00-10.00 sec 18.5 MBytes 155 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval Transfer Bitrate Retr
[ 5][TX-C] 0.00-10.00 sec 477 MBytes 400 Mbits/sec 0 sender
[ 5][TX-C] 0.00-10.02 sec 477 MBytes 399 Mbits/sec receiver
[ 7][RX-C] 0.00-10.00 sec 182 MBytes 152 Mbits/sec 0 sender
[ 7][RX-C] 0.00-10.02 sec 181 MBytes 152 Mbits/sec receiver
iperf Done.
root@OpenWrt:~#
Hi sirherobrine23,
I run similar test on my H660 EN7528 latest build, full GPON stack now working.
Thanks,
Great, today I managed to hit 750 Up/Down in my bench tests in Openwrt and with hw offload on my laptop with ethernet cable. The commits are already in my kernel for analysis
I'll be playing around with u-boot for the Econet, and soon I plan to start porting the Econet's gpon as well
I opened a draft PR with my changes:
Sorry to interrupt your work. I believe TFTP would be a more suitable option than XMODEM for transferring the firmware image. The bootloader documentation indicates that TFTP can be used for this purpose.
You may find the relevant information here:
Some vendors patch out tftp from the bootloader so it's not a catch-all solution.