As a stopgap while waiting for the addition of Archer A7 to release, I'm cobbling together the source for 18.06.2 for Archer C7 v5 to deal with the changed partitioning on the A7. I have been able to back port all the changes from
accept for the dts/dtsi info which from what I've read is new to 2019 builds. From what I can see the mtdparts in the dts file is included in the older target/linux/ar71xx/image/generic-tp-link.mk file but I'm not exactly sure I'm doing it right. I calculated that I need to replace:
Thanks for the reply. I get that I'm modding obsolete code but I just want to avoid the snapshot update issue. I don't see a release cycle for OpenWrt so I just want to hack together the mach files by comparing the info in the dts/dtsi until the snapshot becomes release.
I found a diff at https://gist.github.com/dword1511/b0ead3a1a8f3bfae35d710b4a17b4ce8 for adding Archer A7 to 18.06.2 but it looks like there are some problems and from my research, it seems that the partition info is incorrect. I think I really just need to confirm I'm on the right track as far as the partition info. I'm compiling now and will try to boot off it as I have a serial port connected so I can just try remote booting.
You can't avoid "the snapshot update issue" by building a modified image yourself, as the mach file addition for the a7 changes kernel configuration and ABI (thereby becoming incompatible with the real 18.06.2 by definition). And it really doesn't make any sense venturing this way, considering that the device is fully supported in master/ snapshots already.
Can you elaborate a little for me on this? Aren't the a7 changes merely modified formatting of the leds, buttons, magic numbers and firmware partition mapping? Most of the diff changes are adding A7 labels to C7 v5 entries. I followed the gist mentioned above and had to make a few changes to get it to compile as well as fix the partition mapping. I'm getting ready to try a remote boot. Won't the kernel be the same as the 18.06.2 for C7?
Replicating the exact same version hash of the kernel is tricky to begin with (possible, but tricky), but you are actively changing the ABI via mach-archer-a7-v5.c.
Ok. So, let's say it going to be several months before current Snapshot goes to release. What is best strategy for using Snapshot on a daly used router?
Best, in my opinion, build yourself off master. Need a new package? make menuconfig, add it, and build it yourself. Use ccache to speed build times. This is effectively what you'd be doing if you back-ported the changes to the 18.06 branch anyways. I can't remember the last time I used a "release" branch for my daily drivers.
Second best, take advantage of the pre-built snapshots and flash what you need all in one day.
The other option would be using imagebuilder, to build without actually compiling (disclaimer, I haven't use imagebuilder yet and just build from source myself).
That said, it's not forbidden to use the prebuilt snapshots as-is, adding the necessary packages at runtime - and replacing it with a newer one when the need arises (after all adding new functionality/ new packages shouldn't be a daily occurrence, once you set the basics up).
I usually find that I build two or three times in a day or two to get the packages I want into an image ("shoot, I forgot to add less"), then go for months or years without adding any new ones. Then again, I'm not running every executable that catches my fancy on my router, as I run my services on a separate host (where I, at least, believe they belong, not on a critical piece of infrastructure that is exposed to the Internet, wireless, and responsible for security).
The warning is ominous to make people think and not assume that it is "perfect" firmware and process – running on snapshots / master has been very smooth over the last few years. The process for adoption of patches to OpenWrt has become good enough that I can't remember a non-bootable build from unmodified OpenWrt sources over the last several years.
That said, knowing how to and being ready to recover from a bad flash is wise, even for those using "release" images. I've had a cat play with the power cord at an inopportune moment, causing the upgrade to fail half-way through.
I'm pretty comfortable now compiling snapshot and tftping, u-boot, serial, etc. messing with OpenWrt over the years but have never had a router running Snapshot. I was picturing the dreaded apt like dependency nightmare of days gone by leaving me with a router with some borked kmod and having to dig the router out of the corner and reattaching the serial interface to get back up and running with 2 hours lost after running an opkg upgrade.
The great thing about flashing a self-built image (past it being smaller) is that all the packages are self-consistent and current after you've updated your feeds.
Out of curiosity, what exactly is the "snapshot update issue"?
I've never had any issue updating any of my devices running self-compiled snapshot builds.
(except gl-ar300m NAND builds, but that's because sysupgrade support for that target is not yet complete and I haven't had time to work on fixing that issue)
Jeff's comment about baking in everything you need from the beginning in a self-built image is why I went straight there - Some of my use cases are on devices that have no direct connectivity with the outside world, so I can't just pull packages from a public archive.
