If it is your primary ISP router , I wont recommend flashing anything. In anycase you can try booting an initramfs image. (In my case I am having 4 different devices with en7528 , all are ISP supplied ( procured cheaply from FB marketplace))
Sure, I’ll try flashing it on my ONT. Additionally let me know if I can provide help in any other way.
Regards!
Have you been able to get your hands on an ex3301-t0?
1 Like
Yes, @pstlr78 was kind enough to send me another one, and I was able to unlock it and document the registers. See: https://econet-linux.pkt.wiki/en/hardware/EN751627.
Since @naseef ‘s awesome work on the EN7528, I plan to get that into basic support soon - but first I’m going to complete a fresh version of EcoNet Ethernet driver which is good enough to consider for upstreaming (and which hopefully doesn’t have the ugly packet loss problem that the current one has!)
4 Likes
Hi Caleb, I was working last couple of days on en7528 PCI and just now find out that I have the similar issue. The mt7615 ( vendor id 0x7663) is showing kernel panic. mt 7603 on pcie0 is working fine. Is this what you are experienceing?
[ 75.512233] pci_bus 0000:00: resource 4 [mem 0x20000000-0x23ffffff]
[ 75.518573] pci_bus 0000:01: resource 1 [mem 0x20000000-0x200fffff]
[ 75.524877] pci_bus 0000:01: resource 2 [mem 0x20100000-0x201fffff pref]
[ 75.531645] pci_bus 0000:02: resource 1 [mem 0x20200000-0x202fffff]
[ 75.537995] pci_bus 0000:02: resource 2 [mem 0x20300000-0x204fffff pref]
[ 75.544849] OF: /pcie@1fb80000/pcie@0,0: Missing device_type
[ 75.551710] pci 0000:00:00.0: enabling device (0000 -> 0002)
[ 75.557550] mt7603e 0000:01:00.0: enabling device (0000 -> 0002)
[ 75.563854] mt7603e 0000:01:00.0: ASIC revision: 76030010
[ 75.731691] mt7603e 0000:01:00.0: Firmware Version: ap_pcie
[ 75.737398] mt7603e 0000:01:00.0: Build Time: 20160107100755
[ 75.777307] mt7603e 0000:01:00.0: firmware init done
[ 75.950579] mt7603e 0000:01:00.0: registering led 'mt76-phy0'
[ 76.024097] pci 0000:00:01.0: enabling device (0000 -> 0002)
[ 76.030034] mt7615e 0000:02:00.0: enabling device (0000 -> 0002)
[ 76.038427] ------------[ cut here ]------------
[ 76.043085] WARNING: CPU: 0 PID: 1714 at target-mipsel_24kc_musl/linux-econet_en7528/mt76-2025.11.06~eb567bc7/mt7615/eeprom.c:31 mt7615_eeprom_init+0x484/0x548 [mt7615_common]
[ 76.058991] Modules linked in: pcie_mediatek(+) phy_en7528_pcie pppoe ppp_async nft_fib_inet nf_flow_table_inet pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt76x2e(O) mt76x2_common(O) mt76x02_lib(O) mt7615e(O) mt7615_common(O) mt7603e(O) mt76_connac_lib(O) mt76(O) mac80211(O) cfg80211(O) slhc nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c hwmon crc_ccitt compat(O) i2c_dev i2c_core sha512_generic seqiv sha3_generic jitterentropy_rng drbg hmac geniv rng cmac crc32c_generic
[ 76.125041] CPU: 0 UID: 0 PID: 1714 Comm: insmod Tainted: G O 6.12.62 #0
[ 76.125077] Tainted: [O]=OOT_MODULE
[ 76.125083] Hardware name: DASAN H660GM-A
[ 76.125092] Stack : 000000d0 00000004 0000000c 8186d688 82901984 8102db2c 00000001 01000000
[ 76.125145] 00000000 00000000 00000000 00000000 00000000 00000001 82901930 8084e200
[ 76.125184] 00000000 00000000 8182db68 829017b8 ffffefff 00000000 8190cb38 000000d1
[ 76.125224] 82901804 000000d3 8190cb68 fffffff9 00000001 00000000 8182db68 00000000
[ 76.125263] 00000000 82f482a4 81905530 00000400 00000003 fffc359f 00000000 81ac0000
[ 76.125303] ...
[ 76.125314] Call Trace:
[ 76.125318] [<81006788>] show_stack+0x28/0xf0
[ 76.125364] [<8173ad68>] dump_stack_lvl+0x70/0xb0
[ 76.125410] [<8102e35c>] __warn+0x9c/0x114
[ 76.125448] [<8102e4fc>] warn_slowpath_fmt+0x128/0x188
[ 76.125496] [<82f482a4>] mt7615_eeprom_init+0x484/0x548 [mt7615_common]
[ 76.125574] [<82f3c2c8>] mt7615_register_device+0xb0/0x230 [mt7615e]
[ 76.125629] [<82f3e140>] mt7615_mmio_probe+0x184/0x244 [mt7615e]
[ 76.125683] [<82f3c12c>] 0x82f3c12c
[ 76.125724]
[ 76.125729] ---[ end trace 0000000000000000 ]---
[ 76.240323] mt7615e 0000:02:00.0: registering led 'mt76-phy1'
[ 76.301306] mt7615e 0000:02:00.0: Firmware is not ready for download
I’ve got a C5500XK with an Econet EN7528GT, with a popped case and a serial console. I’d be happy to help test.
That is a WARN_ON and it actually shows in the log where the warn line is,
If I was to guess, I would say you are not correctly sending the EEPROM (which is typically on flash on these devices) to the wifi chip, the chip has no on-device EEPROM (typical) and so when it tries to load, it tries to use the on-chip which is nonexistent and it warns because it’s not working.
It's not an mt76/EEPROM issue - the root cause is in the PCI subsystem's handling of prefetch memory windows on EN7528.
During PCI enumeration, the kernel probes the bridge's prefetch memory registers by writing 0xffe0fff0 and reading back. On EN7528, these registers appear to ignore writes and always read back as 0x00000000. The kernel correctly detects this and sets bridge->pref_window=0.
However, later during resource allocation, pci_read_bridge_bases() is called and it unconditionally calls pci_read_bridge_mmio_pref() without checking the pref_window flag. This function reads base=0, limit=0 from the registers, and since 0 <= 0 evaluates to true, it creates a bogus prefetch window at [mem 0x00000000-0x000fffff pref].
This causes resource allocation issues for the mt7615e which has prefetchable BARs, ultimately leading to the EFUSE read failure
I'm not sure why EN7528 ignores writes to the prefetch registers - could be a hardware limitation or maybe I'm missing some initialization step. But this patch works for me and 5GHz WiFi is now functional:
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -541,7 +541,8 @@ void pci_read_bridge_bases(struct pci_bu
pci_read_bridge_io(child->self, child->resource[0], false);
pci_read_bridge_mmio(child->self, child->resource[1], false);
- pci_read_bridge_mmio_pref(child->self, child->resource[2], false);
+ if (dev->pref_window)
+ pci_read_bridge_mmio_pref(child->self, child->resource[2], false);
if (dev->transparent) {
pci_bus_for_each_resource(child->parent, res) {
Not 100% sure this is the right approach (maybe we should fix it in the PCIe driver instead), but it works. Please let me know your thoughts
1 Like
log after the patch
[ 53.744229] pci 0001:00:01.0: [14c3:0811] type 01 class 0x060400 PCIe Root Port
[ 53.751873] pci 0001:00:01.0: PCI bridge to [bus 00]
[ 53.756927] pci 0001:00:01.0: bridge window [mem 0x00000000-0x000fffff]
[ 53.766082] pci 0001:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 53.775098] pci 0001:01:00.0: [14c3:7663] type 00 class 0x000280 PCIe Endpoint
[ 53.782645] pci 0001:01:00.0: BAR 0 [mem 0x00000000-0x000fffff 64bit pref]
[ 53.789698] pci 0001:01:00.0: BAR 2 [mem 0x00000000-0x00003fff 64bit pref]
[ 53.796701] pci 0001:01:00.0: BAR 4 [mem 0x00000000-0x00000fff 64bit pref]
[ 53.804357] pci 0001:01:00.0: supports D1 D2
[ 53.808682] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 53.816252] pci 0001:00:01.0: PCI bridge to [bus 01-ff]
[ 53.821626] pci_bus 0001:01: busn_res: [bus 01-ff] end is updated to 01
[ 53.828391] pci 0001:00:01.0: bridge window [mem 0x28000000-0x281fffff]: assigned
[ 53.835899] pci 0001:00:01.0: bridge window [io size 0x1000]: can't assign; no space
[ 53.843786] pci 0001:00:01.0: bridge window [io size 0x1000]: failed to assign
[ 53.851160] pci 0001:01:00.0: BAR 0 [mem 0x28000000-0x280fffff 64bit pref]: assigned
[ 53.859068] pci 0001:01:00.0: BAR 2 [mem 0x28100000-0x28103fff 64bit pref]: assigned
[ 53.866927] pci 0001:01:00.0: BAR 4 [mem 0x28104000-0x28104fff 64bit pref]: assigned
[ 53.874816] pci 0001:00:01.0: PCI bridge to [bus 01]
[ 53.879888] pci 0001:00:01.0: bridge window [mem 0x28000000-0x281fffff]
[ 53.886771] pci_bus 0001:00: Some PCI device resources are unassigned, try booting with pci=realloc
[ 53.895862] pci_bus 0001:00: resource 4 [mem 0x28000000-0x2fffffff]
[ 53.902188] pci_bus 0001:01: resource 1 [mem 0x28000000-0x281fffff]
[ 53.909337] pci 0001:00:01.0: enabling device (0000 -> 0002)
[ 53.915132] mt7615e 0001:01:00.0: enabling device (0000 -> 0002)
[ 53.929071] mt7615e 0001:01:00.0: registering led 'mt76-phy1'
[ 54.301116] mt7615e 0001:01:00.0: mediatek/mt7663pr2h.bin not found, switching to mediatek/mt7663pr2h_rebb.bin
[ 54.484190] mt7615e 0001:01:00.0: HW/SW Version: 0x65322d31, Build Time: 2009041715da1a1
[ 54.484190]
[ 54.783490] mt7615e 0001:01:00.0: N9 Firmware Version: 7663mp1827, Build Time: 20200904171623
[ 54.792127] mt7615e 0001:01:00.0: Region number: 0x3
[ 54.797104] mt7615e 0001:01:00.0: Parsing tailer Region: 0
[ 54.805252] mt7615e 0001:01:00.0: Region 0, override_addr = 0x00112c00
[ 54.811929] mt7615e 0001:01:00.0: Parsing tailer Region: 1
[ 54.818100] mt7615e 0001:01:00.0: Parsing tailer Region: 2
[ 54.823972] mt7615e 0001:01:00.0: override_addr = 0x00112c00, option = 3
Well, if it solves the problem, I suppose you could add it to EcoNet with a comment about this as a hardware quirk. Some vendor code might tell us more about what is supposed to happen.