Building LinkMeter with new Platform


 
D

Dave Casazza

TVWBB Fan
Inspired by the LinkMeter project, I've decided to try to build it for a new platform - the WND3700. It's got a serial interface and plenty of room under the hood (Flash/RAM/physical room) for the linkmeter...

My plan is to outline it here step by step, once I get this going so that other people can refer to it. I'll reference different problems as I encounter them in the thread.

The setup:
ez install for Ubuntu 64 bit

As root:
apt-get update
apt-get install subversion build-essential
apt-get install git-core build-essential
apt-get install libncurses5-dev build-essential
apt-get install zlib1g-dev build-essential
apt-get install gawk build-essential
apt-get install unzip build-essential
​
as nonpriv user:

svn co svn://svn.openwrt.org/openwrt/trunk openwrt
git clone https://github.com/CapnBry/HeaterMeter.git
cd ~/HeaterMeter/openwrt
./install.sh ~/openwrt
​

I receive an error patching here on 100-dhcp_add_hostname.patch - can't find file to patch at input line 5

looking at the install.sh script, it seems to be patching ~/openwrt/packages/base-files-network/files/lib/network/config.sh, which doesn't exist in my tree.

I assume this is non-critical error? Or is something missing in the trunk clone?

Thanks in advance to anyone who can help!

Dave
 
The patch is non-essential. It just makes sure the DHCP client supplies a hostname when requesting an address. OpenWrt has gone to using netifd to configure the interfaces so I'm not sure if it is even possible to do this any more.

All the patches are against svn r29665 so you might want to save yourself some headaches and just set your svn directory to that. `svn up -r29665` If not you can just delete the 100- patch and try to carry on. I know the 200-luci-inreq-fix.patch has been accepted upstream so that'll fail too.
 
I don't need any more bloody experiences banging myself in the head needlessly, so I've started again, just getting r29665:

ez install for Ubuntu 64 bit
sudo apt-get install build-essential subversion git-core libncurses5-dev zlib1g-dev gawk unzip
cd~
svn co -r29665 svn://svn.openwrt.org/openwrt/trunk openwrt
git clone https://github.com/CapnBry/HeaterMeter.git

cd ~/HeaterMeter/openwrt
./install.sh ~/openwrt

... now I'm getting some interesting output as part of the feed updates (grepping for ERROR and WARNING):

ERROR: please fix feeds/packages/admin/nagios-plugins/Makefile - see logs/feeds/packages/admin/nagios-plugins/dump.txt for details
ERROR: please fix feeds/packages/mail/xmail/Makefile - see logs/feeds/packages/mail/xmail/dump.txt for details
ERROR: please fix feeds/packages/net/gpsd/Makefile - see logs/feeds/packages/net/gpsd/dump.txt for details
ERROR: please fix feeds/packages/net/iperf/Makefile - see logs/feeds/packages/net/iperf/dump.txt for details
ERROR: please fix feeds/packages/multimedia/peercast/Makefile - see logs/feeds/packages/multimedia/peercast/dump.txt for details
ERROR: please fix feeds/packages/libs/taglib/Makefile - see logs/feeds/packages/libs/taglib/dump.txt for details
WARNING: No feed for package 'libubus-lua' found, maybe it's already part of the standard packages?
WARNING: No feed for package '6rd' found, maybe it's already part of the standard packages?
WARNING: No feed for package 'uclibcxx' found, maybe it's already part of the standard packages?
WARNING: No feed for package 'uclibcxx' found, maybe it's already part of the standard packages?
WARNING: No feed for package 'uclibcxx' found, maybe it's already part of the standard packages?
WARNING: No feed for package 'uclibcxx' found, maybe it's already part of the standard packages?

Are these important to resolve?
 
Oye that could be a problem. I don't know how to pull the feeds at a certain revision and I'm willing to bet that the trunk feeds aren't compatible with the r29665 system. I never had a chance to figure out how to actually build an OpenWrt system with specific versions, since it appeared that the feeds keep moving on. Since both luci and the packages feeds come from svn, there must be a way to do it. My packages also appear to be r29665 and my luci is r8147.
 
Ok, so with some editing of the install.sh script, we can pull back at r29665 and r8147 with the update to feeds.conf:

src-svn packages svn://svn.openwrt.org/openwrt/packages@29665
src-svn luci http://svn.luci.subsignal.org/luci/trunk/contrib/package@8147

then have install2.sh pull back the feeds with a normal:

@WRT_PATH/scripts/feeds update

After these changes, no errors appear, but just one warning:

WARNING: No feed for package 'libsrtp' found, maybe it's already part of the standard packages?

Is this important?
 
Last edited:
Aha! Well I will update the default install.sh script to do this. We don't use libsrtp so that should be fine. Make away!
 
So I've run into the dreaded "checking for lua... no" failure during the rrdtool-1.4.5 make process. The end result is a failure to build rrd.so, shown in the following line:

/home/dcasazza/openwrt/build_dir/target-mipsel_uClibc-0.9.32/rrdtool-1.4.5/ipkg-brcm47xx/librrd/usr/lib/lua/
cp: cannot stat `/home/dcasazza/openwrt/build_dir/target-mipsel_uClibc-0.9.32/rrdtool-1.4.5/ipkg-install/usr/lib/lua/5.1/rrd.so': No such file or directory
make[3]

to recap, the steps to date are:

The setup:
ez install for Ubuntu 64 bit

As root:
apt-get update
apt-get install subversion build-essential
apt-get install git-core build-essential
apt-get install libncurses5-dev build-essential
apt-get install zlib1g-dev build-essential
apt-get install gawk build-essential
apt-get install unzip build-essential
apt-get install flex build-essential -- (new to get make menuconfig to work)

as nonpriv user (getting revision openwrt r29665 and luci r8147):

svn co -r29665 svn://svn.openwrt.org/openwrt/trunk openwrt
git clone https://github.com/CapnBry/HeaterMeter.git

We patched feeds.conf with the following:

src-svn packages svn://svn.openwrt.org/openwrt/packages@29665
src-svn luci http://svn.luci.subsignal.org/luci/t...b/package@8147

Then...

cd ~/HeaterMeter/openwrt
./install.sh ~/openwrt

cd ~/openwrt
make menuconfig (save and exit, no changes)

make

...

Talking with Bryan previously, the problem seems to be in the configure step for the rrdtool.

I created a patch for rrdtool configure.ac that would add debugging output, and I've captured the output around checking for lua .

The net result is that rrdtool configure seems to be checking for an lua install in one of the PATH directories. Bryan's directory is ~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/host/bin, which seems to be consistent where where Bryan's lua was found (/home/bmayland/openwrt-rpi/staging_dir/host/bin/lua).

lua is can be found in my system at the following locations (and I'm not sure if it is a full implementation of lua, sufficient for the rrdtools build)

~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/usr/include/luaconf.h
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/usr/include/lua.h
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/usr/include/lualib.h
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/usr/lib/liblua.so.5.1.4
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/usr/lib/pkgconfig/lua.pc
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/usr/lib/liblualib.so
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/usr/lib/liblua.so
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/usr/lib/liblua.a
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/root-brcm47xx/usr/bin/lua
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/root-brcm47xx/usr/bin/luac
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/root-brcm47xx/usr/lib/liblua.so.5.1.4
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/root-brcm47xx/stamp/.lua_installed
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/root-brcm47xx/stamp/.liblua_installed
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/root-brcm47xx/stamp/.luac_installed
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/stamp/.lua_installed
~/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/packages/lua.list

***

If anyone has any thoughts about why I don't have lua installed in the correct place, please let me know.

I might punt (my head is pretty bloody) and go with the reference hardware and get the BM image... and eventually look at the RPi platform Bryan is working on.

Cheers,

Dave
 
Yeah the problem may be that rrdtool is checking for lua on the host system rather than in staging. I know it had a couple things it checked for that didn't check target system. Do you have lua and lua-dev installed on your host system?
 
It's checking first in staging and then in the host system. Good news is that it isn't finding the host system lua. Bad news... it's not finding staging lua...

Here's the debug output, grepped for test:

+ test -z /home/dcasazza/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/host/bin
+ test -f /home/dcasazza/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/host/bin/lua
+ test -z /home/dcasazza/openwrt/staging_dir/toolchain-mipsel_gcc-4.5-linaro_uClibc-0.9.32/bin
+ test -f /home/dcasazza/openwrt/staging_dir/toolchain-mipsel_gcc-4.5-linaro_uClibc-0.9.32/bin/lua
+ test -z /home/dcasazza/openwrt/staging_dir/host/bin
+ test -f /home/dcasazza/openwrt/staging_dir/host/bin/lua
+ test -z /home/dcasazza/openwrt/staging_dir/toolchain-mipsel_gcc-4.5-linaro_uClibc-0.9.32/bin
+ test -f /home/dcasazza/openwrt/staging_dir/toolchain-mipsel_gcc-4.5-linaro_uClibc-0.9.32/bin/lua
+ test -z /home/dcasazza/openwrt/staging_dir/host/bin
+ test -f /home/dcasazza/openwrt/staging_dir/host/bin/lua
+ test -z /home/dcasazza/openwrt/staging_dir/toolchain-mipsel_gcc-4.5-linaro_uClibc-0.9.32/bin
+ test -f /home/dcasazza/openwrt/staging_dir/toolchain-mipsel_gcc-4.5-linaro_uClibc-0.9.32/bin/lua
+ test -z /home/dcasazza/openwrt/staging_dir/host/bin
+ test -f /home/dcasazza/openwrt/staging_dir/host/bin/lua
+ test -z /usr/local/sbin
+ test -f /usr/local/sbin/lua
+ test -z /usr/local/bin
+ test -f /usr/local/bin/lua
+ test -z /usr/sbin
+ test -f /usr/sbin/lua
+ test -z /usr/bin
+ test -f /usr/bin/lua
+ test -z /sbin
+ test -f /sbin/lua
+ test -z /bin
+ test -f /bin/lua
+ test -z /usr/games
+ test -f /usr/games/lua
+ test -z /usr/perl5/bin
+ test -f /usr/perl5/bin/lua

All of these are failing when running through the tests in configure (I can show you the output, if you want).

ok, so grepping for lua from /, we find this on my system:

./home/dcasazza/openwrt/package/lua
./home/dcasazza/openwrt/build_dir/target-mipsel_uClibc-0.9.32/lua-5.1.4/ipkg-brcm47xx/lua
./home/dcasazza/openwrt/build_dir/target-mipsel_uClibc-0.9.32/lua-5.1.4/ipkg-brcm47xx/lua/usr/bin/lua
./home/dcasazza/openwrt/build_dir/target-mipsel_uClibc-0.9.32/lua-5.1.4/ipkg-install/usr/bin/lua
./home/dcasazza/openwrt/build_dir/target-mipsel_uClibc-0.9.32/lua-5.1.4/ipkg-install/usr/share/lua
./home/dcasazza/openwrt/build_dir/target-mipsel_uClibc-0.9.32/lua-5.1.4/ipkg-install/usr/lib/lua
./home/dcasazza/openwrt/build_dir/target-mipsel_uClibc-0.9.32/lua-5.1.4/src/lua
./home/dcasazza/openwrt/build_dir/target-mipsel_uClibc-0.9.32/rrdtool-1.4.5/ipkg-brcm47xx/librrd/usr/lib/lua
./home/dcasazza/openwrt/build_dir/target-mipsel_uClibc-0.9.32/rrdtool-1.4.5/bindings/lua
./home/dcasazza/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/root-brcm47xx/usr/bin/lua

and lo and behold it looks like the last one is an executable found in the staging directory...
I guess a cheap and easy way of fixing this is to put in a sym link from /home/dcasazza/openwrt/staging_dir/host/bin/lua, pointing to /home/dcasazza/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/root-brcm47xx/usr/bin/lua

However, this isn't very portable for your standard LinkMeter build instruction.

There are ways to override in a nicer fashion for an official linkmeter approach: 1) Either update the path in the Make structure to include this directory in staging, or 2) update an autoconf variable ac_cv_path_LUA to point to this directory. --enable-lua-site-install might also be of value.
 
Last edited:
ruh roh....

with symlink we are still having problems. I suspect that configure can't figure out the lua version, so sym link isn't the way to go. Ok, how in the hell did everyone else figure this out? I'm not doing anything crazy with my setup, am I?

checking for lua... /home/dcasazza/openwrt/staging_dir/host/bin/lua
checking for lua >= 5.0... ./configure: line 20158: test: 0line: integer expression expected
line. found
checking lualine/lua.h usability... no
checking lualine/lua.h presence... no
checking for lualine/lua.h... no
checking lualine./lua.h usability... no
checking lualine./lua.h presence... no
checking for lualine./lua.h... no
checking lua.h usability... yes
checking lua.h presence... yes
checking for lua.h... yes
checking lualib.h usability... yes
checking lualib.h presence... yes
checking for lualib.h... yes
checking lauxlib.h usability... yes
checking lauxlib.h presence... yes
checking for lauxlib.h... yes
checking for library containing lua_call... -llua
checking for library containing luaL_register... -llua
configure: WARNING: Setting Lua include and lib flags to defaults in compat-5.1 and lua 5.1 sources
 
Yeah see the reason it isn't liking the symlink is (from configure.ac, comments mine)
Code: 
# find lua, set $LUA
AC_PATH_PROG(LUA, lua, no) 
# execute $LUA -v to have it print its version
read LUA_MAJOR LUA_MINOR LUA_POINT <<LUA_EOF
    $($LUA -v 2>&1 | cut -f2 -d' ' | sed -e 's/\./ /g')
LUA_EOF
It can't run the target binary because it is built for the ARM target, not the host platform. The only way to get around this is to have the same version of LUA installed and locatable on your host platform OR just make an executable shell script somewhere in one of the paths it searches that echos:
Code: 
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio

EDIT: Well that is really odd, my /home/bmayland/openwrt/staging_dir/host/bin/lua is a x86_64 binary. Iiii wonder how that got there. Even more bizarre is that it is a different version than the one on my host platform.

EDIT Again: The lua package places it there, I'm not sure when Host/* runs but it builds a second version of lua for the host system and installs it in staging. Isn't the OpenWrt build process fun? I've been working with it for a year now and still open some Makefiles and say "you can do that?!" and "what the heck is that?!"
 
Last edited:
Thats crazy.... Thank you for your help Bryan! Hopefully we figure out some one of doing this so that it is repeatable for anyone who follows after us. I'll let you know how it goes.
 
Hi Bryan

Thank you!

Make works for wrt54g and with wnd3700!

Two questions:

I'm looking for something like this in the openwrt structure:

linkmeter-wndr3700v-squashfs.bin - but I'm unable to find it...

However, I do find something like ~/openwrt/bin/ar71xx/openwrt-ar71xx-generic-wndr3700v2-squashfs-sysupgrade.bin and openwrt-ar71xx-generic-wndr3700v2-squashfs-factory.img

1) I assume that the prebuilt image is found in openwrt-ar71xx-generic-wndr3700v2-squashfs-factory.img?

2) How do I build avrdude?

I'll post detailed/tested instructions on another post (I'm about 90% of the way there!).
 
You did it! Hopefully you'll never have to go through that[/] again, right?
1) The output files from the build process go into bin/(platform)/. If it is like the WRT54GL version, the "sysupgrade" version is one you can use with the sysupgrade command line tool for upgrading once openwrt is installed, and I'm guessing the "factory" version is what you need to flash initially.

2) If you want the full avrdude package:
Code: 
./scripts/feeds install avrdude
make menuconfig
select avrdude under Utilities (I think)
Because avrdude is so big and has such a variable startup time it was difficult to catch the AVR in the bootloader, so I wrote a slim replacement that is installed along with the linkmeter package called hmdude. I'd use that unless you really need a feature from the full package. There's also a helper script `avrupdate (file name or URL)` which handles stopping the linkmeterd, downloading the file, and flashing it with hmdude.
 
I think we can wrap up this thread...

So as of 8/5, the tested build procedure (retested from start to finish as of this morning) to build linkmeter for other platforms is the following:

Steps:

Test Linkmeter Build - Ubuntu 64-bit

Using ubuntu-12.04-server-amd64.iso for install

As root:
apt-get update
apt-get install openssh-server <-- optional
apt-get install subversion git-core libncurses5-dev zlib1g-dev gawk unzip flex lua5.1 build-essential

as nonpriv user (getting revision openwrt r29665 and luci r8147):

svn co -r29665 svn://svn.openwrt.org/openwrt/trunk openwrt
git clone https://github.com/CapnBry/HeaterMeter.git

cd ~/HeaterMeter/openwrt

If Bryan hasn't changed ~/HeaterMeter/openwrt/install.sh yet, change the following two lines in install.sh:
src-svn packages svn://svn.openwrt.org/openwrt/packages@29665
src-svn luci http://svn.luci.subsignal.org/luci/t...b/package@8147

run the new install.sh:

install.sh ~/openwrt

Ignore the line "WARNING: No feed for package 'libsrtp' found, maybe it's already part of the standard packages?

cd ~/openwrt
make menuconfig (change to platform and drivers desired, save and exit)

make

***

Troubleshooting:

install.sh could be executed as cd ~/HeaterMeter/openwrt; ./install.sh ~/openwrt 2>&1 | tee install.sh.err to capture output from the executing script.

Likewise make can be executed as cd ~/openwrt; ./make V=99 2>&1 | tee make.err to capture makefile output.

lua binding:

lua 5.1 binary should be found in one of the path directories (hopefully for your host, and not your target). If you run into the rrd.so not found error in your make, you can (as I did) create a patch in ~/HeaterMeter/openwrt/package/rrdtool/patches to patch configure.ac to add in debug lines ( set -x turns on debugging, set +x turns off debugging). Use diff -u to create the patch.

***

I hope this helps anyone who tries this!

Thank you Bryan for an awesome project!!

Cheers,

Dave
 
Last edited:
Very nice, thanks for the writeup. I'm going to put it up in the wiki if you don't mind. I'll have the changes to install.sh pushed up to github sometime this week.
 
So a quick update for any WNDR3700v2 users,

After flashing with openwrt-ar71xx-generic-wndr3700v2-squashfs-sysupgrade, the familiar green power light changes to orange after the router reboots. I thought I bricked my router (because the green led didn't appear for power), but after changing my ethernet to dhcp, and renewing the address, I got a lease of 192.168.200.xxx. Pinging 192.168.200.1 showed icmp responses. Browsing to the 192.168.200.1 address shows the familiar linkmeter pit graphics. Woohoo!

I think we are good to go - next stop - build the HeaterMeter hardware...
 
You must log in or register to reply here.

 

Back
Top