Note: A similar question has been asked before but I didn't see any movement on that thread.
As a purely educational exercise, I'm looking to migrate an older ar71xx device which was formerly supported but did not survive the transition to ath79. Specifically, the device I have in mind is the D-Link DIR-615 rev I1. Because it's a 4/32 device, I don't hold out any hope that anybody would seriously give consideration to accepting a pull request to re-integrate it into the official project. Nevertheless, my aim would be to bring it my work to the point that it would be of sufficient quality that it might be considered adequate if it weren't for the inherent weakness of the underlying hardware.
For a bit of background, I am very comfortable with tasks such as bare metal C coding and interpreting a Linux device tree source file. I suspect the biggest part that's missing is understanding where to look for the old ar71xx-era board-specific data (such as io pin assignment, U-Boot image packing method, etc) so that it can be translated into the correct new equivalent form.
I see that other devices built on the same SoC -- AR9341 -- are successfully building under ath79 in the current release, which gives me some hope that many of the building blocks I will need might already exist, but the hard work will mostly be focused on putting them together in the right order.
Examining the old 19.07 sources, I have made it as far as identifying that the legacy build was based on a "CameoAP123_4M" template, and from that same makefile file I have an idea about stock OS mtd layout. But I am at a standstill taking things any further.
I would very much appreciate any advice to help me advance my work!
While your proposed efforts are appreciated, there is no way that any official support would could be revived for low flash/ram devices.
The current requirement of 8/64 is just barely sufficient, and the next major release will drop this in favor of 16/128.
It is the kernel itself that is largely responsible for increased resource requirements. And the kernel comes from upstream -- it's not like the OpenWrt project is artificially inflating the kernel.
There are community 'tiny' builds that are not "official" but provide recipies to fit more recent versions into older hardware. For example, see this one. However, those assume that the platform target includes the devices in question... your device was not moved from ar71xx > ath79, so there would be quite a lot of work to try to get it running, as this target shift was significant in nature and happened many years ago now (I can't answer why that specific device wasn't transitionted -- maybe the 4/32 size, or maybe some other issue came up).
As an academic exercise, there's certainly no harm in trying, but you're unlikely to get much, if any help with the development, and the work you'd put into this effort would only have the educational value and/or in the cummunity builds section insofar as it wouldn't be integrated into any more recent official builds. All versions pre 23.05 are now EOL and unsupported -- no backporting of devices (or anything else) will happen on any official build. But, if you are able to successfully build for your device on ath79, you'll certainly have learned some serious tricks in coding efficiency.
Therefore:
For your own educational purposes, sure, go ahead and try... but...
Don't expect any help since no currently supported build could fit, meaning you'll be working with unsupported/EOL builds. Further, it is not recommended to use unsupported/EOL builds due to security vulnerabilities which will never be patched.
Even those volunteers that may be willing to help may not remember the nuances of the older versions and the ar71xx > ath79 transition, so any help may or may not be fruitful.
Your work on such an old device would have benefit only to you and your specific device and unofficially within the community builds.
IMO, it's not worth the effort, but I recognize this may be more about learning than practicality... thus:
it doesn't necessarily mean it isn't worth doing for fun/education, but I think most people would recommend putting that effort into adding support for a new, more capable device so that it can be of more universal appeal and move the OpenWrt project further in terms of supported devices or even better new target architectures.
Yes, I have heard of it. I started with DD-WRT a few years ago with this device's sibling, another DIR-615, that one rev E3.
I have come to prefer virtually every aspect of OpenWRT over its counterpart in DD-WRT:
the source code arrangement (I still can't locate DD-WRT's counterpart to OpenWRT's /target subdirectory for abstracting the different supported machines)
the ease of setting up a build system (DD-WRT's documentation, such as it is, seems to boast about how difficult it is to get a build to actually compile)
the evidence of peer review (from what I can tell, only one single person is responsible for every single commit on DD-WRT's subversion repository)
the branching model (new features and stability/security fixes seem to be all jumbled together into a single linear progression; the general tone on the forums gives the impression that it's a total crapshoot whether any successive build will actually boot on any given target)
Don't get me wrong, I am sure that DD-WRT serves a legitimate purpose. For example, having been willing to enter into a proprietary licensing deal with Broadcom, it would make them the natural choice if you are saddled with hardware that cannot work using the limited open source support that exists for their chipsets.
But if there is any other alternative, I would choose the alternative in preference to DD-WRT.
I absolutely did not expect official support, so that doesn't come as a surprise.
I am aware of the community builds targeting the "tiny" targets. In fact, I already generate a few 4/32 builds for my own personal use. I have different priorities than those listed in that thread.
For example, I have a few EX2700's operating as 23.05 WDS extenders -- for which I have made a tradeoff of features to effectively extend the useful life of these devices (tuning the kernel for 1MB squashfs block size and a 1-block cache; no NAT; no firewall; no dnsmasq; no optional netfilter kernel modules at all; no userspace IPv6 ohcpd utilities since they'd all be forwarded from the host router anway and so it's irrelavent in any WDS-based extender; addition of zram-swap; no opkg; sysupgrade still enabled though; addition of wpad-basic-mbedtls; enabling 4kiB SPI-NOR sectors; including the essential aspects of luci-ssl just because I happened to have enough space left in the image to fit it).
I also have another DIR-615, this one rev E3, for which I have found a different 23.05 tradeoff to be useful (also tuning the kernel for 1MB squashfs block size and a 1-block cache, enabling NAT, enabling firewall, enabling dnsmasq; enabling only the necessary netfilter modules; omitting all the IPv6 userspace utilities since my ISP doesn't give my an IPv6 connection anyway; also no opkg, but working sysupgrade; enabling the swap subsystem in the kernel and the zram-swap utility; hostapd-basic-mbedtls, and omitting luci).
From what I've been able to gather so far, the DIR-615 rev I1 partition layout actually frees up an additional 100 kiB or so, compared with the E3 I've already been working with, so that raised my hope that I could similarly extend its life and save it from the landfill for at least another year or so.
It is likely that there will be at least a brief period where 23.05 will continue to receive security patches after the next major release, which is why I am trying to be careful not to say anything about the longevity of any of these devices after 23.05 finally does go EOL. (I note that 22.03's final security patch was just released a few weeks ago.)
Well to answer your original question - you don't really want to 'migrate' anything - treat this as porting the device from scratch.
Pick an existing ath79 device that is very close in hardware, boot the initramfs from that device and then start modifying the DTS to match your device. Once your modified DTS supports all hardware and the partition table is correctly configured try and sysupgrade from your working initramfs.
Be ready with a recovery method in case of failure and make sure all existing partitions are backed up. Don't overwrite the bootloader or calibration data or your may be bricked.
I have done the math for a 4/32 device I owned in February, and the figures didn't look good.
As mentioned there, it is possible to make even harder decisions (and to drop even more), but that was the limit I was going to compromise on, because the system would have become useless (I still wanted it to remain a sensible router/ AP, even if all the convenience (luci) was already gone) to me beyond that point (and the efforts required already exceeded its remaining value). In your case, you'd even have to do the initial porting to ath79, which -while certainly possible- will add yet another layer of complexity. Keep in mind that 32 MB RAM is as much of a problem here, as the limited flash size.
If you still want to take it head on, I would suggest to replace the 4 MB flash chip with a compatible 8 MB model first, as this would make your task easier - while doing so would complicate getting the support merged into OpenWrt, as OpenWrt doesn't take patches for one-off, user-modified devices, that question is out of the question for 4/32 devices at this point anyways. But the ~1-2 bucks for the new flash chip and the 'half an hour' worth of soldering would make your endeavour much easier (and you will need serial console access for this kind of porting anyways).
Don't get me wrong, I won't recommend the above - but it's at least a more reasonable way forward that trying to squeeze modern OpenWrt into 4 MB flash (but yes, 32 MB RAM will also become a serious issue once you start up the wireless interfaces, maybe even before that).
From an economic point of view you could get much better (plenty of flash & RAM, 802.11ac/ ax wireless) devices both on your local used markets or even new from a seller for very little money (decent used gear starting in the 5-15 EUR range if you're lucky - brandnew 802.11ax stuff starting around 15 EUR (mt7621a+mt7915DBDC, e.g. dap-x1860, covr-x1860, wsm20) to ~30 EUR (filogic 820, e.g. ax3000t). That is considerably cheaper than buying:
soldering iron (e.g. Miniware TS101, starting around 40 EUR in a sale)
2-4 EUR for the new 8 MB spi-nor chip itself (don't go higher than this, you only get into trouble with the 32 MB RAM while flashing and may have to fight against bootloader/ PCB issues)
From a practical point of view, >=802.11ac brings a massive improvement over 802.11n device, you get
1 GBit/s ethernet
2.4+5 GHz concurrent dual-band support
200-350 MBit/s wireless throughput (over 5 GHz)
and 802.11ax pushes this to 600-750 MBit/s over the air
more flash/ RAM
more CPU performance
so even without the flash/ RAM constraints, replacing 802.11n devices with something newer really does make sense on merits alone. Keep in mind that the airwaves are a shared medium, so your 802.11n keeps the channel (actually three channels at once) busy, while transmitting at slow speeds, preventing all faster gear in the vicinity to transfer this amount of traffic in much shorter time.
If it comes to it, I have replacement SPI flash chips in hand already -- I was anticipating the need for such surgery at some point for the 615 rev E3 unit, which I have verified to have a compatible SPI command set.
(Off-topic here, but I am also gearing up to upgrade the E3 unit's RAM chip too, but I need more refinement of my soldering skills before I take on that project. I have already concluded that for the I1 unit, even if a RAM upgrade might be possible, I would be on untested ground; I might need to identify a different replacement part, and there would be no guarantee that its bootloader was compiled to automatically identify it. On a professional basis, I am already well aware of "evil vendor" ports of U-Boot that use hard-coded RAM size rather than employing upstream U-Boot's documented way of scanning for RAM capacity.)
Similarly, a 3.3v tolerant serial console will not be a problem.
The shared medium argument is rather persuasive. Although my circumstances don't really justify purchasing new equipment (my internet connection speed is already slower than what 802.11n delivers) that doesn't take into account the fact that I need to peacefully coexist with neighbors whose needs may be different.
I can understand your hesitation about DDWRT but still these older 4MB targets are supported, some even have WireGuard, it might be even available for your router: https://svn.dd-wrt.com/changeset/51596
I have/administer a host of Broadcom Northstar routers (the ones with 128 MB/flash and 256 MB RAM) and DDWRT runs well, with the Broadcom proprietary Hardware offload (CTF) they can do 800+ LAN<>WAN
Self Compiling for those Broadcom targets is possible, I am dong it as we speak
