Today is an auspicious day. It appears 25.12 has gone final. Coincidentally, due to the overall stability of recent builds, I have decided to pause chasing snapshots and declare the March 3rd builds as stable and notable. Or, to use a familiar vernacular, they are OpenW1700k 26.03 rc1.
The minimal-oc branch is the only exception to this, and will continue to chase snapshot, have experimental patches, may crash your system, etc.
In conjunction with this, I have updated the installer to include the March 3rd build of minimal. I still haven't figured out why it hangs when auto-running an install script, but did discover that a user-initiated script completes just fine. Therefore, once you have the installer initramfs running, you merely have to type ./install.sh
If you still have some virgin devices lying around, now would be a good time to test.
Tested again with the pre-built lumos-npu image, fresh configuration.
Unfortunately the problem remains, fails after just two link speed changes.
I donāt know if it matters but I donāt have a 10G NIC right now so Iāve been testing on a 1G NIC, switching between 1000 and 100.
Hey guys, i build a new image using lumos-npu branch, but in the soc app, in the field npu firmware i have unknown. Is there a way to fix this without building a new image ?
edit /usr/libexec/rpcd/luci.airoha_npu
@andrewjlamarche @hurrian @tesf23 Well this is interesting.
Co-Authored-By: Claude Opus 4.6 (1M context). Does this even work?
Could you take a look if you have same issue with my image ?
@OpenWRT-fanboy if you are doing any automatic rebasing from my PR, Iād advise you to axe it for now, big changes coming soon that are completely incompatible.
It failed after 41 link speed changes.
IMHO you have same issue as I have in the past. In my case, I changed UTP connectors and it helps. Consider to change cable, especially when is below class 7
Iām still on GbE though, and it only happens with this device, with two different cables.
Unfortunately, the airoha: add patch to fix USXGMII RX after speed changes was not the panacea we hoped it would be for 10G issues.
After incorporating this patch, lan2 stopped working, despite no plugging activity.
I have reverted this patch. Without it, I plugged and unplugged wan and lan2 ten times and there were no issues. I am unable to replicate this particular problem, so cannot help troubleshoot.
In my case plugging the cable into one of the 1G ports before the 10G works.
Didnāt fix the previous issue though. The patch message says itās supposed to fix RX, but the problem here is TX.
so we're just going to force the entire userbase to repartition to solve for a problem that they (by definition) do not have... sure this will go well.
To be fair, the support was never official. I agree that it's probably a small chance that people have issues at some point, but myself and others have reported problems with blocks going bad, requiring us to open it and reflash. IMO, I think itās a fair compromise to develop this workaround. There should be 0 issues moving forward, unless someone decides to update u-boot and @hurrian is making an installer script to make it as painless as possible.
@hurrian Feature request that reset button triggers launch of recovery initramfs.
I had the same issue on minimal. WAN seemed to work (with a 10G device) but I couldnāt get a link up on LAN2 with 1G/100M devices.
For now Iāve stopped using the 10G ports and trunk out to a switch on LAN3/4 as the 10G ports donāt seem stable enough at the moment.
I'm pleased to announce that the first preview release of the fully automated UBI conversion + OpenWrt installer has been completed.
Instructions are now available in my repository; and a binary release is available for download.
Please note that a serial connection is required for installation.
Due to the way BMT works, it is impossible to perform the migration from a running OpenWrt installation.
The installer script is a bit rough around the edges, so I would appreciate feedback and improvements.
This is not possible for now since GPIO isn't quite wired up yet in U-boot.
However, GPIO leds and keys are already configured in our U-boot device tree - so once support lands it would be easy to add support for this.
I'm currently looking into whether we can use pstore on this platform to pass a flag to the chainloader on reboot, so we could trigger booting into the recovery partition without a UART connected.
