Awesome! I've always considered to host a collection of manually-built images somewhere, but updating this with every new version would be quite a hassle... Amazing how much of this can be automated by building directly on github, and even including all the factory encryption, backwards-compatible sysupgrade and even automatic plc firmware extraction Thanks @jwmullally and @jokujossai!
I wonder if sysupgrade-openwrt1806 could be flashed automatically by adding the device model to SUPPORTED_DEVICES += and incrementing compat-version, but I guess the latter would also affect all devices already running the new ath79 firmware... Also there's probably not much demand for that case
For the moment, the only thing I'd be missing would be a way for downstream projects (e.g. gluon) to use this, but we might as well throw the same patches to the gluon build dir, since binary compatibility is not so much of an issue there.
In the long term, I wonder if subtargets like ath79-generic etc. could become feeds one day, so that device support could come from unofficial sources, without requiring review by core system maintainers for every single newly-added device, yet allowing users to easily build and customize their images using the official repos.
Great! After its been tested enough, I think it would be OK to update the OpenWrt techdata wiki page to point to those images (as they are actively maintained, are open source and have clean patches mostly ready for upstreaming), and create a proper device wiki page.
The best way of course would be getting all the patches slowly upstreamed, but I understand some of the tools are tricky to include.
The Github repo README.md (or Github issues) could contain a section listing out each patch with summary and links to the upstreaming efforts, or explanation of why it cant be upstreamed. It will be the first question new users have.
Yeah something like that would be nice. The Imagebuilder isn't too far off that, it just needs to include the kernel instead of all the firmware images, and provide some extra high-level commands/hooks for building external images (DTB, firmware etc). To not break external images, it would need to be a documented unchanging interface. It might also require duplicate definitions for the Network, LED and Wifi firmware scripts, which the external image would have to maintain.
Right now OpenWrt does benefit heavily from all the devices definitions being in a monorepo side-by-side, e.g. slowly extracting out common functionality that comes from shared SoC designs and reference boards, bulk DTS changes can all be done together instead of updating seperate repos, and its easy to keep all images up to date. Similar to Linux kernel modules.
Upgrade files must be placed in /tmp and you can launch sysupgrade from /tmp. More information: Upgrading OpenWrt firmware using CLI. Sysupgrade process closes active SSH connections so just wait long enough for upgrade to finish after running command.
root@OpenWrt:~# /etc/init.d/plc setup
Downloading 'http://pmdap.dlink.com.tw/PMD/GetAgileFile?itemNumber=FIR1800225&fileName=COVRP2500A1_FW101b08_decrypted.bin&fileSize=1.5990457E7;1.5992229E7;65141.0;'
Failed to send request: Operation not permitted
Could not open COVRP2500A1_FW101b08_decrypted.bin, because No such file or directory
cp: can't stat 'squashfs-root/lib/plc/*': No such file or directory
rm: can't remove 'COVRP2500A1_FW101b08_decrypted.bin': No such file or directory
1) /etc/plc/COVRP2500*.pib
Select PibPath [1-1]:
Haven't tested yet, but awesome to see this upgraded, thanks @jokujossai!
Also great to know that there is an append-loader-okli-uimage recipe that can be used, making append-file redundant.
Updating should be possible without issues, there was not much change since the last release (except for the updated ath10k firmware maybe).
The migration to DSA will probably be within one of next releases, this might require some more testing then.
Finally I had time to debrick one of the two devices and test the new release.
Plc service was not working correctly and left bridge control script running on background after stopping service. Release v22.03.2-plcfix constains plc script fix and also adds /lib/upgrade/keep.d/plc file to preserve PLC firmware files on systemupgrade.
I am grateful for your efforts but that README is really confusing.
There's a very simple "OEM Web UI" section and after that a number of things some are marked with "not working" (so why is it there?) Are these necessary or are these optional? If optional maybe move them into an optional "RECOVERY.md" to be used only in case recovery is needed? Then under PLC there's an optional download step with "wget ???/QCA75XX-2.10.0.0032_modules_5-6_stripped.nvm" -- if it's optional why or why not would I want it and what are those question marks? Then we have "NOTE! plctool does not work with bridge" what does that mean? Is there functionality loss here? I mean, PLC in itself is not much useful if it can't talk to the other network ports.
Thanks @jwmullally and @jokujossai!
Thanks