ARM toolchains with NPTL for Asuswrt/Merlin

[john9527]

ctype.h line 73:
extern int isblank(int __c) __THROW;

In asus`s toolchain this line is commented, well i commented it:
//extern int isblank(int __c) __THROW;

That's two....same error I had (and same solution)

 

[RMerlin]

The toolchain indeed comes directly from Broadcom, and is untouched AFAIK by any of their customers.

 

[kvic]

next compilation stopped on miniupnpd
natpmp.c: In function ‘ReceiveNATPMPOrPCPPacket’:
natpmp.c:211:36: error: dereferencing pointer to incomplete type
natpmp.c:212:15: error: dereferencing pointer to incomplete type
natpmp.c:214:35: error: dereferencing pointer to incomplete type
natpmp.c:215:39: error: dereferencing pointer to incomplete type

well i taked file arm-brcm-linux-uclibcgnueabi/sysroot/usr/include/netinet/in.h from asus`s toolchain

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.

That's two....same error I had (and same solution)

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.

 

[kvic]

The toolchain indeed comes directly from Broadcom, and is untouched AFAIK by any of their customers.

I thought ASUS is heavy weight enough to overrule some of Broadcom's design decision...

 

[RMerlin]

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]

I thought ASUS is heavy weight enough to overrule some of Broadcom's design decision...

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...

 

[kvic]

I tried this toolchain in Debian Jessie 64bit under VirtualBox. Didn't experience ctype.h issue...puzzling.

I built both AC56U and AC68U..

 

[kvic]

I'm currently running Asuswrt-Merlin 378.55 built with this updated Buildroot. And I'm in the process of re-compiling all my programs. No issues thus far. I don't use the Trend Micro.

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]

Does ASUS or Broadcom publish the Buildroot 2012.02 configuration file ".config" used to build the ARM toolchain ?

 

[kvic]

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.

 

[RMerlin]

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).

 

[sfx2000]

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...

 

[Fitz Mutch]

... move to Entware-ng. Its pthread library appears to be newer and much better.

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]

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).

Thank you. This file appears to be the .config to built the ARM toolchain for AsusWRT ?
dl_save/defconfig-arm-uclibc

 

[Fitz Mutch]

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.

In the AsusWRT firmware there is a file /lib/libpthread.so.0. Do you happen to know if it is a good pthreads library?

 

[sfx2000]

In the AsusWRT firmware there is a file /lib/libpthread.so.0. Do you happen to know if it is a good pthreads library?

Should be...

If I recall correctly - I think @kvic did a couple of private builds of AsusWRT enabling pthreads..

 

[RMerlin]

Thank you. This file appears to be the .config to built the ARM toolchain for AsusWRT ?
dl_save/defconfig-arm-uclibc

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.

 

[kvic]

After compiling and linking Transmission-daemon against AsusWRT, it seems to be running as multiple processes.

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]

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.

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.

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 2

Updating 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.

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]

... check if you're actually copying the correct uClib and pthread lib from the right toolchain's directory.

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.