Add support for Asuswrt-Merlin/HND platform (Asus RT-AC86U)

[RMerl]

On the Broadcom HND platform, the /opt directory is no longer just a symlink to /opt/tmp/. Instead, Broadcom creates multiple separate symlinks within /opt for all directories, that points to sub-folders within /tmp/opt (i.e. /opt/bin is a link to /tmp/opt/bin, etc...). They do that because they create their own /opt/scripts directory in the rootfs to store a few scripts.

I have modified entware_install.sh (and Asuswrt-Merlin's entware-setup.sh) scripts. HND has an aarch64 kernel architecture (but userspace still runs armv7l), so this is used (along with uname -o) to properly detect an Asuswrt-Merlin HND platform, and handle it as a special case of armv7l. This special case will create directories within /tmp/opt instead of /opt, so directories get created at the remote end of each separate symlinks created by Broadcom/Asus.

Reference to the modified install script (I am temporarily including it in the firmware):

https://github.com/RMerl/asuswrt-merlin.382/commit/91ee9b123f9e23a03108c92bcd0bd5004848c601

I have only done tests under HND yet - I haven't tested for any regression on regular armv7 platform.

Possible options:

1) Use the modified script for armv7, so it can handle both armv7l and HND/aarch64 2) Provide a separate aarch64 script, that would still use the armv7l packages 3) Modify the Broadcom SDK so it reverts back to its original "global" symlink of the whole /opt

Option 3 worries me because it could break down the road if Broadcom/Asus make more extensive uses of the /opt/scripts/ location. I propose going with 1 or 2 instead, so I'm submitting the modified entware_install.sh script for inclusion in the repo (either as a separate aarch64 script, or an enhanced armv7 script).

[RMerl]

Additional reference:

https://github.com/RMerl/asuswrt-merlin.382/commit/4831e7c4312d0b75b8e0b65d396c3349cd04cf4c

This commit is within the script in Broadcom's SDK that creates the /opt filesystem. I added the missing /opt/var symlink.

[zyxmon]

@RMerl - FYI There is Entware fork - https://github.com/Entware-for-kernel-3x It has more packages. Some packages are newer then in Entware-ng. Installation scripts - http://entware-3x.zyxmon.org/binaries/armv7/installer/ Armv7 repo - http://entware-3x.zyxmon.org/binaries/armv7/ Entware-3x and Entware-ng are updated together at the same time. IMHO It is preferable to use this repo for new kernels.

PS There is also Entware-3x fork for cortex-a15 compiled with -O3 and neon support that is 20-30% faster on some tests. It was made for qualcomm arm chipset by one of the netgear router users.

[RMerl]

Thanks. I will have to do some tests with it to see if it works well with HND's 4.1 kernel.

Not sure I like the idea of supporting different repos for different router models tho. I'll take a look at it over the weekend.

[RMerl]

The entware_3x setup does not work too well with Asuswrt's HND setup, as its packages try to create new directories inside /opt - which fails due to how Broadcom is implementing the binding mount.

I will have to evaluate how much efforts and risks would be involved in reverting the /opt filesystem setup to be similar to previous Asuswrt platforms.

[zyxmon]

The current second level (/opt is 1st level) directory structure is

bacula
bin
eggdrop
etc
home
html
include
lib
libexec
root
sbin
share
tmp
usr
var

In Entware-ng there are no home and root directories. May be it will help.

[RMerl]

I don't like the fact it force install Busybox, AND it puts the /opt/bin at the start of the PATH. This will cause it to override the firmware's own applets, which are often customized for the firmware's own needs. This carries a high risk of breaking things within the firmware's own environment.

[zyxmon]

In your custom installation you can put /opt/bin at the end of PATH (probably this will be changed in entware-3x also) and do not install busybox. In many cases Entwares's busybox fixes firmware's applets.

[zyxmon]

@RMerl

and HND/aarch64

Can you give more info - what chipset used on asus routers supports AARCH64? What about floating point support? Cortex-a53? There are some plans to build native aarch64 Entware version (for Realtek RTD129x NASes). Probably broadcom aarch64 can be also supported.

[RMerl]

GT-AC5300 and RT-AC86U use the BCM4908 and BCM4906 CPU (one is quad-core, other is dual-core). These are based on a B53 core (which is Broadcom's modified COrtex-A53).

While the kernel uses aarch64, userspace still uses armv7, probably to save up on RAM. That doesn't prevent running native aarch64 code however, as long you don't rely on the armv7 libraries.

Here are the supported CPU features:

admin@Stargate86:/tmp/home/root# cat /proc/cpuinfo
processor   : 0
BogoMIPS    : 100.00
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x42
CPU architecture: 8
CPU variant : 0x0
CPU part    : 0x100
CPU revision    : 0

processor   : 1
BogoMIPS    : 100.00
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x42
CPU architecture: 8
CPU variant : 0x0
CPU part    : 0x100
CPU revision    : 0