Thanks for your research. Didn't know they updated the kernel. It would have been nice if they also published the sources for it. The latest source release as of now is 3.0.0.4.382.52274 which is based on kernel 3.3.8 (according to top-level kernel Makefile). Any chance you remember what version of the kernel was reported by uname in previous firmware releases? I would like to make sure they didn't just leave the old version numbers.
"Any chance you remember what version of the kernel was reported by uname in previous firmware releases?"
When I updated firmware have not interested in openWRT router firmware. So I did not use ssh.
I would not downgrade firmware, because I use the router.
Older firmwares can be downloaded here:
I'm a beginer in that field, so my next idea may be strange.
The openwrt-19-07-8 relase (OpenWrt 19.07.8 service release) use Linux kernel 4.14.241.
The newest Asus firmware use 4.4.60 kernel. Without kernel building, could we make openwrt-19-07-8 firmware image?
Or simpli we install openwrt by ssh?
tl;dr: In order to install an OS on a device you need to patch the kernel so that it has all the drivers required to boot and run the OS on this specific device. Neither the mainline linux kernel nor OpenWrt project have patches for the hardware used on this device.
Our work therefore looks like this:
Figure out which parts of code provided by ASUS are needed for this particular SoC;
Port these patches to mainline kernel;
Backport them to current kernel version used by OpenWrt if needed;
Build OpenWrt image with patches from (3) and test it;
Submit (2) and (3) to the community and work towards having them integrated into mainline.
Yes we will use the existing ath79 arch. But! Every single SoC (sometimes even specific board!) needs a little bit of code specific to this SoC / board.
However, your information regarding NETGEAR EX7300 (v2 to be precise) is very interesting. This board is indeed based on QCN5502 and the openwrt wiki page says that there's a pending PR for it. Not sure what "pending" means here and where it exists if there is one. Waiting for the page author's reply regarding this.
I have created a public git repository. Relevant tasks will be created as "issues". Make sure to read the project's main wiki page to understand which branch contains what. There's nothing of interest there at the moment - just mainline kernel code and code from ASUS firmware. I will be creating issues in the next few days. Anyone is welcome to read / comment / open merge requests / etc.
@Hsxsky here's my router's info as you requested (without dmesg since the forum doesn't allow very long messages):
bridge name bridge id STP enabled interfaces
br0 8000.a85e4547d7f8 yes vlan1
ath0
ath1
/sys/kernel/debug/gpio
GPIOs 0-19, ath79:
gpio-1 (sysfs ) in hi
gpio-4 (sysfs ) out hi
gpio-5 (sysfs ) out lo
gpio-15 (sysfs ) out lo
gpio-16 (sysfs ) out lo
gpio-17 (sysfs ) in hi
I have compared data. CPU is slightly different, and the ls /sys/devices/platform is totally different. Maybe different version of firmware. As I see, other parameters are same.
Please check "/tmp/home/root# uname -a" too.
As i see platform/target will be ath79
Subtarget: generic
Package architecture: mipsel_74kc or mips_24kc
I tried to figure out what parts of ASUS patches are required for the SoC to work. I tried removing things that seemed unnecessary, but this approach quickly made my device not boot.
I found a less error-prone way to remove irrelevant patches: by removing patches to files that aren't mentioned in the kernel compilation log. I tested the resulting image and it works fine.
Apparently there is a small patch that needs to be added for RT-AC59U v2, RT-AC57U v3, RT-AC58U v3 boards (they are identical). These are similar to the board discussed in this thread except with more flash memory.
Found out that there's a PR here which adds support for one QCN5502-based board. The patch is quite small.
Plans:
fix branches in my repository
there's code for boards that use device tree - investigate if it can be used for our board
remove patches for all the files that are not being compiled
finish writing device tree for the router
solder header pins to get access to UART
In order to use ASUS TFTP recovery without ASUS program for windows:
set a static IP to 192.168.1.10/24
turn off the device
hold and don't release the reset button
turn on the device while holding the reset button
wait until power LED is slowly blinking
release the reset button
send new image with atftp --put -l /path/to/image.trx 192.168.1.1 69
With the help of other developers, I've been able to build an OpenWrt image for my RT-AC57U v2. Switch and wireless don't work yet, but the CPU runs OpenWrt just fine. I have created a repository which is a mirror of OpenWrt with my patches in apjet01 branch. Choose Qualcomm Atheros APJET01 (16M) in Target Profile. Once you flash the image your device will loose connectivity and the only way to access it is by soldering a pin header to UART and using TTL-USB adapter. Only use this image if you have access to UART! You can return to stock firmware at any time via TFTP recovery though.
The device is not really useful at this point, but we've got so much closer...
All 5 ports are now working correctly. We've had support for LAN ports for a while in my repository, but I wanted to have the switch part finished before saying anything. Apparently there are more than 1 phy. There is phy at register 4 which I was using, but WAN port didn't work and it crashed when using VLANs (required to tell WAN from LAN) so it had limited functionality. Then recently @merlin discovered there's also a phy at register 0 which makes everything work if you provide PORT0_STATUS in qca,ar8327-initvals. Most recent commit fixes that. There is no distinction between LAN and WAN at the moment, I will fix this soon. USB support by @merlin is also on the way!
Note that this is my 3rd consecutive message so I will have to modify it instead of writing new ones.
Hi,
Thanks for your work.
Any ETA on when do you think we should be expecting to see fully functional openwrt images with support for RT-AC58U v2/v3?
I just got one recently and I was planning to use openwrt since the stock firmware does not support VLANs.
Thanks,
Roy
Hi! We're resuming our work after a bit of a break. The following is missing functionality as of now:
2.4 GHz Wi-Fi
5 GHz Wi-Fi
USB
As far as I know, it is possible to get USB and 5 GHz Wi-Fi working, but the patch for these features is not yet ready and we'll be preparing it soon. I will post an update here as soon as things become more clear.
As for 2.4 GHz Wi-Fi, it is not clear when we'll be able to support it. I think it would be helpful if you could ask the manufacturer for the source code of wireless drivers used in this model.
Hi! I'm tagging everyone who expressed interest in this work because I need your input. I will be making community (i.e. unofficial) builds for testing.
IMPORTANT: do NOT expect 2.4 GHz Wi-Fi anytime soon! Everything else, including 5 GHz Wi-Fi is expected to work after we integrate the remaining patches.
Please tell me if you're interested and also which packages / settings are important to you so that I know what to include in my builds.
We are a two-man team from Ukraine. In light of recent events, it is not clear if / when we'll be able to continue actively working on this project. We might loose internet access or get hit by a missile or have to evacuate leaving non-essential equipment behind. Therefore I decided to explain the current status of the patches. We're mostly fine at the moment, but will spend less time on this side-project due to more pressing concerns.
If you wish to work on this and need help getting started, reach out to me on this forum. If you already have patches to contribute, you can ask me for my email address or open a merge request in my gitlab repository.
If you have something to contribute and you message me in this topic and you don't get a response from us for 4 weeks, consider taking the code from the last commit in apjet01-rebase branch, adding whatever you have and submitting it to OpenWrt. Don't forget to change the signed-off lines according to this doc though.
MAC address from flash (MAC addresses will be random on each boot)
Branches
apjet01 contains tested code with true history of development
apjet01-dev is derived from apjet01, but includes untested patches
apjet01-rebase has the same code as apjet01-dev except all our commits
are squashed and rebased on top of upstream master branch. It has a
single commit with the message I am planning to use when submitting
the patch via email. This branch will be forced-pushed to, keep this in mind when doing git pull.
apjet01_usb contains a patch for USB support, needs to be rebased on
apjet01-dev and tested
How to install
The process is the same as building OpenWrt from source, except you clone our repository instead of official one with the branch you want: git clone https://gitlab.com:alexconst.sh/openwrt -b apjet01-rebase
In menuconfig you should select the following:
Target System: Atheros ATH79
Subtarget: Generic
Target Profile: Qualcomm Atheros APJET01
There are two variants of Target Profile depending on your device
Use 16M variant if you have these devices:
RT-AC57U v2
RT-AC58U v2
RT-AC59U v1
Use 32M variant if you have these devices:
RT-AC57U v3
RT-AC58U v3
RT-AC59U v2
Future plans
Apart from testing and integrating existing patches, I will be working on documentation and releasing images as promised. Just keep in mind that my ability to do so depends on how good my city's infrastructure will be in the coming weeks, which is very unpredictable.
