First of all, please do not complain about 8+32. I use them mostly as VLAN switches only. They have 5 Gigabit switch ports. Disabling uhttpd, dnsmasq, odhcpd, firewall... make them run very well for that purpose.
Today I tried to upgrade them from 22.03.2 to 22.03.3. At first I used the ImageBuilder to build a minimal image without these above daemons to save time disabling them. I flashed the 1st WRT320N and it bricked. I suspected a hardware issue, tried again on the 2nd one, and it bricked too.
I downloaded the official image and bricked the 3rd one now.
Are these images tested before releasing, or are they just an automated build to be used at the user's own risk?
P.S: as a side note, the ImageBuilder for target bcm47xx/mips74k seems to be broken. A simple command make image PROFILE="linksys_wrt320n-v1" will download everything and build images for all devices in that target, while I need the image for WRT320N only.
OpenWrt supports over 800 different devices, how do you imagine to test all of those? In many (by far most) cases no one of the developers has ever seen these devices, as most device support is user contributed (just another device for a well-known SOC family).
Reasons for breakage can vary massively, including minor size increases of the images, pushing beyond unknown thresholds of the bootloader (including actual bootloader bugs). It's impossible to guess without debugging this further, serial console logs would be helpful, as would be git-bisecting.
While you wave away the fact that 8/32 devices are explicitly unsupported, this could also be a contributing factor (in the sense of OOM preventing a successful boot). Testing of affected devices and targets also tends to be minimal for obvious reasons.
OpenWrt supports over 800 different devices, how do you imagine to test all of those?
I worked as a software tester back in 2010 when Android was a strange terminology to everyone. And you know, at that time we had around 150 different Android devices to test, with each person taking care of 2-5 devices. I do not blame OpenWrt developers because I understand that this is an volunteer project, but I just want to let you know that it is definitely possible in commercial projects.
In many (by far most) cases no one of the developers has ever seen these devices, as most device support is user contributed (just another device for a well-known SOC family).
This sounds more reasonable. I have some Chinese devices that I never expect any core OpenWrt developer to be able to see them.
Anyway, I just desoldered the MX25L6405DMI-12G flash chips from my bricked WRT320N, and hopefully can restore the firmware back. I don't keep a copy of the stock firmware, although I do keep a documentation of the partition layout. And the OpenWrt image seems to have 32KiB of header before the actual flashable data. It's time to do some experiment and try my luck. There is nothing to lose now.
What I actually want to ask is: are the image files tested by respective maintainer of the devices before each release? Or do they just submit a patch to support the devices, then vanish, leaving future OpenWrt releases with compatibility risks?
Yes and no I would say, but the good news is that the commercial network products are forgotten pretty much the same day as they are put on the market. And absolutely after 2years.
Maybe they get one or two firmware upgrades that never fix the actual problem people seem to experience.
No.
OpenWrt relies on feedback (both the bug reports and fixes) from its contributors, following the respective branches (openwrt-22.03, openwrt-21.02, master). There is no commitment for continued attention for contributed device support code, it's very welcome if the original authors keep an eye on it, but there are no "contractual obligations" to do so (how would you imagine that to happen in the first place, w.g. what happens if the device breaks, gets sold, passed on into production service; apart from having to bother about 3 active branches). Again, we're talking about a volunteer project with little to none financial resources, over 800 different different devices from over 15 years old up to brandnew, half a dozen completely different architectures (with multiple ISAs each) and almost 40 targets (plus several sub-targets). The buildbots are just churning out images, the more exotic (e.g. airohoa, malta, uml, etc.) or obsolete (bcm47xx, ath25, etc.) a target or device gets, the less testing it tends to receive (and I wouldn't be surprised if whole targets haven't gotten any attention in years at all[0]). It's an opensource- and volunteer project, if you care about something to work, you test and/or fix it, as necessary.
Are you sure that this is the right approach?
Most devices have easier/ better ways of recovery - and CFE implementations should at least allow manipulation via serial console (unless the vendor really locked it down hard), if not opening a http or tftp based method as well.
While out-of-band recovery with an spi-nor writer is always possible, it's usually regarded as a method of (very-) last resort, after all other options have been dismissed.
--
[0] well, someone will have to keep it compiling and updated/ rebased to the next LTS kernel, but in case of ath25 and some other obsolete targets, that might not even have been tested on the hardware.
I would say a new SoC family gets very much work done, Realtek switches is one of those and is now a pretty massive forum tread and there is still active driver development ongoing.
And for other families of SoC the big development has finished, then it is pretty much only upgraded if needed and if someone suddenly finds a bug like the switch bug in mvebu family recently then action is more or less taken. A device can also end up on the scrap heap if a big party pooper bug appears, there are no guarantees.
