Adding/Maintaining Support for RT-AX89X in Merlin (from One Dev to Another)

[Nick B]

Hello everyone,

This is about me adding support for RT-AX89X. It's primarily addressed to @RMerlin, but if anyone has specific technical details, feel free to jump in and assist in the answering with @RMerlin.

That being said, I just want to start with that I'm not just a user. I'm not asking for AX89X support be added, and maintained, by anyone but myself. I am highly experienced software developer of nearly 25 years, both by hobby and by occupation. I have a metric-ton of GNU/Linux experience under my belt, both in the desktop and embedded spaces.

I'm not asking the following lightly -- because of both my needs for a router and my current issues -- I am extremely motivated to use the information to begin to work on a practical solution and set the broad rule of, "Broadcom only" aside, at least in this one, very specific instance.


Originally posted by @RMerlin from the F.A.Q.:

Q: Will you add support for model XYZ?
A: The decision whether or not to support a new model depend on a long list of factors, which may evolve over time. Right now:

- It needs to be Broadcom-based
- It needs to be widely available (not just in two or three countries)
- It needs to have high-end hardware so I don't have to fight with lack of flash or RAM
- It needs to receive frequent enough GPLs so I won't have to regularly skip it due to the GPL being outdated
- I need to have one
- I need to have the time to try supporting it
- I need to have the motivation to try supporting it

Each new model requires its own dedicated support. That means every time I work on a new firmware release, I have to work on each separate model, and I need GPL releases from Asus for each individual model, and I need to merge each of them separately. So that means if I support 10 different routers, then I need to merge in the content of 10 different GPL releases, and these need to be close enough to one another to still be compatible. The more models I support, the harder this is to accomplish, therefore I am VERY conservative regarding adding any new model.

So don't ask if/when a new model will be supported. I cannot speculate about future model support, and until I have working support for a model, I cannot answer that question.

@RMerlin:
The biggest question of them all: what are the most immediate concerns with maintaining a Qualcomm-based router? Starting high level and drilling down into specifics as much as you feel you have time to do, please. Whether you have notes or not, any remembrances off the top of your head are appreciated. For example:

• Do you find that compiling the Qualcomm kernel and asuswrt sources are more problematic?
• Are there specific points of incompatibility that seem like a huge time sink, namely in maintenance?
• Does the Broadcom-only rule have something to do with the incompatibility between the 386.x and 388.x branch? (I don't know how you develop 388.x betas at all, and this router does not have any publicly posted non-production firmware like 388.x, but I'm assuming you blend them together from a 388.x released for one other router or generic, public source code repo.)
• Are certain router features (e.g. special CPU instruction sets like 'aes') present in Broadcom chips, but not in Qualcomm which make maintaining a Qualcomm version difficult (yes, the RT-AX89X has the 'aes' extension, was just an example)?
• Are there specific netfilter/iproute2 rules that are present on one, but not on the other, used as a workaround in the stock firmware release?
• Anything else...?
• Or... is this, "Broadcom only" rule simply something more of a legacy from old ASUSWRT Qualcomm GPL releases which had too many pain points of discrepancies between their Broadcom-equivalents at the time? From what it seems like to me based on building the recent ASUSWRT sources, there are very few discrepancies anymore, but I wasn't building entire images for flashing. (NON-DEVELOPERS / USERS: I'm not asking this from RMerlin in order to add merit to your request that your non-Broadcom router have support added. You need to understand that the issues are far more complicated than you can begin to fathom.)

General:

• Am I to understand that you own each and every single one of the models of routers listed on the ASUSWRT Merlin homepage? Or, for some, you simply verified their capabilities with other individuals before allowing it to become adopted by the official build processes / releases?
• Could you please qualify and quantify, "frequent enough GPLs" in regard to skipping releases? When do you draw the line, typically? 30 days? 90 days? Beyond that? (I assume that you know GPL sources for specific releases often go entirely unreleased due to severe vulnerabilities being discovered, such as in the case of the RT-AX89X's 386.47191, which is why I just want to be clear.)

Please, take all of the time you need to reply. I know that this post is from some random user sucking the time out of your life which you'd probably be using to spend with friends, family, or just to keep ASUSWRT-Merlin humming along normally -- I don't expect to be treated any differently. I'll have the system notify me if and when you reply.

Immense thanks,
--Nick Betcher

 

[RMerlin]

Supporting a Qualcomm platform means starting from zero. Having to familiarize yourself with the SDK, the APIs, rewriting the entire code that handles the Wireless Log display to use that API, rewriting any code that specifically interfaces with Broadcom-specific features to work with the Qualcomm platform. Porting/adapting/dropping Kernel-level patches that may or may not work with the kernel version used by the Qualcomm SDK. Possibly having to use a different iptables/iproute2 version, reapplying any changes and patches that may have been applied by me in the past for the Broadcom-specific versions.

I have never looked at the Qualcomm SDK at all, so I can't comment on how much effort or what issues may be encountered. All I know is that it requires starting from the beginning and reviewing every single features/enhancements currently present to determine if reapplying them is possible, and what is required to do so.

Basically, a LOT of work. And since I have never looked at it, I cannot quantify what is involved exactly.