john9527
Part of the Furniture
That's two....same error I had (and same solution)
ARM toolchains with NPTL for Asuswrt/Merlin
- Thread starter kvic
- Start date
Thanks for this. I incorporated a fix for Tomato build compatibility. It's not affecting asuswrt or merlin build before and after.
sys root/usr/include/netinet/in.h and ChangeLog.
At the moment both Ubuntu 12.04 64bit & Debian Jessie 64bit have this error. Linux Mint 13 "Maya" 64-bit and Debian Wheezy 64bit doesn't.
I thought ASUS is heavy weight enough to overrule some of Broadcom's design decision...
Some of the components are compiled by Broadcom, and provided as-is to their customers. And if Asus wants to get any tech support from Broadcom, I suspect BCM will require them to use the original toolchain as provided.
And there are also the components compiled by Tuxera or Trend Micro. Any toolchain change would require to also have all their partners get the new toolchain.
sfx2000
Part of the Furniture
Generally no... low level stuff is usually from the chip provider, in a form that is close to launch..
Asus can integrate (same as other vendors)..
at the end of the day, it's how much effort the chipset vendor/vendors is willing to put in to the total effort to launch and support a product...
I was performing some torture tests on my AC56U for the sake of having a better understanding of this beloved little all-in-one router..
I found that I have to use Trend Micro's DPI for adaptive QoS. Or else I can barely browse the internet during prolonged tests. Traditional QoS is out of question because I decided to have CTF always on.
The thing I want to share is "wred" seems not essential in Adaptive QoS.
When Adaptive QoS is enabled, other than DPI kernel modules loaded, four user space processes come into play: bwdpi_wred_alive, data_colld, qosd and wred.
bwdpi_wred_alive is simply yet another watchdog* which monitors and re-starts the other three programs in case they crash for whatever reason. Since wred always crash using this new build root, I simply kill off bwdpi_wred_alive after boot. I don't notice any observable loss of functionality on adaptive QoS.
During my torture tests, I have over 10,000 NAT'ed iperf streams between one LAN host and another external host in the cloud. These 10,000 streams saturated my 100Mbit/s WAN, and fully load CPU 1 (if u count from 1) all time. Suprisingly data_colld and qosd barely consume any CPU cycles under such condition and give me a much more pleasant net browsing experience than without any QoS.
Most likely adaptive QoS is here to stay for me.
*It's quite funny on ASUS's part..there are so many watchdogs in ASUSWRT. They even have a watchdog on watchdog... I guess their R&D is clueless of some random crashes reported by customers..hence so.
Fitz Mutch
Senior Member
Does ASUS or Broadcom publish the Buildroot 2012.02 configuration file ".config" used to build the ARM toolchain ?
I think not in the sense as the one you see in its linux kernel source. There might be ones for the toolchain. If there are, you can find in the buildroot's tarball inside Asus GPL tarball.
Frankly I can't recall...if you want to work with newer libraries, move to Entware-ng. Its pthread library appears to be newer and much better.
Asus has included the buildroot tarball on occasion in their GPL releases, but I never checked to see if it contained the whole config info. When it's included, it's located in release/src-rt-6.x.4708/toolchains/hndtools-arm-linux-2.6.36-uclibc-4.5.3/src .
I'll upload it to https://www.mediafire.com/folder/ftf9kjixr1a5f/Misc in a few mins (I don't include it on Github because it's too big - would require LFS).
I'll upload it to https://www.mediafire.com/folder/ftf9kjixr1a5f/Misc in a few mins (I don't include it on Github because it's too big - would require LFS).
Last edited:
sfx2000
Part of the Furniture
going back to pthreads and asuswrt - there was issues with certain revisions of the Cortex-A9 that pthreads enabled could cause corruption and data aborts in corner cases
Broadcom likely opted to do the safe approach to cover all bases and intended use cases in their SDK. Esp. with the older kernel and toolchain back in the day.
Just my thoughts here...
Broadcom likely opted to do the safe approach to cover all bases and intended use cases in their SDK. Esp. with the older kernel and toolchain back in the day.
Just my thoughts here...
Fitz Mutch
Senior Member
After compiling and linking Transmission-daemon against AsusWRT, it seems to be running as multiple processes. Under Entware-ng, there is only one Transmission-daemon process. I'm just trying Transmission/uClibc for better performance on my RT-AC68U with Asuswrt-Merlin. So now I'm looking at the Buildroot 2012.02 ARM toolchain to explain why Transmission-daemon is multiple processes when compiled against AsusWRT.
Fitz Mutch
Senior Member
Thank you. This file appears to be the .config to built the ARM toolchain for AsusWRT ?
dl_save/defconfig-arm-uclibc
Fitz Mutch
Senior Member
In the AsusWRT firmware there is a file /lib/libpthread.so.0. Do you happen to know if it is a good pthreads library?
Don't know, I never really looked at it. Last time I messed with a toolchain was back in the MIPS days, and I scrapped my whole plan as it brought more issues than anything. I guess there's always a chance Broadcom might have used a customized version of that config file. I guess you'll have to experiment with it.
If you're using my build of the toolchain, you shall get native pthread otherwise you will see processes as you did. they're known as linuxthread very very old tech.
If you'r using my build of the toolchain but still see linuxthread, then check if you're actually copying the correct uClib and pthread lib from the right toolchain's directory.
I suspect somewhere in your surgery..you're copying old files from the original toolchain...
Fitz Mutch
Senior Member
I ran out of time trying to compile the toolchain myself. Now I'm rebuilding the firmware with your toolchain.
However, there's a problem with the host libraries and your toolchain. My OS is Ubuntu 16.04 LTS 64-bit.
Code:
awk: symbol lookup error: awk: undefined symbol: mpfr_z_sub
/tmp/GmRElg1V:1119: recipe for target 'modules.builtin' failed
make[4]: *** [modules.builtin] Error 127
make[4]: Leaving directory ' /home/rob/asuswrt-merlin/release/src-rt-6.x.4708/linux/linux-2.6.36'
Makefile:1006: recipe for target 'kernel' failed
make[3]: *** [kernel] Error 2
make[3]: Leaving directory ' /home/rob/asuswrt-merlin/release/src/router'
Makefile:202: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory ' /home/rob/asuswrt-merlin/release/src-rt-6.x.4708'
Makefile:2816: recipe for target 'bin' failed
make[1]: *** [bin] Error 2
make[1]: Leaving directory ' /home/rob/asuswrt-merlin/release/src-rt-6.x.4708'
Makefile:2886: recipe for target 'rt-ac68u' failed
make: *** [rt-ac68u] Error 2Updating the libs fixed it. I had this same problem when trying to compile the Buildroot 2012.02 ARM toolchain myself, except it was the 'gawk' program causing the error. Same fix though.
Code:
cp -pdv /usr/lib/x86_64-linux-gnu/libmpfr.* /opt/brcm-arm/lib/Just waiting for my firmware build to finish, then we will see if those multiple processes are Linux threads.
Fitz Mutch
Senior Member
Yes, I had to update an environment variable RTVER in this file, ~/asuswrt-merlin/release/src-rt/platform.mak. And the Beceem_BCMS250_arm with prebuilt librt.so had to be updated too.
Unfortunately, your build of the toolchain, I had issues with some custom programs. Transmission-daemon wouldn't start up and nothing in the syslog about it. And Cryptsetup got a segfault when I tried mounting an encrypted disk. Normally it runs fine on AsusWRT and Merlin. However, a statically linked version of Cryptsetup worked just fine with your toolchain. I had a similar issue with running Tomatoware on Asuswrt-Merlin, on the RT-AC68U, with Cryptsetup, where only the statically linked version worked and the one with dynamically linked libraries did not. The problem was happening somewhere down in the device mapper library. Never did figure it out.
Last edited:
Similar threads
- Locked