Debugging EcoNet's MT7530 PHYs

[Valent@MeshPoint]

Hi Caleb and list,
This email is primarily for Caleb - I'm offering technical 
collaboration. If the details below aren't relevant to you, feel free to 
skip this one. Caleb and I will likely continue the conversation 
off-list.
First: thank you, Caleb, for posting about EN751221 on this list. I 
would never have discovered this hardware otherwise. I'd heard of CJDNS 
and PKT before, but honestly never studied it deeply or considered 
practical applications - until now. With some new projects we're 
starting, I finally have a broader picture where PKT makes tremendous 
sense.
WHO I AM
I'm Valent Turkovic from MeshPoint, a Croatian company building outdoor 
mesh WiFi equipment. My background is in humanitarian action and crisis 
response - that's actually where MeshPoint was born.
THE MESHPOINT STORY
We started building mesh networks for disaster response and underserved 
communities. Over 10+ years, we've learned that the biggest problem 
isn't getting equipment deployed - it's maintaining it long-term. In 
Haiti, in Puerto Rico after the hurricane, everywhere in the world - the 
pattern is the same: volunteers arrive, equipment gets installed, 
organizations eventually leave, and then infrastructure falls apart. 
There's simply no incentive for ongoing maintenance.
This is where I see PKT's enormous potential.
WHY PKT MATTERS FOR HUMANITARIAN USE
I believe internet access is a fundamental human right. But I've also 
learned the hard way that "free" alone doesn't work.
We ran a project called "Otvorena Mreža" (Open Network) together with 
WLAN Slovenia, deploying free community hotspots. It worked beautifully 
- until 2-3 key people left the project. With no financing model for 
maintenance, everything collapsed.
The lesson: we need balance. Some services must be free (because 
internet is a human right), but the infrastructure backbone must be 
self-sustaining. PKT's model - where people maintaining the network are 
financially incentivized - could solve this exact problem.
WHAT I'M BUILDING NOW
I'm working heavily on automation and AI for network maintenance - 
systems that can be self-sustaining with minimal human intervention. The 
goal: maintain 1000 nodes on the other side of the world with minimal 
effort, remotely. That's what MeshPoint.Two will enable.
I see the architecture clearly now:
- PKT Network = self-sustaining backbone (Caleb's piece)
- MeshPoint = outdoor edge nodes (our piece)
- EN751221 hardware = the bridge
THE COLLABORATION I'M PROPOSING
I want to help with the MT7530 PHY issues and whatever hardware 
challenges you're facing. We have hands-on experience with MediaTek 
chipsets from our own OpenWRT work.
But I also want to learn from you. I'd like to either:
- Build backbone infrastructure using this hardware for our humanitarian 
projects, or
- Connect directly with PKT Network if that makes sense
I haven't studied PKT deeply enough yet to know which path is better - 
I'd love to discuss.
NEXT STEPS
Let's take this off-list. I'd welcome a video call to explore how we can 
help each other. My email: valent at meshpointone.com
Thank you again for sharing your work publicly. It connected dots I 
didn't know needed connecting.
Best,
Valent Turkovic
MeshPoint
https://www.meshpointone.com


------ Original Message ------
>From "Caleb James DeLisle" <cjd at cjdns.fr>
To "Daniel Golle" <daniel at makrotopia.org>
Cc "Felix Baumann" <felix.baumann at freifunk-aachen.de>; 
openwrt-devel at lists.openwrt.org
Date 27.1.2026. 18:26:41
Subject Re: Debugging EcoNet's MT7530 PHYs

>>
>>Would there be any reason not to set BMCR_PDOWN in mt7530_phy_config_init() so we know they're in a consistent state?
>>
>>Also if you happen to have an MT7621 sitting there running, would you mind setting BMCR_ANENABLE | BMCR_ANRESTART with mdio on a running port to see if it's the same behavior? The port should immediately die and then go into a loop trying to connect every few seconds / minutes depending on what it's connected to.
>>
>Whoops, spoke too soon. dsa_register_switch() (indirectly) calls phy_resume() so the phy is up while the port is down. However, adding this to mt7530_port_enable() does make it work:
>
>     if (priv->id == ID_EN751221_EXT && phy)
>         genphy_soft_reset(phy);
>
>I note that if the port is brought up within seconds of having been reset, then it seems to work (at least sporadically) despite the BMCR_ANENABLE bug. I imagine this is something that can be tuned out, but given it's happening in the bootloader, I don't have much confidence that I'm going to find the knob to fix it. I've got a problem with my vendor OS image, but when I get that fixed I'll check that as well.
>
>In the mean time, if any likely culprits come to mind, do let me know.
>
>Thanks,
>
>Caleb
>
>
>_______________________________________________
>openwrt-devel mailing list
>openwrt-devel at lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-devel