[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Checkout a tagged release’s source code (like v21.02.0)

Advice to NOT checkout the tagged release:
For most users it is usually better to compile from the HEAD of the release branch instead of compiling the exact release like 21.02.0
Checking out the exact release locks also the feeds (packages, LuCI etc..) to the commits at the release moment. Later fixes made to LuCI and other packages will not get compiled into the firmware. Similarly fixes made later to the 21.02 branch main OpenWrt sources do not get included. (see the locked feeds at https://github.com/openwrt/openwrt/commit/b2ae4233149dfd78f2ac00bb5327695bcacdc255 )
When compiling from the release branch HEAD, the later fixes into the main 21.02 OpenWrt source and into the package feeds get included in the build. To achieve that, do not checkout the release tag "v21.02.0" but checkout the branch "openwrt-21.02":
git checkout openwrt-21.02
Old advice for checking out the tagged release:
I am sure that sooner or later there will be a flood of questions how to checkout the exact release source code for a tagged release (like 17.01.0-rc1), so this is a short guide:
You need to have already cloned the LEDE source repo in advance with
git clone https://git.lede-project.org/source.git
Then you only fetch the tags and checkout the correct one:
git fetch --tags
git checkout v17.01.0-rc1
Example workflow how to fetch v17.01.0-rc1 source:
perus@ub1610:/r7800-lede1701$ git fetch --tags
remote: Counting objects: 19, done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 19 (delta 13), reused 0 (delta 0)
Unpacking objects: 100% (19/19), done.
From https://git.lede-project.org/source
   31b0640906..e038c60049  lede-17.01   -> origin/lede-17.01
 * [new tag]               v17.01.0-rc1 -> v17.01.0-rc1

perus@ub1610:/r7800-lede1701$ git tag -l
reboot
v17.01.0-rc1

perus@ub1610:/r7800-lede1701$ git checkout v17.01.0-rc1
A files/etc/Compile_info.txt
A files/etc/applyHNsettings.sh
...
M target/linux/ipq806x/base-files/etc/board.d/01_leds
Note: checking out 'v17.01.0-rc1'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 68a04dbb42... LEDE v17.01.0-rc1: adjust config defaults
Below is verification that the main source code is at the release tag and that all feeds point to a specific commit instead of the moving HEAD of the respective lede-17.01 branch in that feed:
perus@ub1610:/r7800-lede1701$ git log --oneline | head -n 5
68a04dbb42 LEDE v17.01.0-rc1: adjust config defaults
ec095b5bf3 ledtrig-netdev: don't cancel work on events for different interfaces
b8fcbbf31d kmod-sched-core: Add HTB and TBF traffic shapers
70a6bbd53d ar71xx: prepare jffs2 partition properly in factory.bin for BHR-4GRV2
f5e8c908bd mxs: remove stale references to obsolete kernel module packages

perus@ub1610:/r7800-lede1701$ cat feeds.conf.default
src-git packages https://git.lede-project.org/feed/packages.git^31d89be9e69bac261bfe7440512cb4e0f3356255
src-git luci https://git.lede-project.org/project/luci.git^472dc4b9e2ca71c114f5da70cb612c1089b8daa7
src-git routing https://git.lede-project.org/feed/routing.git^a6c7413594a0e4b42dab42bb5fa68534e39b7d0c
src-git telephony https://git.lede-project.org/feed/telephony.git^1f0fb2538ba6fc306198fe2a9a4b976d63adb304

8

[Assistant]
EDIT:
This advice mainly concern only 17.01.0-rc1, as the tagging script has been modified for rc2 to create and include version.date and version files in the archive. Those will set the correct date and git version. (but will also prevent recognising possible later git commits, as they override the git versioning.)
Note that if you did not use git, but download the release sources as an archive file from Github, some of the version info does not get set and some packages may fail to compile to due to missing date/time reference:
Easy fix:
Run this command in the build root directory to create the timestamp file "version.date" there:
date +%s > version.date
Developers will likely fix this for the next releases, so the fix is likely needed only for rc1.
Explanation:
The Makefile logic (in include/toplevel.mk and scripts/get_source_date_epoch.sh) expects to get a value value from git for the revision and hash as well as SOURCE_DATE_EPOCH, but if you are not in a git repo, those will be left unset. And that then triggers the error in those packages that use the SOURCE_DATE_EPOCH variable without verifying that it is set properly.
I tested myself and both getver.sh and get_source_date_epoch.sh fail to provide a version/time reference when sources from archive are used:
$ wget https://github.com/lede-project/source/archive/v17.01.0-rc1.tar.gz
$ tar -xvf v17.01.0-rc1.tar.gz
$ cd source-17.01.0-rc1/
$ ./scripts/getver.sh
unknown
$ ./scripts/get_source_date_epoch.sh
      <-- empty result
@jow

I wonder if the tag commit should also include a "version.date" file for scripts/get_source_date_epoch.sh and possibly a "version" file for scripts/getver.sh as a fallback. The build system rather bluntly assumes that sources have been got via git, but that may not be true. I think that build000 already ran into this issue as he wrote two packages bugs about the failures.

2 Replies
2

@hnyman
- will look into providing fallbacks for the epoch date asap

have compile issue:
wget https://github.com/lede-project/source/archive/v17.01.0-rc1.tar.gz
tar -xvf v17.01.0-rc1.tar.gz
cd source-17.01.0-rc1/
scripts/feed update -a
scripts/feed install -a
make defconfig
make prereq
make menuconfig
Target System (Lantiq)
Subtarget (XRX200)
Target Profile (o2 Box 6431 / Arcadyan VGV7510KW22 (NOR))
Base system -> block-mount
sqm-scripts
Firmware -> dsl-vrx200-firmware-xdsl-a-patch
dsl-vrx200-firmware-xdsl-b
Kernel modules -> Filesystems -> kmod-fs-ext4
USB Support -> kmod-usb-storage
Languages -> Perl -> Perl
-> perl-html-tree
-> perl-http-message
LuCI -> Collections -> luci
-> Applications -> luci-app-sqm
Mail -> mailsend
Network -> Telephony -> asterisk13
asterisk13-app-directed_pickup
asterisk13-app-read
asterisk13-app-stack
asterisk13-app-system
asterisk13-cdr
asterisk13-cdr-csv
asterisk13-chan-sip
asterisk13-codec-a-mu
asterisk13-codec-alaw
asterisk13-codec-g722
asterisk13-codec-g726
asterisk13-codec-gsm
asterisk13-codec-ilbc
asterisk13-codec-resample
asterisk13-codec-ulaw
asterisk13-format-gsm
asterisk13-format-sln
asterisk13-func-blacklist
asterisk13-func-groupcount
asterisk13-pbx-spool
asterisk13-res-musiconhold
make
...
make[3] -C toolchain/musl prepare
make[3] -C toolchain/musl compile
make[3] -C toolchain/musl install
make[3] -C toolchain/gcc/final prepare
make[3] -C toolchain/gcc/final compile
make -r world: build failed. Please re-run make with -j1 V=s to see what's going on
make: *** [/home/dennis/Downloads/source-17.01.0-rc1/include/toplevel.mk:199: world] Fehler 1
make -j1 V=s
...
hain-mips_24kc_gcc-5.4.0_musl-1.1.15/gcc-5.4.0/missing makeinfo --split-size=5000000 --split-size=5000000" 'AR=ar' 'AS=as' 'CC=x86_64-pc-linux-gnu-gcc' 'CXX=x86_64-pc-linux-gnu-g++' 'DLLTOOL=dlltool' 'GCJ=' 'GFORTRAN=' 'GOC=' 'LD=ld' 'LIPO=lipo' 'NM=nm' 'OBJDUMP=objdump' 'RANLIB=ranlib' 'READELF=readelf' 'STRIP=strip' 'WINDRES=windres' 'WINDMC=windmc' LDFLAGS="${LDFLAGS}" HOST_LIBS="${HOST_LIBS}" "GCC_FOR_TARGET= $r/./gcc/xgcc -B$r/./gcc/" "echo 'STMP_FIXPROTO=' | sed -e s'/[^=][^=]*=$/XFOO=/'" "echo 'LIMITS_H_TEST=' | sed -e s'/[^=][^=]*=$/XFOO=/'" all
make[5]: *** [Makefile:4118: all-gcc] Error 139
make[5]: Leaving directory '/home/dennis/Downloads/source-17.01.0-rc1/build_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.15/gcc-5.4.0-final'
make[4]: *** [Makefile:874: all] Error 2
make[4]: Leaving directory '/home/dennis/Downloads/source-17.01.0-rc1/build_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.15/gcc-5.4.0-final'
make[3]: *** [Makefile:88: /home/dennis/Downloads/source-17.01.0-rc1/build_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.15/gcc-5.4.0-final/.built] Error 2
make[3]: Leaving directory '/home/dennis/Downloads/source-17.01.0-rc1/toolchain/gcc/final'
make[2]: *** [toolchain/Makefile:92: toolchain/gcc/final/compile] Error 2
make[2]: Leaving directory '/home/dennis/Downloads/source-17.01.0-rc1'
make[1]: *** [toolchain/Makefile:89: /home/dennis/Downloads/source-17.01.0-rc1/staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.15/stamp/.toolchain_install] Error 2
make[1]: Leaving directory '/home/dennis/Downloads/source-17.01.0-rc1'
make: *** [/home/dennis/Downloads/source-17.01.0-rc1/include/toplevel.mk:199: world] Fehler 2
See the .config file: https://www.file-upload.net/download-12292118/config.zip.html


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Hardware NAT For LEDE

I have been trying to port QCA Hardware NAT over to stock LEDE.
This is from Code Aurora Repo
After some monkey patching the compile works and I got the binaries.
You can try it at my repo, targeting WDR4300
GitHub
gwlim/mips74k-ar71xx-lede-patch
Patchset for MIPS74Kc AR71xx For LEDE Project. Contribute to gwlim/mips74k-ar71xx-lede-patch development by creating an account on GitHub.

To compile select the Hardware NAT Module in Kernel Modules and the SSDK Shell in utilities
Unfortunately I got the following errors while loading the kmod
Anyone can make head and tails off it?
[ 126.429985] qca_ssdk: Unknown symbol ppp_hold_channels (err 0)
[ 126.436355] qca_ssdk: Unknown symbol ppp_release_channels (err 0)
[ 126.442761] qca_ssdk: Unknown symbol f1_phy_init (err 0)
[ 126.448378] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0)
[ 126.455151] qca_ssdk: Unknown symbol ppp_is_multilink (err 0)
Thanks

2 Replies
4

[Assistant]
gwlim:
I have been trying to port QCA Hardware NAT over to stock LEDE
Not familiar with this error but just wanted to say this is awesome. I use your performance orientated builds for my WDR3600 <3
EDIT: Removed unrelevant links

I look at the source, it seems that their ppp driver isn't mainline, it has some special functions that QSDK Hardware NAT uses, looks like some patching is needed.

ppp_hold_channels and other ppp_*** functions
github.com
paul-chambers/netgear-r7800/blob/eeac2e10190f6f45e32e4c7012c4babc351898d8/git_home/linux.git/sourcecode/drivers/net/ppp/ppp_generic.c
/*
 * Generic PPP layer for Linux.
 *
 * Copyright 1999-2002 Paul Mackerras.
 * Copyright (c) 2013-2015 The Linux Foundation. All rights reserved.
 *
 *  This program is free software; you can redistribute it and/or
 *  modify it under the terms of the GNU General Public License
 *  as published by the Free Software Foundation; either version
 *  2 of the License, or (at your option) any later version.
 *
 * The generic PPP layer handles the PPP network interfaces, the
 * /dev/ppp device, packet and VJ compression, and multilink.
 * It talks to PPP `channels' via the interface defined in
 * include/linux/ppp_channel.h.  Channels provide the basic means for
 * sending and receiving PPP frames on some kind of communications
 * channel.
 *
 * Part of the code in this driver was inspired by the old async-only
 * PPP driver, written by Michael Callahan and Al Longyear, and
This file has been truncated. show original


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Raspberry Pi Managed Switch Project

Hi,
I created an open source 4-port managed switch based on a Raspberry Pi with OpenWrt support.
Hardware: https://github.com/AlbrechtL/rpi-managed-switch-4-port
Software (OpenWrt): https://github.com/AlbrechtL/rpi-managed-switch-openwrt/tree/rpi_managed_switch
I would like to share this project to the OpenWrt community to collect feedback.
Is such a project interesting to the OpenWrt community?
I'm using the RTL8367S switch chip. The rtl8365mb DSA driver has no hardware offloading and VLAN support . But the old rtl8367b swconfig driver supports it. Are they any plans to migrate all rtl8367b features to rtl8365mb? Or did I miss something?
Feel free to write any feedback to me .
BTW: Here are my OpenWrt changes: https://github.com/openwrt/openwrt/compare/main...AlbrechtL:rpi-managed-switch-openwrt:rpi_managed_switch

12

[Assistant]
As you described, still lots of parts missing for DSA support.

2

Generally speaking, this is a cool project. Thanks for sharing it.
From a practical perspective, though (and this is my opinion only, I can't speak for others), I feel that the device is not all that useful unless it is considerably cheaper (compete cost) than a basic 5-port L2 managed switch. That's pretty hard to achieve, though -- you can get entry level 5 port managed switches in the range of $25-$30 USD. My thinking is that this won't be able to offer much (if anything) more that a commercially available switch can provide, except maybe the fact that you developed it with OpenWrt in mind.

1

I have no idea how hard it would be, but if you were able to do 2.5G rather than gigabyte speed, that could make it a lore more interesting with regards to what
@psherman
was saying

2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Help prioritizing games with alternative qdisc design

Hello i play first person shooter games in console ps4. A friend uses fresh tomato firmware and this qos works perfect for this games.
It uses sfq with 2 classes only and only 2 rules...
One with udp protocol and transferred 256kb
And one more with tcp and udp transferred 256kb+...thats it.
Can we create a script to do the same thing in Openwrt?

1 Reply
4

[Assistant]
Hi
@knomax
, you sent me some personal messages, thanks for posting this publicly.
I have some ideas how we can get a very similar result, maybe even with a better rule than this one, I will think about it a little and try to put something together. I'm thinking perhaps a TBF to get the rate right, and then a simple drr with two classes, one for games and one for everything else (DRR is similar to SFQ but offers a little more control).

2 Replies
2

Thanks
@dlakelan
i think and other call of duty gamers are interested in that... Waiting for testings.

1

TBF for rates....256kb and 256+kb?DRR for classification?


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Netgear R7800 exploration (IPQ8065, QCA9984)

After looking for a new device in Next router? ath10k or mwlwifi based? something else? thread, I decided on Netgear R7800. I started exploring the new device a week ago and wrote my first comments to that thread, but it is probably better to have a new device-specific thread.
Netgear R7800 is a dual-core 1,7 GHz AC2600 router based on IPQ8065 SoC and QCA9984 wifi. (iox806x target and arm_cortex-a15_neon-vfpv4 packages in LEDE)
Some notes on the current support in OpenWrt (updated in Aug 2018, valid in Apr 2020):
Most normal functionalities are ok:
Flashing via OEM GUI works (questionable, you might need TFTP)
Sysupgrade works
USB ports work
LEDs work, also ath10k wifi LEDs in 18.06 and master
CPU frequency scaling works. Both cores scale independently between 384 - 1700 MHz according to CPU load.
Software NAT flow offloading with kernel 4.14 (master, 18.06)
Note: eth0 and eth1 are swapped compared to earlier Openwrt practice, so SQM etc. configs need checking.
What does not work / work in progress:
Hardware NAT (and hardware offloading)
Native qca8k hardware switchdriver. Work in progress (by blogic)
Note that all network (eth0, eth1, wlan0, wlan1) IRQs are assigned to core0 by default. With gigabit-style connections, performance benefits be obtained by distributing the IRQs more evenly to also core1. See also irqbalance
EDIT: May 2018
kernel 4.14 in master and 18.06 branches
Kernel 4.14 requires a larger flash space for kernel than earlier. Due to this, TFTP flashing is needed once when you move into kernel 4.14 based firmwares. Sysupgrade works normally after that. TFTP flashing needs to be used to move between these two groups:
kernel 4.4 or 4.9: 17.01, old master builds (<r7000), plus the quite earliest 18.06 builds
kernel 4.14: new master builds (>r7000), new 18.06 builds
You need TFTP flash once here, if you upgrade/downgrade from one group to the other group. Sysupgrade works normally inside each of those groups.
R7800 has a TFTP recovery mode in the u-boot bootloader.
Details at message 5 of this thread: Netgear R7800 exploration (IPQ8065, QCA9984)

3 Replies
11

[Assistant]
Advice on opening Netgear R7800 case and using the serial console
The case bottom and cover are attached to each other pretty tightly, but the case can be opened once you figure out all necessary steps:
The circuitboard is attached to a heatsink that is attached to the top cover. So the bottom panel (with sides) is the one to separate from the others. The heatsink is likely attached with a thermal paste or such (I never removed it).
There are five screws (Torx T-10) on the bottom that need to be opened. One screw is visible and four are hidden inside the rubber feet (which are attached with adhesive tape)
There are small clips on sides keeping the top cover tight even when the screws have been opened. These clips need to be carefully pronged open with a flat screwdriver or something.
Additionally, there are fangs in the vertical backpanel protecting the connectors' holes (by preventing vertical lifting). In practice the front side can be lifted up first and the backside last by pulling forward so that the connectors slide free from the backpanel holes.
The serial header is right at the edge of the circuitboard, so it can be accessed even while the cover is attached to the circuitboard. I bended sideways the three needed pins (ground, rx, tx) that are luckily nearest to the circuitboard's edge, so that I could easily attach the serial cable. I left the farthest +3.3V pin untouched.
Using the markings in my USB-ttl converter, the pin order starting from the circuitboard's edge is: ground, rx, tx, +3.3V
Serial connection is the usual 115200,8,N,1
(The serial header can be seen through the left ventilation grill, so it might be possible to get access to it without by opening the case, by cutting a hole to the ventilation grill on the side panel.)
Bootlog starting with u-boot bootloader looks like this (LEDE master r3676-edda26dc4f):
https://gist.github.com/hnyman/8a68f6280ef5d267bba2ee80601fe8f0
EDIT:
I led the wire through side grill so that I access the serial header even when the cover is closed:

1 Reply
7

I got a nice suggestion from tohojo at the SQM scripts development repo, where I opened an issue about this. It may actually be how the HTB (hierarchical token bucket) qdisc perfoms on this CPU...
github.com/tohojo/sqm-scripts
ipq806x / Netgear R7800: difference in download speeds with cake and simple/fq_codel (possibly due to HTB )
opened
Nov 16, 2016
closed
Jan 30, 2017
hnyman
I have a new router Netgear R7800 that is an 1,7 GHz dual-core IPQ8065 device. I…
Well in that case it sounds like it has something to do with the way HTB runs on that CPU. You could try if TBF has the same behaviour; enable sqm, then issue the following commands to replace the configured qdiscs with a TBF-based one (provided TBF is in LEDE; not sure if it is):
tc qdisc del dev eth0 root
tc qdisc del dev ifb4eth0 root
tc qdisc add dev eth0 handle 1: root tbf rate 8Mbit burst 15140 latency 100ms
tc qdisc add dev ifb4eth0 handle 1: root tbf rate 90Mbit burst 15140 latency 100ms
tc qdisc add dev eth0 handle 2: parent 1:1 fq_codel
tc qdisc add dev ifb4eth0 handle 2: parent 1:1 fq_codel
I tested that suggestion and did a quick and dirty Ookla speedtest and the resulting change is impressive:
simple with original HTB: 77 / 7 Mbit/s
simple with TBF (above): 85 / 8 Mbit/s
So, an immediate jump of 8 Mbit/s in the download speed and now the throughput is much closer to the set limit of 90 / 8. HTB might be culprit (but what is the ultimate reason for the bad performance, no idea, yet)

1

After realising that the HTB qdisc is part of the problem for R7800 I looked into the original sources of HTB at Linux upstream and noticed that there are a bunch of performance patches that have been implemented in Linux stable after 4.4 that we use here.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/net/sched/sch_htb.c?h=linux-4.8.y
Everything after Feb2016 is not in 4.4, about 10 commits in total. I looked at the commit list and one patch especially looks interesting as it promises to fix a major performance issue in dual-core processors (like ipq8065 in R7800).
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.8.y&id=a9efad8b24bd22616f6c749a6c029957dc76542b
I found a serious performance bug in packet schedulers using hrtimers. sch_htb and sch_fq are definitely impacted by this problem. ... This issue is particularly visible when multiple cpus can queue/dequeue packets on the same qdisc, as hrtimer code has to lock a remote base.
I compiled a firmware with that patch backported to 4.4, and SQM simple's download throughput improved by 1.5-2.0 Mbit/s. So, a partial fix, but not yet perfect.
I will look also into the other htb patches, but good to know that at least a partial reason has been found.

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: [Tutorial] Build OpenWrt with Multipath TCP

This tutorial explains building OpenWrt images with out-of-tree MPTCP (MPTCPv0 & MPTCPv1) support.
Disclaimer: We can no longer use out-of-tree MPTCP on OpenWrt 22.03 and newer since upstream MPTCP (supports only MPTCPv1) is included instead. I will write a tutorial for building OpenWrt with upstream MPTCP in the future.
There are a few reasons to build your own image to use MPTCP instead of using solutions like OpenMPTCPRouter:
Only a few devices are supported.
Firmware is heavily bloated, making it impossible to run the image for devices with small flash.
Official out-of-tree MPTCP patches won't work with the kernel used on OpenWrt
Official out-of-tree MPTCP patches only support minor releases of the Linux kernel (starting with 4.9). OpenWrt uses patch releases of the Linux kernel.
Because of this reason, you can't use the patches from the official website.
http://multipath-tcp.org/patches/
Wikipedia page explaining major, minor and patch versions.
I maintain my own patches for patch versions of the Linux kernel by diff'ing the official out-of-tree MPTCP branch against the upstream kernel it’s based off of, here:
github.com
GitHub - arinc9/openwrt at openwrt-21.02-mptcpv0
openwrt-21.02-mptcpv0
This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins or for reporting issues. We will continue to accept Pull Request...
github.com
GitHub - arinc9/openwrt at openwrt-19.07-mptcpv0
openwrt-19.07-mptcpv0
This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins or for reporting issues. We will continue to accept Pull Request...
Building the image
For OpenWrt 21.02
Clone the repository and checkout the commit
git clone https://git.openwrt.org/openwrt/openwrt.git && \
cd openwrt && \
git checkout v21.02.2
Download the patch to target/linux/generic/hack-5.4
curl -L 'https://github.com/arinc9/openwrt/raw/openwrt-21.02-mptcpv0/target/linux/generic/hack-5.4/999-mptcp_v0.96.patch' -o target/linux/generic/hack-5.4/999-mptcp_v0.96.patch
For OpenWrt 19.07
Clone the repository and checkout the commit
git clone https://git.openwrt.org/openwrt/openwrt.git && \
cd openwrt && \
git checkout v19.07.9
Download the patch to target/linux/generic/hack-4.14
curl -L 'https://github.com/arinc9/openwrt/raw/openwrt-19.07-mptcpv0/target/linux/generic/hack-4.14/999-mptcp_v0.94.patch' -o target/linux/generic/hack-4.14/999-mptcp_v0.94.patch
Disclaimer: 19.07 uses kernel 4.14 which MPTCP v0.94 is used instead. MPTCP v0.94 does not support MPTCPv1.
  Update feeds and configure menuconfig
./scripts/feeds clean && ./scripts/feeds update -a && ./scripts/feeds install -a && make menuconfig -j$(nproc)
Configure the device model and enable luci at LuCI -> Collections by pressing "y".
Test the patches to see if they apply
make target/linux/{clean,prepare} V=s
Configure kernel menuconfig, this will take a while
make kernel_menuconfig -j$(nproc)
Enable MPTCP protocol then MPTCP: advanced path-manager control & MPTCP: advanced scheduler control at Networking support -> Networking options by pressing "y".
Enable MPTCP Full-Mesh Path-Manager then choose Default MPTCP Path-Manager as Full mesh at Networking support -> Networking options -> MPTCP: advanced path-manager control by pressing "Enter".
If you'd like to enable MPTCP TCP congestion controls and set default, you can do so at TCP: advanced congestion control.
Finally, make the image
make -j$(nproc)
  Using shadowsocks-libev & v2ray
v2ray is recommended for use instead of shadowsocks-libev because of significantly better performance.
v2ray
v2ray-core: https://github.com/arinc9/v2ray-openwrt
luci-app-v2ray: https://github.com/kuoruan/luci-app-v2ray
shadowsocks-libev
opkg update && opkg install luci-app-shadowsocks-libev shadowsocks-libev-config shadowsocks-libev-ss-local shadowsocks-libev-ss-redir shadowsocks-libev-ss-rules shadowsocks-libev-ss-server shadowsocks-libev-ss-tunnel
  Here's my Multipath TCP knowledgebase:
Notion
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team
Here's the aggregation solution I use:
Notion
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team
  It took me 3 days to test the patches and make the guide. Have fun!
Updates

1 Reply
12

[Assistant]
Your tutorial worked perfectly for D-Link DIR-842 C1!! I didn't get any error at all, just copy pasted everything from your tutorial and it all went smoothly. I flashed the resulting image, and was able to verify with external servers that MPTCP actually works! Thanks a lot!

That's great to hear! I'm using this solution on my router Linksys WRT32X as well. Getting 200/13mbps speed over v2ray socks connection. I couldn't get full speed on shadowsocks. I even ran a few tests here. Quoting from there:
Shadowsocks (shadowsocks-libev & v2ray)
shadowsocks-libev gives max of 50mbps speed
v2ray gives max of 110mbps speed
SOCKS5 (SSH & v2ray)
SSH gives max of 50mbps speed
v2ray gives full speed

First time I am hearing of v2ray. Will have to check it out.
It would be interesting to test Wireguard performance. If v2ray is giving you full speed, I suspect Wireguard would give you full speed too


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Xiaomi ax3600 ssh guide

Half a year has passed since the release of the xiaomi wifi6 router ax3600. And finally we can get the ssh access on it.
The origin exploit is found by LonGDikE from Chinese Enshan forum.
Here are the steps:
Downgrade your router to 1.0.17 version:http://cdn.cnbj1.fds.api.mi-img.com/xiaoqiang/rom/r3600/miwifi_r3600_firmware_5da25_1.0.17.bin
Login in to your router and get the STOK like follwing:
http://192.168.31.1/cgi-bin/luci/;stok=<STOK>/web/home#router
Access these urls in browser:
(nvram set ssh_en=1;nvram commit)
http://192.168.31.1/cgi-bin/luci/;stok=<STOK>/api/misystem/set_config_iotdev?bssid=Xiaomi&user_id=longdike&ssid=-h%3Bnvram%20set%20ssh%5Fen%3D1%3B%20nvram%20commit%3B
(sed -i 's/channel=.*/channel="debug"/g' /etc/init.d/dropbear)
http://192.168.31.1/cgi-bin/luci/;stok=<STOK>/api/misystem/set_config_iotdev?bssid=Xiaomi&user_id=longdike&ssid=-h%3Bsed%20-i%20's/channel=.*/channel=%5C%22debug%5C%22/g'%20/etc/init.d/dropbear%3B
(/etc/init.d/dropbear start)
http://192.168.31.1/cgi-bin/luci/;stok=<STOK>/api/misystem/set_config_iotdev?bssid=Xiaomi&user_id=longdike&ssid=-h%3B/etc/init.d/dropbear%20start%3B
If everything is ok ,the ssh is enabled now.
PS: You can excute any shell code like this:
http://192.168.31.1/cgi-bin/luci/;stok=<STOK>/api/misystem/set_config_iotdev?bssid=Xiaomi&user_id=longdike&ssid=-h%3B<your encoded shell code>%3B

8

[Assistant]
Did your Redmi AX5 have version 1.0.16 installed when you received it or did you downgrade?
I'm wondering how to find the download links for previous versions for the Mi AX1800.

Yes recieved with 1.0.16 in ax5.
If find something for AX1800 i talk to you

2 Replies
1

I think I need to downgrade to 1.0.34, the link is available on right.com.cn forum but I'm not a member, maybe someone with access could post it here.
Edit: No need to downgrade, gained SSH access to the Mi AX1800 running latest 1.0.336 firmware after a reset and setup in router mode, in AP mode is didn't work.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: A new theme designed for LuCI – luci-theme-rosy

This project is open source at : https://github.com/rosywrt/luci-theme-rosy
The relevant feeds is : https://github.com/rosywrt/luci
Hello !
We made a new theme for LuCI, flat UI design, concise style. Matching colors with red and grey. Hope you will like it, thanks!
PC

12

[Assistant]
I like the menus on the left side and the "pastel" touch but as technical guy black and white suits me fine ;- )
Thats brings me to some other points: If openwrt/luci versions change you have to adapt? and second: How is it security wise if I include this feed I have to trust you, right?

2

I am thinking about send a pull request to luci community.
By the way, it is quite security, and you can check the source at https://github.com/rosywrt/luci-theme-rosy and copy it in to official luci feed if you are familiar with openwrt engough.

I would change the theme name to Romy - La Rose as tribute to Romy Schneider which was born on a 23. September

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: NanoPI R2S is a great OpenWrt device

Over the past few weeks I have been fortunate enough to do some tests with early OpenWRT builds on the NanoPI R2S provided to me by
@jayanta525
.
This is a dual Gigabit Ethernet board with a 4 core Rockchip SOC (RK3328) on it, manufactured by FriendlyARM.
Performance of the board is great, especially considering its price point (€32 incl shipping to Europe in my case). In summary (more details below):
AES h/w accelerated openssl, up to 12x openssl performance compared to RPi4
WAN-to-LAN/ingress (NAT + firewall) TCP throughput of 940 Mbps
SQM enabled ingress up to 465 Mbps, egress up to 750 Mbps
@Jayanta525
is working on other similar RK3328 boards as well, like the Rock Pi E, and is currently preparing a PR. Once ready, please consider supporting us getting the PR merged into mainline OpenWRT!
OpenSSL performance
root@nanopi-r2s:~# openssl speed -evp aes-128-cbc -elapsed
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 24232739 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 18557185 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 8901311 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 2985544 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 414423 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 208278 aes-128-cbc's in 3.00s
OpenSSL 1.1.1  11 Sep 2018
built on: Tue Nov 12 16:58:35 2019 UThar) des(int) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-J6qvxk/openssl-1.1.1=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc     129241.27k   395886.61k   759578.54k  1019065.69k  1131651.07k  1137475.58k
root@nanopi-r2s:~# openssl speed aes-128-cbc
Doing aes-128 cbc for 3s on 16 size blocks: 8962695 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 2534616 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 256 size blocks: 652684 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 164408 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 20592 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 16384 size blocks: 10291 aes-128 cbc's in 3.00s
OpenSSL 1.1.1  11 Sep 2018
built on: Tue Nov 12 16:58:35 2019 UTCns:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-J6qvxk/openssl-1.1.1=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128 cbc      47801.04k    54071.81k    55695.70k    56117.93k    56229.89k    56202.58k
TCP routing performance
FriendlyARM states 941 Mbps throughput on both eth interfaces. I have confirmed this. Furthermore I have tested routing performance as follows. Test setup: Windows laptop on LAN port, Linux machine on WAN port, both running iperf3.
iperf3 ~890 Mbps (LAN-to-WAN)
iperf3 -R ~910 Mbps (WAN-to-LAN)
This packet steering trick from the RPi4 thread actually slows down the iperf3 performance (both directions) with around 1-2%:
echo 2 > /sys/class/net/eth1/queues/rx-0/rps_cpus
echo 1 > /sys/class/net/eth0/queues/rx-0/rps_cpus
Resetting that, and enabled software offloading in luci increases performance with a few %:
iperf3 ~898 Mbps
iperf3 -R ~941 Mbps (line speed!)
Note: for full performance like this, the IRQ of eth1 needs to be moved to a different CPU core. Failing to get irqbalance to work, I did:
root@OpenWrt:/etc/rc.d# cat /proc/irq/166/smp_affinity
f
root@OpenWrt:/etc/rc.d# echo "e" > /proc/irq/166/smp_affinity
root@OpenWrt:/etc/rc.d# cat /proc/irq/166/smp_affinity
e
TCP routing performance with SQM
Using the default SQM setup as described in OpenWRT wiki ("piece of cake"), I was able to get the following impressive numbers which should cover the vast majority of SOHO broadband installations.
ingress (WAN-to-LAN) shaping seems to be saturating 1 CPU core and is limited to around 465 Mbps TCP. Moving IRQs around for a bit does not help.
egress shaping works fine at 750 Mbps, two cores are up to 90%.

3 Replies
19

[Assistant]
Thanks for the test info.
What is the CPU temp like while running the tests? My RPI4 at idle sits around 50ºC for comparison running a heatsink passive cooling case.
I read that this thing runs very hot on factory software.

1

I was seeing 50-52 ºC while doing these tests. I have the model with a fixed, passive heatsink. I am running mine outside of its case at the moment as I have the UART connected.
The board has a fan header (ZH1.5 2 pins) so a fan when installed permanently may be a good idea.

1

this amazing!
will follow this thread to get next update
could i buy this i AliExpress with official price ? 22$


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: [Banana BPI-R4] Wifi7 status

BE200
As in the thread.
Not working with Banana Pi BPI-R4 board. It is an Intel familly so we cannot expect here AP mode.
WCN7851/QCNCM865
As in the thread.
Not working with Banana Pi BPI-R4 board as probably we hit the pci bug for ath12k module.
MT7925/MT7927
Based on https://wikidevi.wi-cat.ru/MediaTek:
MT7925:
Wi-Fi 7, WPA3, 2.4/5/6GHz, 4.5Gbps,
DBDC, BW 160MHz, 4K QAM, MLO,
BT 5.3 LE, MRC, MRU, HDT, 6 nm
FCC ID: RAS-MT7925B22M
MT7927:
Wi-Fi 7, WPA3, 2.4/5/6GHz, 6.5Gbps,
DBDC, BW 320MHz, 4K QAM, MLO,
BT 5.3 LE, MRC, MRU, HDT, 6 nm
FCC ID: RAS-MT7927 • AMD RZ738
Based on https://wikidevi.wi-cat.ru/Mt76
MT7925 - 802.11a/b/g/n/ac/ax/be 2T2R 2.4/5G/6GHz PCIe/USB Chip (6.7+)
As the snashopt OpenWrt is with kernel 6.6.32 we cannot expect it working it as you can see below:

mt7925 Makefile config can be taken from here and copied to package/kernel/mt76/Makefile

4

[Assistant]
I've ordered a sample Emwicon WMX8402 and will share my experiences here as soon as it has arrived.
Emwicon has not finished its firmware right now therefore don't expect miracles

2 Replies

We'll probably move to a more recent wireless stack in the future, but I have no idea which kernel is going to be LTS after 6.6. The wireless stack OpenWrt uses is often (if the timeframe allows it) one LTS version ahead of the LTS used as the OpenWrt kernel itself.

I was thinking about that card but the prise is really high. It uses also ath12k...


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Reducing multiplexing latencies still further in wifi

I have been sucked into helping stablizing the current and next releases of openwrt wifi, and it's beginning to look like many of the power, multicast, and reliability problems have all been solved, thx to the enthusiastic testing and commitment by openwrt's wonderful community, and I really hope rc6 rocks and hundreds of wifi bugs all over can be closed that were side-effects of the mess.
But!
What I'd actually set out to do months ago was test implementing more than a few latency reducing ideas left over from the original make-wifi-fast project: https://www.youtube.com/watch?v=Rb-UnHDw02o - of note were ack-filtering, reducing the intervals announced in the beacon, reducing the codel target, l4s-style ecn, better controlling the multicast queue, and fiddling with understanding the real effects of qosify on modern wifi stacks.
The simplest of these is to try improving multiplexing behavior by reducing the maximum txop size. There's four places to do this nowadays, this is in hostapd.conf...
The simplest test is to verify that the AP chipset can use some reduced parameters, mimicking the VI queue thusly.
tx_queue_data2_aifs=1
tx_queue_data2_cwmin=7
tx_queue_data2_cwmax=15
tx_queue_data2_burst=3.0 # this is a really low value for modern ac but
This will clobber from the AP performance even more than what we are seeing today, and is undesirable for most apps. (but does it work in x chipsets? What does it look like?) - CORRECTION - I assumed this was the max txop size (5.7), in saying that, and it turned out that openwrt was already tuning it down to 2. Putting it up to 3 got a better down/up ratio. Still not the right thing but (see a few more posts below)
More interesting is observing whether or not announcing this reduced interval in the beacon is respected by the client, which should improve up/down fairness in the rrul_be test, and is probably desirable behavior for most.
wmm_ac_be_aifs=2
wmm_ac_be_cwmin=3
wmm_ac_be_cwmax=4
wmm_ac_be_txop_limit=94 # arguably we can just change this
wmm_ac_be_acm=0
There are a lot of other mysterious parameters in https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf -
Now, an algorithm to do this more right (reducing the txop size in beacon announcements in response to the number of stations with data outstanding) is in the cards, with a ceiling of say, 1.1ms instead of 5.7, but first up is merely verifying that drivers and clients obey the rruls. There is also a potential impact on the ATF calculations...
Assuming that actually doesn't crash things, verifying that the VI queue is working as designed vs a vs the BE queue would be next, then merely reducing wmm_ac_be_txop_limit sanely for be.
anyway, we could get a 4-8fold reduction in latency and jitter by fiddling with these at some cost in bandwidth that those with a lot of stations would probably find acceptible. I routinely ran with 2.1ms as my outer limit on my old mesh.

2 Replies
8

[Assistant]
@dtaht
, I've got a mac80211.sh patched and ready to go. What should be tested, what should be observed? Is this something only for APs? Should STAs be patched too?

2 Replies

One or both of us should figure out where our OCD meds got to...
The first set of options I described tells the AP or STA to use limited airtime, the second announces in the beacon that the clients should use limited airtime. Since you have the up/down difference, simplest test is 2) a short rrul_be against:
wmm_ac_be_txop_limit=94
(if i was unclear, the first test was to see if changing those parameters actually did anything on the local AP or STA, before trying to command the client to obey them also)
There's two approaches to life. Scientifically, and rigorously change one variable at a time, or "all up" - change as much as possible, and iterate rapidly backwards from the RUD. Both approaches are valid, and needed, the latter got us to the moon in 8 years.
Bonus link: https://longnow.org/essays/richard-feynman-connection-machine/

2

dtaht:
One or both of us should figure out where our OCD meds got to...
Me, mostly certain. I promise not to read something that must be comprehended with only two and a half hours of sleep. Let's try it first reducing wmm_ac_be_txop_limit=94. I'll do some testing once my significant other finish work today.
Ta,
@dtaht
!


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Working Realtek SoC RTL8196E 97D 97F in last master

I have ported the RTL8196E RTL8197D and RTL8197F SoC from Realtek to the last master of Openwrt (as of today).
GitHub
ggbruno/openwrt
This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins or for reporting issues. We will continue to accept Pull Request...
This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins or for reporting issues. We will continue to accept Pull Request...
The port have the necessary code for those SoCs. I used the
@hackpascal
initial port as a start and have ported RLX4181 and RLX5281 Lexra processors. Those are easier to port, as they have the unaligned instructions. Musl is working in lexra now...
RTL8197F uses a full 24k mips processor, so, no modification is needed in the toolchain...
For the SoCs:
All the SoC drivers are implemented and tested (gpio, pci, irq, timers, etc), for the three SoCs. One can port a router to openwrt just creating a DTS file for it (and changing the Makefiles, as any normal port for openwrt).
The problem is with network and wireless. RTL8196E based routers can use the RTL8192EE open source wifi driver from mac80211 package. Most routers that use RTL8197D SoC also use RTL8192EE for 2.4 and RTL8812 for 5... Both drivers are open source on linux kernel...
TODO:
Network and switch driver: hackpascal has started the port for RE865X driver. Need rework for new SoCs....
RTL8197F 2.4Ghz wireless driver: This SoC uses an internal wifi, but can be ported to the new RTW88 driver, as they use the same structs (8192EE uses this structs too, but is implemented in the old driver... May a port of 8192EE to the new driver can help too )
Performace: The main focus right now is compatibility... We need to improve for performace....
Use the ramdisk for now... As we dont have the network driver right now, we must use the serial port to bootup... The cvimg boot can be used, but is now of much use right now...
Any help and feedback are welcome

9

[Assistant]
Bootlog for RTL8192E
[    0.000000] Linux version 4.14.187 (gaspare@gaspare-MacBookAir) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r14023-1deaf695ec)) #0 T0
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 0000cd01 (Lexra LX4380 / RLX4181)
[    0.000000] MIPS: machine is Multilaser RE172 V1
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 02000000 @ 00000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] BOOTSTRAP = 8196e001 2 100218 b08
[    0.000000] Primary instruction cache 16kB, linesize 16 bytes.
[    0.000000] Primary write-back data cache 8kB, linesize 16 bytes.
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000001ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000001ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000001ffffff]
[    0.000000] random: get_random_bytes called from start_kernel+0x9c/0x4e0 with crng_init=0
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8120
[    0.000000] Kernel command line: console=ttyS0,38400
[    0.000000] PID hash table entries: 128 (order: -3, 512 bytes)
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Memory: 19248K/32768K available (4442K kernel code, 159K rwdata, 832K rodata, 7488K init, 204K bss, 13520K reserve)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 128
[    0.000000] clocksource: RTL819X counter: mask: 0xfffffff max_cycles: 0xfffffff, max_idle_ns: 4778151100 ns
[    0.000034] sched_clock: 28 bits at 25MHz, resolution 40ns, wraps every 5368709100ns
[    0.025522] timer-controller: running - mult: 107374182, shift: 32, IRQ: 7, CLK: 25.000MHz
[    0.052958] Calibrating delay loop... 397.82 BogoMIPS (lpj=795648)
[    0.105601] pid_max: default: 32768 minimum: 301
[    0.121964] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.143697] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.184820] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.216906] futex hash table entries: 256 (order: -1, 3072 bytes)
[    0.239084] NET: Registered protocol family 16
[    1.001167] PCI host bridge to bus 0000:00
[    1.014647] pci_bus 0000:00: root bus resource [mem 0x19000000-0x19ffffff]
[    1.037216] pci_bus 0000:00: root bus resource [io  0x18c00000-0x18dfffff]
[    1.059810] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
[    1.082111] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
[    1.109647] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    1.138528] pci 0000:00:00.0: BAR 8: assigned [mem 0x19000000-0x190fffff]
[    1.160894] pci 0000:00:00.0: BAR 7: assigned [io  0x18c00000-0x18c00fff]
[    1.183247] pci 0000:01:00.0: BAR 2: assigned [mem 0x19000000-0x19003fff 64bit]
[    1.207328] pci 0000:01:00.0: BAR 0: assigned [io  0x18c00000-0x18c000ff]
[    1.229645] pci 0000:00:00.0: PCI bridge to [bus 01]
[    1.245948] pci 0000:00:00.0:   bridge window [io  0x18c00000-0x18c00fff]
[    1.268256] pci 0000:00:00.0:   bridge window [mem 0x19000000-0x190fffff]
[    1.293361] clocksource: Switched to clocksource RTL819X counter
[    1.319464] NET: Registered protocol family 2
[    1.336443] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[    1.359429] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[    1.380334] TCP: Hash tables configured (established 1024 bind 1024)
[    1.401946] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    1.421214] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    1.443012] NET: Registered protocol family 1
[    1.573510] random: fast init done
[    2.296471] Crashlog allocated RAM at address 0x1f00000
[    2.323211] workingset: timestamp_bits=14 max_order=13 bucket_order=0
[    2.381620] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    2.400799] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    2.568508] io scheduler noop registered
[    2.581500] io scheduler deadline registered (default)
[    2.600128] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
[    2.623840] console [ttyS0] disabled
[    2.635794] 18002000.serial: ttyS0 at MMIO 0x18002000 (irq = 28, base_baud = 12500000) is a 16550A
[    2.665498] console [ttyS0] enabled
[    2.665498] console [ttyS0] enabled
[    2.688503] bootconsole [early0] disabled
[    2.688503] bootconsole [early0] disabled
[    2.743549] m25p80 spi0.0: gd25q32 (4096 Kbytes)
[    2.824635] 2 fixed-partitions partitions found on MTD device spi0.0
[    2.845952] Creating 2 MTD partitions on "spi0.0":
[    2.862089] 0x000000000000-0x000000010000 : "boot"
[    2.882633] 0x000000010000-0x000000400000 : "firmware"
[    2.909620] NET: Registered protocol family 10
[    2.947927] Segment Routing with IPv6
[    2.960656] NET: Registered protocol family 17
[    2.975928] 8021q: 802.1Q VLAN Support v1.8
[    3.035923] Freeing unused kernel memory: 7488K
[    3.051177] This architecture does not have kernel memory protection.
[    3.131238] init: Console is alive
[    3.211875] kmodloader: loading kernel modules from /etc/modules-boot.d/*
[    3.246387] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[    3.282665] init: - preinit -

[    4.734676] random: jshn: uninitialized urandom read (4 bytes read)
[    5.069736] random: jshn: uninitialized urandom read (4 bytes read)
[    5.998420] random: jshn: uninitialized urandom read (4 bytes read)
[    6.217717] random: jshn: uninitialized urandom read (4 bytes read)
[    6.755500] random: jshn: uninitialized urandom read (4 bytes read)
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[   10.816134] procd: - early -
[   11.505577] procd: - ubus -
[   11.542893] random: ubusd: uninitialized urandom read (4 bytes read)
[   11.569277] random: ubusd: uninitialized urandom read (4 bytes read)
[   11.592857] random: ubusd: uninitialized urandom read (4 bytes read)
[   11.623301] procd: - init -
Please press Enter to activate this console.
[   13.865007] kmodloader: loading kernel modules from /etc/modules.d/*
[   13.951095] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   14.056952] Loading modules backported from Linux version v5.8-rc2-0-g48778464bb7d
[   14.082325] Backport generated by backports.git v5.8-rc2-1-0-g7a69429b
[   14.145792] urngd: v1.0.2 started.
[   14.171293] ip_tables: (C) 2000-2006 Netfilter Core Team
[   14.255706] nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
[   14.688222] xt_time: kernel timezone is -0000
[   14.872751] random: crng init done
[   14.884328] random: 2 urandom warning(s) missed due to ratelimiting
[   15.077787] PPP generic driver version 2.4.2
[   15.128741] NET: Registered protocol family 24
[   15.308137] PCI: Enabling device 0000:00:00.0 (0000 -> 0003)
[   15.361707] rtl8192ee: Using firmware rtlwifi/rtl8192eefw.bin
[   15.396009] rtlwifi: rtlwifi: wireless switch is on
[   15.542723] kmodloader: done loading kernel modules from /etc/modules.d/*

BusyBox v1.31.1 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt SNAPSHOT, r14023+1-1deaf695ec
 -----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@(none):/#

1 Reply
3

Excellent work done here, porting into dts system is a godsend. I also started something earlier but I was alone and couldn't forward much.
@gaspare
GitHub
shibajee/linux-rtl8196e
Realtek RTL8196E SoC Linux port. Contribute to shibajee/linux-rtl8196e development by creating an account on GitHub.

GitHub
shibajee/binutils
Lexra and RLX CPU support. Contribute to shibajee/binutils development by creating an account on GitHub.

GitHub
shibajee/gcc
Lexra and RLX CPU support. Contribute to shibajee/gcc development by creating an account on GitHub.

GitHub
shibajee/uclibc-ng
Lexra and RLX CPU support. Contribute to shibajee/uclibc-ng development by creating an account on GitHub.

GitHub
shibajee/buildroot-rlx4181
Patch for RLX4181 compatibility. Contribute to shibajee/buildroot-rlx4181 development by creating an account on GitHub.

1

Can you help me build the firmware for a RTL8197D router with 8mb flash and 32mb ram? I attempted to build on my machine but encountered an "dependency on 'libpcre' " error that I was not able to resolve. I am trying to unbrick my router locked in miniweb server after firmware update.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Asus TUF Gaming AX6000 support

A fresh model from ASUS based on Filogic SOC (based on reviews found in the web, I don't own the actual hardware now)
ASUS Global
TUF Gaming AX6000｜WiFi Routers｜ASUS Global
ASUS gaming routers provide the very best gaming experience, with an arsenal of features and tools designed to improve online gaming performance and give you the competitive edge you need to win.
It looks similar to ASUS TUF Gaming AX4200 (support thread Asus TUF AX4200 support), but with one additional 2.5G for LAN, 6 instead of 4 external antennas and 4x4 streams for both 2.4GHz and 5GHz

7

[Assistant]
It is a different device. I hope I don't break any rules by giving external link https://www.aroged.com/2023/05/29/review-and-testing-of-asus-tuf-gaming-ax6000-wireless-router/
The old GT-AX6000 is clearly broadcom though OpenWrt on ASUS GT-AX6000 but GT-AX6000 and TUF-AX6000 are different devices.
The link to FCCID https://fccid.io/MSQ-RTAX6700 There are internal photos, which clearly show that it is MEDIATEK.

2

While it should be supportable, someone[0] with the device on their desk will still have to do the porting work.
--
[0] this "someone" might be you, yourself - it's going to be a steep learning curve, but judging from the TUF-AX4200 and the pending RT-AX59U PR there shouldn't be anything particularly bad about it either.

I'v jut bought this one. To support it with OpenWRT, I think most of the AX4200 support can be reused. Unfortunately, ASUS hasn't released any GPL source to it. In discussion with Asus support, they said they are not obliged to do so. Typical reaction I guess.
Hope I can base the OpenWrt support on the decompiled DTB and the AX4200 support...

1 Reply
2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Belkin RT3200/Linksys E8450 WiFi AX discussion

Bringing the discussion over from here - https://github.com/dangowrt/linksys-e8450-openwrt-installer/issues/7
I'll try to keep this updated - drop progress/thoughts below!
Working (snapshot)
11a HE80 (add htmode HE80 to /etc/config/wireless - 1200 Mbit link speed)
iwinfo (merged - https://git.openwrt.org/?p=project/iwinfo.git;a=commit;h=50b64a63e3945693646d1b2eb4e59e14e35cedc3)
Not working
11a HE160 (not detected by supporting devices)
11a HE80+80 (< 100 Mbit link speeds on supporting devices)
hostapd (patch works but needs merge - https://patchwork.ozlabs.org/project/openwrt/list/?series=229531)
Luci (no AX support at all currently - WIP here https://github.com/openwrt/luci/pull/4994)
Not tested
2.4Ghz AX (i.e. 11g w/ HE) (not supported)
6Ghz (not supported)

2 Replies
15

[Assistant]
andyrichardson:
Not tested
2.4Ghz AX (i.e. 11g w/ HE)
6Ghz (supported?)
Neither of these are supported by the hardware.

1 Reply
3

HE160 and HE80P80 are supported by the hardware?
I know HE80 is supported despite the OEM only offering up to HE40.
Can you post an iw phyX info for both Phys please? I assume iw is patched enough to understand the capabilities the radio will report.

Yup it's fully supported according to iw list
HE PHY Capabilities: (0x5c70ce126d00f3064e3f00):
    HE40/HE80/5GHz
    HE160/5GHz
    HE160/HE80+80/5GHz
Full output
For now, I'm guessing HE80+80 is a bit of a stretch - as far as I can tell, OpenWRT doesn't currently support dual bands on a single radio (or whatever it's called) such as VHT40+40 / VHT80+80

1 Reply
2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: OpenWrt support for Xiaomi AX9000

Let's move the Xiaomi AX9000 related discussion to a new thread to reduce off-topics in the AX3600 one.
@kirdes
@sumo
Current state as of (07.11.2022).
Working:
4x 1G ports
1x 2.5G port
USB 3.0 port
QCA9889 IoT radio
Built-in IPQ8074 radios (2.4G and high 5GHz band)
LED-s
Buttons
Not working:
PWM LED effects (Honestly not worth the effort)
Fan controller (Lacking driver)

1 Reply
14

[Assistant]
UART
From left to right:
RX, GND, TX (I guess ;-), VCC

Did you have to remove the board in order to solder the header?

2 Replies

I did that, its better to solder the header from the other side.
But it should be also possible to solder wires from the top side i think.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: [Tutorial] Build, customize and use MediaTek open-source U-Boot and ATF

This tutorial will help you to build, use and customize the official u-boot and atf (TF-A) from MediaTek SDK.
1. Source code
U-Boot: https://github.com/mtk-openwrt/u-boot
ATF: https://github.com/mtk-openwrt/arm-trusted-firmware
2. Toolchain
This tutorial talks only about the ARM 64-bit platforms. So you need only the aarch64 toolchain.
You can use the openwrt toolchain which can be found in staging_dir/toolchain-aarch64_XXXXX
You also need dtc tool to compile .dts files for ATF. It can be found in:
device-tree-compiler package in Ubuntu for example
scripts/dtc from a compiled u-boot/kernel source tree
3. Configure u-boot
Here is a list for all defconfigs supports MediaTek-specific features (Bootmenu with upgrading/booting support)
Name Boot device Description
mt7622_emmc_rfb_defconfig eMMC (dev 0)****
mt7622_nmbm_rfb_defconfig SPI-NAND (SNFI)* NMBM enabled. Uses squashfs + jffs2
mt7622_nmbm_ubi_rfb_defconfig SPI-NAND (SNFI) NMBM enabled. Uses UBI
mt7622_nor_rfb_defconfig SPI-NOR***
mt7622_sd_rfb_defconfig SD (dev 1)****
mt7622_snand_ubi_rfb_defconfig SPI-NAND (SNFI) Uses UBI
mt7981_emmc_rfb_defconfig eMMC
mt7981_sd_rfb_defconfig SD
mt7981_snfi_nand_rfb_defconfig SPI-NAND (SNFI) NMBM enabled. Uses UBI
mt7981_spim_nand_rfb_defconfig SPI-NAND** NMBM enabled. Uses UBI
mt7981_spim_nor_rfb_defconfig SPI-NOR
mt7986_snfi_nand_rfb_defconfig SPI-NAND (SNFI) NMBM enabled. Uses UBI
mt7986_spim_nand_rfb_defconfig SPI-NAND NMBM enabled. Uses UBI
mt7986_spim_nor_rfb_defconfig SPI-NOR
mt7986a_bpir3_emmc_defconfig eMMC
mt7986a_bpir3_sd_defconfig SD
mt7987_emmc_rfb_defconfig eMMC
mt7987_sd_rfb_defconfig SD
mt7987_spim_nand_rfb_defconfig SPI-NAND** NMBM enabled. Uses UBI
mt7987_spim_nor_rfb_defconfig SPI-NOR
mt7988_snfi_nand_rfb_defconfig SPI-NAND (SNFI) NMBM enabled. Uses UBI
mt7988_spim_nand_rfb_defconfig SPI-NAND** NMBM enabled. Uses UBI
mt7988_spim_nor_rfb_defconfig SPI-NOR
mt7988_emmc_rfb_defconfig eMMC
mt7988_sd_rfb_defconfig SD
* SPI-NAND (SNFI) means the SPI-NAND is connected to the MediaTek SPI-NAND Flash Interface (SNFI), a dedicated controller for SPI-NAND flashes using MTK's HW ECC engine instead of the On-die ECC engine from SPI-NAND chip.
** SPI-NAND without SNFI means the SPI-NAND is connected to the standard spi-mem controller.
*** MT7622 uses a dedicated SPI-NOR controller while MT7981/MT7986 use standard spi-mem controller.
**** MT7622 has two SD/eMMC controllers (called MSDC), the first one always connects to the eMMC and the second one always connects to SD.
To configure the u-boot, please run the following command in u-boot source directory:
make XXXXX_defconfig
4. Compile u-boot
Run the following command in u-boot source directory:
make CROSS_COMPILE=<toolchain-prefix>
Assume you have a toolchain located at ~/openwrt/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0-musl, and a directory named aarch64-openwrt-linux is inside the toolchain base directory, the toolchain-prefix will be:
~/openwrt/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0-musl/bin/aarch64-openwrt-linux-
If no error occurs, the target file is u-boot.bin.
5. Compile ATF
To compile ATF, we have to pass several configuration parameters to the make command line.
The overall command line is:
make -f Makefile PLAT=<plat> BOOT_DEVICE=<bootdevice> BL33=<path-to-u-boot.bin> <optional-options> all fip
If no error occurs, the target file are bl2.img and fip.bin located in
<atf-src-dir>/build/<plat>/release
a) Essential parameters:
PLAT=
Possible values: mt7622/mt7981/mt7986/mt7988
BOOT_DEVICE=
Value Boot device Description
nor SPI-NOR
snand SPI-NAND (SNFI) optional NAND_TYPE= may be needed
spim-nand SPI-NAND optional NAND_TYPE= may be needed
emmc eMMC
sdmmc SD optional DEVICE_HEADER_OFFSET= may be need by mt7622
ram - For debugging purpose only
b) Optional parameters:
NAND_TYPE=
This option is valid only when BOOT_DEVICE= is set to snand or spim-nand.
By default NAND_TYPE= will be set to default value if not specified.
Important notice: NAND_TYPE must match the memory organization of the SPI-NAND chip otherwise the device will not boot.
Value Boot device Platform Description
2k+64 snand mt7622 Page size: 2K, Spare size: 64 (default)
2k+128 snand mt7622 Page size: 2K, Spare size: 128
4k+256 snand mt7622 Page size: 4K, Spare size: 256
hsm:2k+64 snand mt7981/mt7986 Page size: 2K, Spare size: 64 (default)
hsm:2k+128 snand mt7981/mt7986 Page size: 2K, Spare size: 128
hsm:4k+256 snand mt7981/mt7986 Page size: 4K, Spare size: 256
hsm20:2k+64 snand mt7988 Page size: 2K, Spare size: 64 (default)
hsm20:2k+128 snand mt7988 Page size: 2K, Spare size: 128
hsm20:4k+256 snand mt7988 Page size: 4K, Spare size: 256
spim:2k+64 spim-nand mt7981/mt7986/mt7988 Page size: 2K, Spare size: 64 (default)
spim:2k+128 spim-nand mt7981/mt7986/mt7988 Page size: 2K, Spare size: 128
spim:4k+256 spim-nand mt7981/mt7986/mt7988 Page size: 4K, Spare size: 256
NMBM=
This option is valid only when BOOT_DEVICE= is set to snand or spim-nand.
This option is incompatible with UBI=1
Value Description
0 Disable NMBM (default)
1 Enable NMBM
UBI=
Enable this option if FIP is located in a volume of UBI.
This option is valid only when BOOT_DEVICE= is set to snand or spim-nand.
This option is incompatible with NMBM=1
Value Description
0 Disable Full-UBI layout (default)
1 Enable Full-UBI layout
DRAM_USE_DDR4=
This option is valid only for mt7981/mt7986/mt7988.
MT7988: this is used for single DDR4 chip.
Value Description
0 The DRAM chip is DDR3 (default)
1 The DRAM chip is DDR4
DRAM_USE_COMB=
When this option suppresses DRAM_USE_DDR4.
This option is valid only for mt7988.
Value Description
0 No effect (default)
1 The MT7988 CPU uses KGD DDR die, or the board is using two DDR chips
DDR4_4BG_MODE=
This option is valid for mt7987/mt7988.
For mt7988, this option must be used with DRAM_USE_COMB=1.
Value Description
0 No effect (default)
1 Enable DDR4 4GBytes (mt7987) / 32-bit 8GBytes mode (mt7988)
DDR3_FLYBY=
This option is valid only for mt7622.
Value Description
0 The board uses only one DRAM chip (default)
1 The board uses two dram chips (For BPI-R64)
BOARD_BGA=
This option is valid only for mt7981.
Value Description
0 The chip package is QFN (MT7981C) (default)
1 The chip package is BGA (MT7981A/MT7981B)
RAM_BOOT_DEBUGGER_HOOK=
This option is valid only when BOOT_DEVICE= is set to ram.
By using this option, the bl2.bin can be load by OpenOCD for debricking.
Please refer to: https://github.com/mtk-openwrt/openocd-scripts/tree/main/mt7622
Value Description
0 Disable debugger hook (default)
1 Enable debugger hook
RAM_BOOT_UART_DL=
This option is valid only when BOOT_DEVICE= is set to ram.
By using this option, the bl2.bin can be load by UART-boot tool for debricking.
Value Description
0 Disable UART download (default)
1 Enable UART download
DEVICE_HEADER_OFFSET=
This option is valid only when PLAT is mt7622 and BOOT_DEVICE= is set to sdmmc.
This option specify the absolute address of the BL2 in the SD card.
This value must match the real address of the BL2 in the SD card otherwise the device will not boot.
The default value is 0x80000.
ENABLE_JTAG=
This option is valid only when PLAT is mt7981/mt7988.
By default JTAG will be disabled in BL2.
Value Description
0 Disable JTAG (default)
1 Enable JTAG
USE_MKIMAGE= and MKIMAGE=
If you don't want to use the closed-source program bromimage to generate bl2.img, you can use the open-source replacement —— The mkimage from u-boot.
To enable using mkimage, these two parameters must be used together:
USE_MKIMAGE=1 MKIMAGE=<path-to-mkimage>
OVERRIDE_FIP_BASE= and OVERRIDE_FIP_SIZE=
If both specified, they will override the default FIP base & size provided by each platform.
These options have no effect if UBI=1.
OVERRIDE_UBI_START_ADDR=
These options is only valid for UBI=1.
If specified, it will override the default UBI partition start address, which is 0x200000.
OVERRIDE_UBI_END_ADDR=
These options is only valid for UBI=1 and OVERRIDE_UBI_START_ADDR is set.
If specified, it will override the default UBI partition end address, which is 0, meaning the end of NAND.
BL2_COMPRESS=
If set to 1, BL2 will be compressed with XZ and a preloader will be built to decompress BL2 at runtime.
This can reduce the loading time of BL2 used for UART booting.
Enabling compression will increase the boot time by 1s.
FIP_COMPRESS=
If set to 1, FIP payloads will be compressed with XZ and will be decompressed by BL2 at runtime.
This can reduce the size of FIP which is useful if used for SPI-NOR booting.
Also this can reduce the loading time of FIP used for UART booting.
Enabling compression will introduce extra decompression time by 1s.
c) Examples
Build for BPI-R64 booting from SPI-NAND:
make -f Makefile PLAT=mt7622 BOOT_DEVICE=snand DDR3_FLYBY=1 all fip
Build for MT7986 booting from SD using DDR4:
make -f Makefile PLAT=mt7986 BOOT_DEVICE=sdmmc DRAM_USE_DDR4=1 all fip
6. Upgrade the new U-Boot and ATF
The final files are bl2.img and fip.bin. You can upgrade them from anywhere, e.g. from u-boot bootmenu or from linux shell of OpenWrt.
7. Breif introduction of MediaTek-specific u-boot features
Five commands are added:
Command Description
mtkautoboot Display MediaTek-specific bootmenu
mtkupgrade Start interactive prompt for firmware/bootlaoder upgrading
mtkload Start interactive prompt for loading data to ram
mtkboardboot Automatically boot the firmware
httpd Start Web-based failsafe for upgrading firmware
mtkautoboot
This command is also the autoboot command for u-boot.
A menu will be displayed like this:
  *** U-Boot Boot Menu ***

      1. Startup system (Default)
      2. Upgrade firmware
      3. Upgrade ATF BL2
      4. Upgrade ATF FIP
      5.   Upgrade ATF BL31 only
      6.   Upgrade bootloader only
      7. Upgrade single image
      8. Load image
      9. Start Web failsafe
You can choose whatever you want.
mtkupgrade
This command has one optional parameter:
mtkupgrade [part]
Part Description
bl2 Upgrade BL2
fip Upgrade FIP
bl31 Upgrade BL31 of ATF FIP
bl33 Upgrade BL33 (Bootloader) of ATF FIP
gpt Upgrade GPT for SD/eMMC
simg Upgrade single image (ROM dump), not recommended for use
If mtkupgrade is called without parameter, it will first ask you to choose a part:
Available parts to be upgraded:
    0 - ATF BL2
    1 - ATF FIP
    2 - BL31 of ATF FIP
    3 - BL33 of ATF FIP
    4 - Firmware
    5 - Single image

Select a part:
Just press a number to select a part.
Note: FIP contains both bl31 and bl33. bl33 is normally the bootloader, i.e. u-boot.bin here.
If you choose to upgrade bl31 or bl33, mtkupgrade will read FIP into memory, replace the bl31/bl33 of the FIP, and then write FIP back to flash.
After you select the part, or you just called this command with the part parameter, it will ask you to choose a transmission method:
*** Upgrading ATF BL2 ***

Available load methods:
    0 - TFTP client (Default)
    1 - Xmodem
    2 - Ymodem
    3 - Kermit
    4 - S-Record

Select (enter for default):
Again, press a number to select a method. You can also press enter directly to select TFTP client.
If you selected TFTP client, it will then ask you for some network configurations:
Input U-Boot's IP address: 192.168.1.1
Input TFTP server's IP address: 192.168.1.2
Input IP netmask: 255.255.255.0
Input file name: bl2.img
After all prompts above, this command will start to receive file data and then write it to the flash device:
Using ethernet@15100000 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.1
Filename 'bl2.img'.
Load address: 0x46000000
Loading: ##############
         94.7 KiB/s
done
Bytes transferred = 200888 (310b8 hex)
Saving Environment to MTD... Erasing on MTD device 'u-boot-env'... OK
Writing to MTD device 'u-boot-env'... OK
OK

*** Loaded 200888 (0x310b8) bytes at 0x46000000 ***

Erasing 'bl2' from 0x0, size 0x32000 ... OK
Writing 'bl2' from 0x46000000 to 0x0, size 0x310b8 ... OK

*** ATF BL2 upgrade completed! ***
mtkload
This command is similar to mtkupgrade, but only load data into memory.
mtkboardboot
This command will boot firmware according to configuration:
a) Bootmenu type is set to SD/eMMC:
Try to boot kernel from the partition named kernel defined in GPT.
b) Bootmenu type is set to MTD:
If both kernel and ubi partition exist, it will boot kernel from mtd partition kernel.
If only ubi partition exists, it will try to load and boot kernel from ubi volume named kernel.
If only firmware partition exists, it will boot kernel from mtd partition firmware.
httpd
This command will start a HTTP server listening on port 80. You can access to it to upgrade firmware image instead of using tftp.
8. Customization of U-Boot
After running defconfig command for u-boot, you can use menuconfig to modify the MediaTek-specific features:
Bootmenu
> MediaTek specific configurations > Enable bootmenu framework
Use default bootmenu: You can deselect this to use a customized bootmenu implementation (entries, command actions, ...).
Default bootmenu implementation file is:
board/mediatek/common/bootmenu_mmc.c
board/mediatek/common/bootmenu_mtd.c
board/mediatek/common/bootmenu_mtd_legacy.c (for MT7629, which uses only one bootloader)
Device type for bootmenu:
a) MTD (NOR/NAND/UBI): Based on mtdparts:
If both kernel and ubi partition exist -> Upgrade kernel to kernel partition, upgrade rootfs to rootfs vaolume in ubi partition.
If only ubi partition exists -> Upgrade both kernel and rootfs to volumes in ubi partition.
If only firmware partition exists -> Upgrade firmware image to firmware partition
b) SD/eMMC
If mmc device is eMMC -> Upgrade BL2 to boot0 hw partition.
If mmc device is SD -> Upgrade BL2 to bl2 partition defined in GPT.
Upgrade both kernel and rootfs to partitions defined in GPT.
Enable bootmenu countdown: You can deselect this to make u-boot stop booting on this menu. This is mainly used for debugging (Load by OpenOCD)
MediaTek bootmenu delay time: This is an idependent to standard bootmenu and autoboot. Specify the delay time for bootmenu displayed by mtkautoboot command.
Enable support for loading from SD card: When both mmc support, partition support and FS support are enabled, enabling this option will add a new file loading method for mtkupgrade command to support load file from SD partition.
MMC device index for SD card: The mmc device index of the SD card. 1 for mt7622, 0 for other chips.
Enable Web-based failsafe for firmware upgrading: When enabled, Web-based failsafe will start if mtkboardboot command fails. The bootmenu will also have an entry for starting Web-based failsafe.
Enable support for UBI-based images: Enable this option to allow mtkupgrade and mtkautoboot commands to deal with ubi volume and tarball sysupgrade image.
NMBM
> MediaTek specific configurations > Enable NAND bad block mapping management
Lower MTD device name: The raw nand mtd device. Currently spi-nand0 for all chips.
You should also define proper mtdparts described in next section.
MTD partition table
The bootmenu type MTD requires mtd partition table be defined properly.
> Command line interface > Filesystem commands
Default MTD IDs:
nor0=nor0 for SPI-NOR
spi-nand0=spi-nand0 for SPI-NAND without NMBM
nmbm0=nmbm0 for SPI-NAND with NMBM
Default MTD partition:
For SPI-NOR, firmware partition must be defined
For SPI-NAND + UBI: define only ubi partition if both kernel and rootfs are stored as ubi volumes; define both kernel and ubi partition if only rootfs is stored as ubi volume.
9. Customization of ATF
There are two sets of configurations:
a) The offset and size of FIP (for nor, or snand/spim-nand with NMBM=1):
All platforms have their own default FIP offsets and sizes.
You can override them by passing the following arguments to the make command:
OVERRIDE_FIP_BASE=xxx \
OVERRIDE_FIP_SIZE=xxx
b) The start and end addresses of UBI partition (for snand/spim-nand with UBI=1)
By default the start address of UBI partition is 0x200000, and its end address is 0, which means end of flash.
You can override the start address by passing the following argument to the make command:
OVERRIDE_UBI_START_ADDR=xxx
You can also override the end address by passing the following argument to the make command if OVERRIDE_UBI_START_ADDR has been set:
OVERRIDE_UBI_END_ADDR=xxx
10. Generating GPT data
A tool is provided in the ATF repo: tools/dev/gpt_editor
mtk_gpt.py requires python 2.7
A quick start command line:
python mtk_gpt.py --i <gpt-json> --o <output-gpt>
<gpt-json> defines each partition. Examples can be found in example folder.
<output-gpt> is the actual GPT raw data that can be written to the start of SD/eMMC data region, or be upgraded by mtkupgrade command.
Notes:
The only difference for SD and eMMC partitions is that bl2 partition does not exist for eMMC.
There is no limit for bl2 partition for SD cards of MT7981/mt7986. You can modify its start offset and size at will.
GPT for MT7622 SD
The GPT for MT7622 booting from SD is special:
Although we uses GPT, the bootrom of MT7622 actually uses MBR. And an additional limit is that the device header offset in BL2 header must match the real offset of BL2 in SD card.
One can generate valid GPT data for MT7622 SD, with the following steps:
Use the example file mt7986-sd.json to generate the initial GPT data
python mtk_gpt.py --i example/mt7986-sd.json --o GPT_SD
Use the start block num of BL2 to calculate device header offset:
 "bl2" : {
  "start": 1024,
  "end" : 8191,
  "attributes": 4,
  "uuid" : "{19a4763a-6b19-4a4b-a0c4-8cc34f4c2b8a}"
 },
So the start block of BL2 is 1024, device header offset is 1024 * 512 = 0x80000.
When compiling the ATF, pass DEVICE_HEADER_OFFSET=0x80000 to the make command line.
You can actually omit this if the offset id the default value 0x80000.
Use WinHex or other editor to add the second partition to MBR partition table:

* 7168 = 8191 -1024 + 1
Edit history
Date Description
2023/07/05 Update for new ATF release
2023/07/20 Update for new U-Boot release
2025/02/18 Update for new ATF/U-Boot release

13

[Assistant]
There's no such option.
The bootrom doesn't support booting from USB.

While would be hard to have uboot supporting the xhci?

I assumed it weren't. Is it enough to enable xhci support?


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Xiaomi AX3600 INT firmware

International version of AX3600 started popping up,
IPQ807x SoC Investigation / Status [WIP]
For Developers
sorry for offtopic just for the info AX3600 global version 100% confirmed
If You get one please try to extract firmware so we can try to flash it on CN version.
It can be done by going to
http://192.168.31.1/cgi-bin/luci/;stok=<stok>/api/xqsystem/check_rom_update
When update is pending, it should return url to update package

2

[Assistant]
{"needUpdate":0,"code":0,"status":{"status":0,"percent":0},"changeLog":"","version":"1.0.227"}
no url

Yeah, You have CN firmware and up to date, so You will not get nothing useful
We need someone with INT firmware which is out of date to use this method.
I am trying some tricks right now, maybe i will be succesful

2

You will not get anything useful if You are running Chinese firmware


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Building / Compiling OpenWrt ON OpenWrt - A Howto

[NOTE] This is now its own wiki article at: https://openwrt.org/docs/guide-developer/toolchain/building_openwrt_on_openwrt
The wiki page above is now more up-to-date than the instructions below.
It's been noted before that OpenWrt isn't self hosting. Well, with only a very few additions (but with a bunch of bug workarounds) it can be! My BPI-R64 running snapshot just made its own build. This was a learning experience about the OpenWrt build system, and it exposed a LOT of bugs in things like LLVM, musl, perl, and in OpenWrt itself. But it was fun. This is still, of course, experimental. But I'll go into the steps you can use to replicate this:
First: Why Build OpenWrt on OpenWrt?
Becoming self-hosting is an important milestone for any OS
It makes building OpenWrt more accessible for those with less resources.
Continuously building on a mono-culture (x86-based full blown Linux systems) lets a lot of bugs slide under the radar. Building on a different system can (and did) expose a lot of issues.
For the brownie points of knowing (or bragging) that the OS on your device was BUILT on your device.
Hardware Requirements
Device with 1GHz+ CPU, preferable dual core or better
512MiB RAM per core you intend to use**1
2GiB swap space on non-built-in storage (sd card if your playform supports it, or USB stick) **2
2GiB of space on whatever your rootfs is
~26GiB storage space for the build, **2
Note1: Building on 64-bit systems is more RAM-hungry than building on 32-bit systems. You can get away with a little less ram-per-core on 32-bit systems. You can also get away with a little less ram-per-core if you can use a pre-built LLVM.
Note2: This should be a fairly good quality storage device. Certain steps in the process will be somewhat heavy on the swap. A good quality storage device will handle the wear better. A larger storage device will spread the wear more.
Setting Up The Dev Environment
You need a whole lot of packages:
Some good-to-have packages to make life easier:
opkg install joe joe-extras bash htop whereis less file findutils findutils-locate chattr lsattr wget-ssl xxd
The dev tools themselves:
opkg install pkg-config make gcc diffutils autoconf automake bzip2 check git git-http patch libtool-bin
Perl:
opkg install perl perlbase-findbin perlbase-pod perlbase-storable perlbase-feature perlbase-b **3
A bunch of coreutils, since busybox versions aren't good enough in some cases, or aren't there:
opkg install coreutils-nohup coreutils-install coreutils-sort coreutils-ls coreutils-realpath coreutils-stat coreutils-nproc coreutils-od coreutils-mkdir coreutils-date coreutils-comm coreutils-printf coreutils-ln coreutils-cp coreutils-split coreutils-csplit coreutils-cksum coreutils-expr coreutils-tr coreutils-test coreutils-uniq
Other miscellaneous tools:
opkg install grep rsync tar python3 getopt procps-ng-ps gawk sed xz unzip gzip flock
A few libs:
opkg install libncurses-dev zlib-dev musl-fts
We need a softlink for libncurses:
ln -s libncursesw.a /usr/lib/libncurses.a
Note3: My system had a lot of perl installed already, so there may be more perl packages necessary that aren't listed here.
Before we can go further, we have a few Initial bugs to fix:
OpenWrt Bug: OpenWrt doesn't put execute permissions on the scripts for the automake, autoconf, and libtool packages. This prevents a lot of build systems from working correctly. To fix:
chmod +x /usr/share/automake-1.16;chmod -x /usr/share/automake-1.16/COPYING /usr/share/automake-1.16/INSTALL
chmod +x /usr/share/autoconf/Autom4te/*
chmod +x /usr/share/libtool/build-aux/*
Now we can install the three dev libraries that OpenWrt doesn't support. One of them is included in OpenWrt as a non-dev library, but it's stripped in such a way as you can't compile against it. These three libs are all to support GNU LIBC extensions that musl doesn't have and are required mostly for elfutils. Switch to your ~/devel folder (or wherever you're going to use to build things) and do the following:
libargp:
git clone https://github.com/xhebox/libuargp.git
cd libuargp
make
make prefix=/usr install
ln -s libargp.so /usr/lib/libargp.so.0
cd ..
libfts: We installed the non-dev version above already, so this will overwrite it with one that can be compiled against. We installed the non-dev version first so that it doesn't get installed later and overwrite your dev version with a lobotomized one:
git clone https://github.com/void-linux/musl-fts.git
cd musl-fts
./bootstrap.sh
./configure --prefix=/usr
make
make install
cd ..
libobstack:
git clone https://github.com/void-linux/musl-obstack.git
cd musl-obstack
./bootstrap.sh
./configure --prefix=/usr
make
make install
cd ..
Now a few more bug fixes and issue workarounds:
OpenWrt Workaround: Not a bug per se, though one might call it a bug by omission. The bzip2 binary also acts as bunzip2 and bzcat, but it can only do so if the proper softlinks are made when it's installed, which the OpenWrt package doesn't do. So:
ln -s bzip2 /usr/bin/bunzip2
ln -s bzip2 /usr/bin/bzcat
Elements of the build system don't like to be built as root. OpenWrt is essentially single-user, so to get around this:
export FORCE_UNSAFE_CONFIGURE=1
You might want to add the above to your ~/.profile
Speaking of .profile, I use bash as my shell. I suspect that the busybox Ash isn't good enough for some of the scripts in the build system, so I recommend installing bash and setting it as your /bin/sh
opkg install bash (already included above)
ln -sf bash /bin/sh
The rest of the bug workarounds, and the installation of the one tool we're still missing are all done in the OpenWrt source tree itself. So let's get it:
Get and Build OpenWrt
This is based on the wiki instructions, with a bunch of deviations to fix various bugs.
Make sure you're in your devel directory.
First the preliminaries:
git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
git checkout master
git pull
./scripts/feeds update -a
./scripts/feeds install -a
Get the config file for your architecture and save it as .config. For me (BPI-R64) it is this:
wget https://downloads.openwrt.org/snapshots/targets/mediatek/mt7622/config.buildinfo -O .config
Configure your build:
make defconfig
make menuconfig
Things to change in the config: set it up to build for only your platform, read the next step below about LLVM and configure whether or not you're going to use a pre-built one, and then make any other tweaks you normally do.
EITHER get a pre-made LLVM (preferable)...
Compiling LLVM is the single most time and resouce-intensive step in the whole process. It can easily take two days by itself. I have so far built it on two platforms: aarch64 and armv7l. If you have one of those platforms, you can grab my pre-made LLVM and untar it into the openwrt build folder. If not, you will have to...
...OR Build LLVM
BE CAREFUL HERE! Early in my experiments I burned out a Sandisk Extreme 64GB microSD card because I did a multi-core build and the memory requirements to build LLVM pushed the system so far into swapping that it did about 18 hours of non-stop writes. A single-core build will take a long time, but is safer. This is going to take a long time, so best use nohup in case you get disconnected - you don't want compilation to stop. And start getting into the habit of using V=sc and logging everything, because this whole process is still experimental:
nohup nice -10 make -j 1 V=sc tools/llvm-bpf/compile > ~/llvmcomp01.out &
Periodically check htop to make sure it is going well, and check the log when it stops. Hopefully there's no error, but if there is, welcome to the experiment. Debug, rinse and repeat and report it here for the rest of us.
Now we build the rest of the toolchain. Now that LLVM is out of the way, if you have multiple cores and enough RAM per core, then you should be ok to use multi-core compiling. Keep an eye on it, though and htop is your friend here. I am still going to put -j 1 in all the copy/paste commands for safety - but feel free to up the core count at your discretion.
nohup nice -10 make -j 1 V=sc toolchain/install > ~/toolchain01.out &
Now that the toolchain is done we can do a make download. A bug in qosify's makefile prevents make download from working before the toolchain is complete in some cases.
make download
We will now build the last tool we're missing: rev, which is a little-known and littler used unix tool found in util-linux. OpenWrt doesn't make a package out of it, even though it's built, so we're going to build util-linux then copy it out. This is quick, prolly no need to log it:
make -j 1 package/util-linux/compile
cp $(find . -wholename \*ipkg-install/usr/bin/rev) /usr/bin/rev
Now we're going to fix some bugs. One which causes a problem with perl on musl, one where recent compilers cause a seg fault, and one in Perl's Configure script itself. Fort this we need two patches. The first patch we will apply directly:
( cd feeds/packages/lang/perl && wget https://va1der.ca/~public/perl_fix_memmem_and_segfault.patch -O - 2> /dev/null | patch -p 1 )
That fixes the first two bugs. The next fixes the Perl bug, and we're just going to download and store it in the OpenWrt build system and let OpenWrt sic it on Perl when it builds it.
wget https://va1der.ca/~public/997-fix-Configure-gcc-parse.patch -O feeds/packages/lang/perl/patches/997-fix-Configure-gcc-parse.patch
Now we test to see if your OpenWrt build is actually affected by one of the above bugs. Some are (mine was), and if it is, we're going to have to build perl right now with the above patch to fix your existing system, because the host system's perl is used when OpenWrt builds openssl. Download and run the script:
wget https://va1der.ca/~public/test_index.perl -O ~/test_index.pl
chmod +x ~/test_index.pl
~/test_index.pl
It will tell you if your perl is affected by the index() bug. If it is then...
We build perl with our bug patch above and copy libperl.so over top of of the buggy one:
make -j 1 package/perl/compile
cp $(find staging_dir -name libperl.so) /usr/lib/perl5/5.28/CORE/
~/test_index.pl
The test should now show the index() bug is fixed
Now we can make the rest of the build. This is likely to take a while (not as long as LLVM though). I recommend using nohup and V=sc and redirecting to a log:
nohup nice -10 make -j 1 V=sc world > world01.out &
Other Issues
A couple other minor issues I ran into in my experiments:
Lately some snapshot packages of perlbase-b included a bad /usr/lib/perl5/5.28/auto/B/B.so that referenced a wrong symbol. I found that this was only in the package delivered by opkg - if you build it yourself the library seems fine.
There is a bug in LLVM that makes libatomic need to get linked in to libLLVM.so, but then the LLVM build doesn't add it when it builds the rest of the package. You end up getting link failures. This only shows up on armv7l, I believe. I think you can get around it by usinv my LLVM above. I haven't gone as far on armv7l yet, though (just to the end of the toolchain).
On Errors
The above procedure Works For Me™. But this is very much an experimental process. By the time I was done, I was up to world13.out on two different platforms. I tried to document everything I did, but I may have missed packages. And there may be other subtle issues on other architectures. When htop tells you compilation has stopped, look at the log. Jump to the end, then (if you were doing multi-core builds) search backwards for "Error" (capital E) to find what actually went wrong. Most of the time it's a missing tool. Feel free to post your results here.
SUMMARY
There are a number of bugs that were exposed. Bugs in OpenWrt, Perl, LLVM, and other places. But I don't consider the presence of bugs the deciding factor on whether a system is, in general, self-hosting. OpenWrt needs one small utility (rev), and three bandaid libs to cover for GNU extensions to GLIBC. That makes OpenWrt about 99.9% self-hosting ready. This is a great achievement, especially for an embedded OS where self-hosting wasn't even the goal, and more especially considering the enormous amount of complex code and a build system that uses so many different build tools. The OpenWrt devs are to be greatly commended for an excellent embedded OS!

15

[Assistant]
Such great timing! I recently acquired one of those Changwang Intel N5105 4x2.5Gbps boxes as an experimental/dev router. Yesterday I was thinking to myself, "I'm only using like 150M of the 250G drive and this thing has a ton of horsepower, I wonder if I could set up an OpenWrt build system on OpenWrt?" I am definitely going to try out your recipes here.

2

efahl:
N5105 4x2.5Gbps boxes as an experimental/dev router.
And
[...] this thing has a ton of horsepower
That's pretty much mutually exclusive. Sure, it's more powerful than your average consumer MIPS router, but it's still a gutted x86 CPU. Of course, if you want to use it as your router and compiler farm... Have at it, I'd say.
@VA1DER
What I'm missing is how long it took to compile everything?

2 Replies
2

Borromini:
how long it took to compile everything?
About 18 hours for the toolchain. After that, the actual image "only" takes about 5 hours.
Borromini:
if you want to use it as your router and compiler farm... Have at it, I'd say.
I'm 52. I grew up with Apple ][s and cut my teeth using 6502 assembly to turn the PIO user port of CBMs into serial ports for my first BBS modem. I still remember as a project manager deploying a huge process control server for Canadian Autoparts Toyota. It had a (then) massive 768MB of RAM. I remember saying "three quarters of a gigabyte" over and over to myself. I remember when "DEC Alpha" was spoken with reverence. And now my router, in every aspect, is more capable than those machines.
So yes, even though I have a laptop that could probably walk on water, I still tend to look at routers differently. There is a ton of stuff they can do, and I don't tend to discount them as junk.
And there are still places in the world where cheap consumer grade hardware like a router is the best computing equipment available.
Besides, it's FUN.

2 Replies
5


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: New WireGuard based OpenWrt VPN implementation: unetd

Hi,
I've made a new WireGuard based VPN implementation called unetd. My goal was to make it as easy as possible to link up multiple OpenWrt based routers (or Linux servers) and provide a fully-meshed VPN (all peers talk directly to each other) that can properly deal with NAT inbetween. It also supports automatically creating a VXLAN tunnel (if requested) and properly deals with issues from reduced MTU.
You can find an overview and documentation here: https://openwrt.org/docs/techref/unetd
It also provides some example commands which show that it's possible to create a new VPN two routers in 5 commands securely without having to worry about generating and distributing keys.
It automatically exchanges endpoint information and distributes VPN config updates between all member nodes.
Since it uses WireGuard, you can expect it to have really good performance.
At the moment it needs at least one of the hosts to be reachable via public IP, but I'm working on removing that limitation by using a DHT for node discovery.
It's still fairly new and only in OpenWrt master so far, but it should be easy to backport to 22.03.
If you're already using WireGuard, OpenVPN or some other VPN implementation, I'd be very interested to hear if unetd would cover your use cases as well, or if there is something missing that should be added.

30

[Assistant]
thanks
@nbd
a function of the hybrid vpn of netduma allows to rotate the ports like that to its vpn to establish the connection to server
is it possible to do it with this one ? thanks
with openvpn i'm use files

At the moment, rotating ports is not supported. What’s the use case for it?

MatchMake VPN For Consoles - NetDuma & NightHawk Setup Guide
I use it to connect to game servers I send you the video link only with netduma
with OpenWrt the localization is well truncated but the game doesn't connect to the servers here is the link
in openvpn I have the start in red that engages,
I can make all vpn work in principle but this vpn not
video at 1"30


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Adding OpenWrt support for Xiaomi AX3600 (Part 1)

...which is presumably IPQ8071. More information expected during during Mi 10 launch on Feb 13th.
I hope we will get relatively affordable high-end device which has good chances of being supported by OpenWRT.
Gizmochina – 10 Feb 20
Xiaomi's upcoming AX3600 Wi-Fi 6 router is based on Qualcomm's enterprise...
Xiaomi has finally confirmed that it will announce its new Wi-Fi 6 router, the Xiaomi AIoT AX3600 at the Xiaomi Mi 10 online launch event on February 13. The existence of this router was first revealed by Digital Chat Station a couple of days back....

14

[Assistant]
Do you want to actively help in getting this (not even available) device supported?
If yes, can you please change the topic title to "Adding OpenWrt support for AX3600"?

1

I guess Xiaomi would not allow SSH access for this router too. So without open the case it's impossible to flash a third-party firmware.

1 Reply

Some more info: price is 599 CNY (~$86) in China.
SOC: Qualcomm IPQ8071A (Quad core A53 @ 1 Ghz + 2x 1.7 Ghz network acceleration cores)
RAM: 512 MB
ROM: 256 MB
Antennas: 2x 2.4GHz + 4x 5GHz + 1x "IoT antenna"
PSU: 12V 2A
Gizchina.com – 13 Feb 20
Xiaomi AIoT Router AX3600 Announced At 599 Yuan ($86)
Apart from the Xiaomi Mi 10 series smartphones, the manufacturer also released a few other amazing products, including the Xiaomi AIoT Router AX3600.

https://detail.tmall.com/item.htm?spm=a220m.1000858.1000725.1.71da2af3n03NdC&id=612191379924&skuId=4482074859923&user_id=1714128138&cat_id=2&is_b=1&rn=dc044fb527622126adedfa6e1340ad4c

1