MerlinWRT - compile instructions?

[RMerlin]

@RMerlin The build completed successfully, but QoS doesn't work. I used the latest master merlin.ng source straight out of the git repo, no extra patch or mod. So was it because of the recent code changes or is there patch needed for it to work?

Which QoS? There are four different QoS modes.

 

[jerrytouille]

Which QoS? There are four different QoS modes.

The default Adaptive QoS and flexqos fq_codel. Also I notice the TrendMicro signature update check is not there vs. your build so was thinking got to do with special TrendMicro hook or something

I didn't check the other/traditional, also cake's not avail for rt-ac68u

 

[RMerlin]

The default Adaptive QoS. Also I notice the TrendMicro signature update check is not there vs. your build so was thinking got to do with special TrendMicro hook or something

That's normal. Since 386, Asus were forced to take new measures due to repeated abuse from illegal firmwares such as Xvortex and Koolshare who kept ignoring the licensing terms of the Trend Micro components, and were implementing them on non-Asus routers. People downloading sources and building firmware images from my repo will no longer have working Trend Micro components, only the firmware images that I build myself will have it working.

This was the compromise so I could still be able to fully support Trend Micro components.

 

[jerrytouille]

@RMerlin totally understand. Maybe put that (TM components/qos wouldn't work for private builds) disclaimer in the wiki or something. Thanks for your help, and all your work.

 

[ptr1337]

I could create a docker image, which can be used on any machine x86_64 and arm64. Also include some "helpers" for easy compiling.
The only dependecies which needed are docker and docker-compose. Then one single command and the container is running with all dependecies.

edit:
ill creating a test container and build a firmware. if its worked ill create the docker image

 

[ptr1337]

@RMerlin

Is there any reason to use these old aarch/armv7 cross compilers?
Personally i would go for a arm cluster and using distcc. Then the firmware build would be much cleaner. Native compiling is every time much cleaner then cross compiling.
with like 4 differnt sbc in a cluster, it would be probally faster then with a gaming rig.

And also the documentation for compiling the firmware need much rework. Do you have anywhere actual list, which got al dependecies in ? most builds failed because a missed tool.

But finally its done. Seems to work.
Now i will create the dockerfile and docker-compose.yml. Then ill test a compile one more time, then i will push it on the dockerhub.
Everything will be included, and i also create "scripts" for changing the compilers for the needed models.

If someone want to test the image, would be nice.
Here you can download it:

archl/asusmerlin • Arm-Image-Builder Fileserver

Here you will find some prebuilt images and kernels.

arm-image-builder.xyz

Regards

 

[RMerlin]

Is there any reason to use these old aarch/armv7 cross compilers?

They are the toolchain provided by Broadcom, and this is what was used to compile the existing precompiled pieces.

And also the documentation for compiling the firmware need much rework. Do you have anywhere actual list, which got al dependecies in ? most builds failed because a missed tool.

The WSL2 article which I wrote should be the most up-to-date, as it's what I reproduced last year in my WSL2 tests.

 

[ptr1337]

They are the toolchain provided by Broadcom, and this is what was used to compile the existing precompiled pieces.

The WSL2 article which I wrote should be the most up-to-date, as it's what I reproduced last year in my WSL2 tests.

These one or ?
https://github.com/Broadcom/stbgcc-6.3/releases

Switched now to ubuntu:18.04 as base image, the compilation is running much cleaner. my bad.
Doing a test comile now and flash it. if everything is working, i will upload the docker image into the dockerhub.

Would be nice if you yourself test it and prove that everything is correctly working, if you got the time for it.

 

[RMerlin]

These one or ?

Whichever one Broadcom supplied to Asus along with the whole SDK. The toolchain changes between SDKs, as SDKs use different versions of the kernel, different libc implementations, etc...

Would be nice if you yourself test it and prove that everything is correctly working, if you got the time for it.

If the firmware builds and boots correctly and you haven't made any change to the code or the build profile in target.mak, then you're good. Only the Trend Micro related features will not work properly.

 

[RMerlin]

If you want a "clean" starting point to build under Ubuntu 20.04, refer to the WSL2 page that I wrote on the Wiki. It was written only last year, and it should contain the complete instructions for setting up a new 20.04 environment - just skip the WSL2-specific portion at the start.

Personally I use 20.04 for my development, under VMWare Player.

 

[ptr1337]

If you want a "clean" starting point to build under Ubuntu 20.04, refer to the WSL2 page that I wrote on the Wiki. It was written only last year, and it should contain the complete instructions for setting up a new 20.04 environment - just skip the WSL2-specific portion at the start.

Personally I use 20.04 for my development, under VMWare Player.

Thanks for your answer.
Mostly just got some problems with which enviroment for the right compiler.
Im trying to create a script which mostly automaticly do everything.
For example right now, if the container is downloaded and your exec into it, there are several scripts to execute.
Im not so famillar with your compilers right now, thats why i need some time. :x

Right now, it pulls both repos, create a backup with rsync. and linking the basic enviroments. and a simple stupid script for pulling or resetting the complete pulled repo.
Options which i want to include are with make commands; are like "make rt86u" is automaticly linking to the correct dir and creates the firmware and move it to the mounted directory, which is where you start the container.

If you get little bit familar with docker, its mostly a great solution. im writing a readme right now also. with the readme could everyone create a firmware, also who isnt familar with docker.
if i feel like its production ready, i will post it here.

 

[RMerlin]

Im trying to create a script which mostly automaticly do everything.

There's already one:

amcfwm - AsusWRT-Merlin Custom Firmware Manager

amcfwm AsusWRT-Merlin - Custom Firmware Manager Inspired By @RMerlins Original Script Features Can configure default Ubuntu 20.04 VM Interactive menu Configurable settings No hard-coded settings/variables Daily build cronjob if git changes detected POSIX compliance Installation This...

www.snbforums.com

 

[jerrytouille]

@RMerlin will AiMesh work for private builds? Not sure if it's part of TrendMicro components...

 

[RMerlin]

@RMerlin will AiMesh work for private builds? Not sure if it's part of TrendMicro components...

AiMesh will be fine, yes.

 

[jerrytouille]

@RMerlin Is there a way (like flags) to disable/remove all the TrendMicro components from the build (since it won't work anyway)?
The result would be like a mini or lite build. Maybe we can call it "merlin-lite"

 

[RMerlin]

@RMerlin Is there a way (like flags) to disable/remove all the TrendMicro components from the build (since it won't work anyway)?
The result would be like a mini or lite build. Maybe we can call it "merlin-lite"

Not possible unfortunately, as a lot of prebuilt components are compiled with bwdpi enabled, so it`s impossible to disable it globally.

 

[jerrytouille]

Not possible unfortunately, as a lot of prebuilt components are compiled with bwdpi enabled, so it`s impossible to disable it globally.

Thanks. I guess withdraw button is the only option :/

 

[ptr1337]

I have just created a Docker Image, which automatically got all needed dependencies.
You can run after pulling and running the container the ac86u.sh script which pulls the GitHub Repo's for the Toolchains and the firmware and set up the toolchains.

Only tested right now for the AC86U and is running fine.

GitHub Repo with more Instructions:

GitHub - ptr1337/asus-merlin-wrt-docker-builder

Contribute to ptr1337/asus-merlin-wrt-docker-builder development by creating an account on GitHub.

github.com

DockerHub:

Docker

Feel free to create a issue or a PR.

Regards

 

[dave14305]

It’s a lost cause trying to compile Merlin firmware anymore (IMO) since his repo is missing critical proprietary files from Asus to allow the Trend Micro components to work in a user-compiled firmware.

 

[man_with_the_stick]

Hi,

I have tried to build the ASUSWRT Merlin firmware from sources for the RT-AC86U router using the docker image. The build was successful, but there's one thing that intrigued me. I haven't watched the entire build process, but the pieces of software I've watched building were using arm-linux-gcc or arm-linux-g++. That meant all the tools were built for 32 bit ARM (armv7) instead of 64 bit ARM (aarch64). I thought there was an environment configuration error and I have downloaded busybox and some other tools from my router to check them with readelf. Readelf displayed ELF32 format and ARM machine meaning the executable binaries were indeed 32 bit programs. The router was using the original ASUSWRT Merlin 386.5_2 firmware, so I think the way I have built the firmware is pretty much the same as the one used on the official build servers.

In the build documentation there's nothing related to this issue. I don't know I should call it this way, but since the router platform uses a 64 bit SoC I wondered why the tools were 32 bit programs and the kernel was 64 bit. I have searched on the internet for ways to build the firmware with the aarch64 tools, I haven't found any satisfactory result but I have found this thread.

Consequently, is the 32 bit ARM the intended target? How can we build for aarch64?