Building HM4+rPi openwrt from source


 
Eric Thomas

Eric Thomas

TVWBB Member
I'm attempting to build the openwrt and linkmeter files from source for the first time.

Code: 
mkdir ~/heatermeter
cd ~/heatermeter
git clone https://github.com/CapnBry/HeaterMeter.git
svn co svn://svn.openwrt.org/openwrt/branches/attitude_adjustment openwrt
cd HeaterMeter/openwrt
source ./install.sh BCM2708 ~/heatermeter/openwrt
cd ~/heatermeter/openwrt
make menuconfig
make

But, the build is failing when creating boot.img:
Code: 
,dir_index /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/root.ext4
tune2fs 1.42.4 (12-June-2012)
/home/eric/heatermeter/openwrt/staging_dir/host/bin/e2fsck -fy /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/root.ext4
e2fsck 1.42.4 (12-June-2012)
Filesystem did not have a UUID; generating one.

Adding dirhash hint to filesystem.

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create? yes

Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/root.ext4: ***** FILE SYSTEM WAS MODIFIED *****
/home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/root.ext4: 904/6000 files (0.1% non-contiguous), 12440/20480 blocks
cp -fpR /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/root.ext4 /home/eric/heatermeter/openwrt/bin/brcm2708/openwrt-brcm2708-ext4.img
cp -fpR /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/Image /home/eric/heatermeter/openwrt/bin/brcm2708/openwrt-brcm2708-Image
rm -f /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img
mkdosfs /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img -C 9216
mkdosfs 3.0.7 (24 Dec 2009)
# Raspberry Pi has no bootloader, instead the GPU loads and starts the kernel
mcopy -i /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img /home/eric/heatermeter/openwrt/build_dir/target-arm_v6zk_uClibc-0.9.33.2_eabi/brcm2708-gpu-fw-boot/arm128_start.elf ::
mcopy -i /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img /home/eric/heatermeter/openwrt/build_dir/target-arm_v6zk_uClibc-0.9.33.2_eabi/brcm2708-gpu-fw-boot/arm192_start.elf ::
mcopy -i /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img /home/eric/heatermeter/openwrt/build_dir/target-arm_v6zk_uClibc-0.9.33.2_eabi/brcm2708-gpu-fw-boot/arm224_start.elf ::
mcopy -i /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img /home/eric/heatermeter/openwrt/build_dir/target-arm_v6zk_uClibc-0.9.33.2_eabi/brcm2708-gpu-fw-boot/bootcode.bin ::
mcopy -i /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img /home/eric/heatermeter/openwrt/build_dir/target-arm_v6zk_uClibc-0.9.33.2_eabi/brcm2708-gpu-fw-boot/COPYING.linux ::
mcopy -i /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img /home/eric/heatermeter/openwrt/build_dir/target-arm_v6zk_uClibc-0.9.33.2_eabi/brcm2708-gpu-fw-boot/LICENCE.broadcom ::
mcopy -i /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img /home/eric/heatermeter/openwrt/build_dir/target-arm_v6zk_uClibc-0.9.33.2_eabi/brcm2708-gpu-fw-boot/loader.bin ::
mcopy -i /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img /home/eric/heatermeter/openwrt/build_dir/target-arm_v6zk_uClibc-0.9.33.2_eabi/brcm2708-gpu-fw-boot/arm128_start.elf ::start.elf  #Copy file for memory/gpu division
mcopy -i /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img cmdline.txt ::
mcopy -i /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/boot.img /home/eric/heatermeter/openwrt/build_dir/linux-brcm2708/Image ::kernel.img  # Copy OpenWrt built kernel
Disk full
make[5]: *** [install] Error 1
make[5]: Leaving directory `/home/eric/heatermeter/openwrt/target/linux/brcm2708/image'

I'm not sure what each of the elf files do, but arm128_start.elf is added twice and all three of the armXXX_start.elf files are being added to boot.img.

I see that CONFIG_BRCM2708_SD_BOOT_PARTSIZE=9 which sets the size of the boot.img file. The total size of the files that are being added to boot.img is closer to 12M.
Any ideas where I'm going wrong?

Thanks,
eric
 
Last edited:
Ah someone actually tried to build from source! Wow it got pretty far but it looks like I've neglected getting a patch into git that is needed. It's actually a pretty big one that modifies all the bcm2708 config to work with the more recent firmware that fixes a number of initial issues. Give me a day to get the patch properly assembled and into git. Thanks for reporting, I'll get it worked out.
 
I didn't intend to spawn more work Bryan, but I started looking into the issue and realized I'm lost without first understanding the openwrt build. Thanks.
 
Oh no I'm glad you did. I thought all the necessary patches were in github. This is a pretty important one so I'd hate to lose it if something happened to my build machine. Coincidentally, I am typing this message as my build machine reboots because it had a drive error that forced it to remount the drive read-only... and now it isn't coming back up. Oh why didn't I make this patch last night!?
 
Oof my hard drive is in bad shape, bad blocks everywhere and takes 2 hours to boot, but I think I was able to get the patches off it. I'd appreciate it if you grabbed the latest git and see if it builds now.

The problem is there are 2 patches that need to be applied manually because they were missing from the install.sh script. Try this: go to the heatermeter/openwrt directory (the one with the install.sh script, ~/heatermeter/HeaterMeter/openwrt?) and execute:
Code: 
  patch -N -p0 -d ~/heatermeter/openwrt < patches/0600-rpi-patches-999b9c7a-4cdeb7b0.patch
  patch -N -p0 -d ~/heatermeter/openwrt < patches/0700-bcm2708-tweaks.patch
Then try to rebuild openwrt. You should probably do a `make clean` before you do the make because this changes a ton of underlying stuff in the target build, the linux kernel, the configuration, etc.

Let me know how it works because if there's something else I've missed I'd like to try to get it off this hard drive before it dies! Thanks
 
0700 patch set applies cleanly.
but the 0600 patch set is for the kernel which I don't think is uncompressed into $WRT_PATH/build_dir until after the build starts.
Should install.sh be copying the 0600 patch to $WRT_PATH/target/linux/brcm2708/patches-3.3 ?
 
Last edited:
Oh good catch, that is exactly right. Copy it there and go for it! See, you're catching on to this openwrt build system even faster than I did.
 
Well, the build completed cleanly without any problems.
My board boots openwrt, but the AVR is not detected ('No HeaterMeter board attached').
I was able to successfully flash the bundled AVR firmware via the gui, but after reboot AVR is still not detected.
linkmeter baud is set to 38400 (/etc/config/lucid).
I'm going to kick off another build just to make sure that I didn't corrupt anything.
Good luck with your hard drive.
 
Check the /etc/inittab to make sure the ttyAMA0 line starts with a #, and also check /proc/cmdline to make sure that ttyAMA0 isn't mentioned at all. I'm wondering if something else is grabbing the serial port even though it should be patched out.
 
After a clean build, the rPi and AVR board are communicating, so HM is running and graphs are pretty via lan.

Wireless kernel modules are missing though ...
CONFIG_DRIVER_11N_SUPPORT=y that is in the default config.BCM2708 is being overwritten with CONFIG_DRIVER_11N_SUPPORT=n after 'make menuconfig' runs.
As far as I can tell, it is being overwritten simply because the DRIVER_11N_SUPPORT config option in ./package/hostapd/Config.in is not user-configurable (i.e. it has no text prompt allow it to be configured from menuconfig) and it is 'default n'.
So, regardless of how CONFIG_DRIVER_11N_SUPPORT is set in .config, if you run 'make menuconfig' or 'make oldconfig' it will be reset to "Not set"

If I change the parameter definition for DRIVER_11N_SUPPORT in ./package/hostapd/Config.in from 'bool' to 'bool "Include 11N Support" ' the config stops overwriting it. But this is not a root cause ... after changing the config, wireless support is still missing in the .img
 
Last edited:
That should be being set by the 8192cu Makefile which "DEPENDS:=@DRIVER_11N_SUPPORT" and that's the package that actually builds and installs the wireless. Did you install the 8192cu source from RealTek in heatermeter/HeaterMeter/openwrt/package/8192cu/src? That's uhhh not mentioned anywhere I bet :-D It doesn't download the source directly because I can't direct link to their driver code. Just search their download for 8192cu and grab the Linux download, untar it and put the source in src (so that Kconfig and whatnot are right in that top directory).

I just had a great idea to have it error out it the source isn't there. It is funny that it will actually build a package that has nothing in it without throwing an error. Let me just compile this here code... oh no code? Welp I guess I am done!
 
Ah ... of course I had not downloaded the 8192cu source code, but now I understand the README file in the 8192cu folder. So, I dropped just the driver code into the src folder (with Kconfig at the top of the folder). The .config shows 11N support now, but it is still not building 8192cu.ko. The only modules in target fs /lib/modules/3.3.8/ are evdev, usbhid, spidev, spi-bcm2708, and hid.

Are there any manual config options that need to be set?
 
Nope, there shouldn't be anything else once the source is there. Maybe try
Code: 
make package/8192cu/compile V=s
And see what it is doing?
 
make package/feeds/linkmeter/spi-bcm2708/compile V=s works for that package.
However, the package/feeds/linkmeter/ folder doesn't include the 8192cu folder; only linkmeter, rrdtool, and spi-bcm2708.
should it??
 
Ah crap, looks like I fell victim to another one of OpenWrt's build inconsistencies. When building the package it wants the directory name, when installing the package it wants the parsed package name. Run this from the openwrt directory
Code: 
./scripts/feeds install kmod-8192cu
make package/8192cu/compile V=s
 
I had tried installing and uninstalling the linkmeter feed, but I didn't realize there were individual packages for kmod-8192cu, librrd, etc.
Installing the kmod-8192cu package manually added the 8192 driver option into the menuconfig (kernel->wireless drivers).
Next, I discovered that the RealTek 8192cu drivers that I pulled from the RealTek site are version _linux_v3.4.4_4749.20121105 and I really needed _linux_v3.4.3_4369.20120622.
So, after fixing this, I got a clean build and my EdiMax is alive.

Bryan, thanks again for all the build help end education on the openwrt build system; it is actually somewhat impressive the way that openwrt enables extensions.

However, I'm haunted by evil networking spirits ...

Wired eth0 network: rPi boots normally, pretty ethernet LEDs all light up and the network is stable for a while (sometimes as little as 2-5 minutes, other times much longer). Then, the board goes into a state where eth0 drops, all lan LEDs go dark for 3-4 seconds, then eth0 comes alive again for 8-30 seconds. This loop repeats. Typically when this happens I have 1 browser window open and one ssh connection. Occasionally my ssh connection will survive a few cycles, so I can tell the rPi is not rebooting.

Wireless: Runs for a while (20-30 minutes?) with -64 dBm signal, then the board freezes up; similar to what I reported on another thread that I was seeing with the pre-built Nov image. No blue light. It could be the same issue as wired network, but the init times of the devices differ so that when it happens to wireless, everything just appears dead.

With the pre-built Dec image (v3?) I have not seen these symptoms after 2-3 days up-time. I have a rPi heartbeat script running that toasts the uptime to the HM LCD. I'm going to keep testing to see if I can get a more consistent pattern ...
 
Last edited:
That is bizarre. I had to do a lot of work to get the wifi working on wrt and I never experienced something like you're experiencing so I'm not sure how much help I can be in tracking down the issue. The issues I had were with the module not communicating properly with the cfg80211 subsystem, properly exposing its information, and modifying wrt to support more standard access methods. Maybe the dmesg output on the device might hold a clue?

I do like the OpenWrt build system and how much you can do with it. It is really one of the reasons why I went with OpenWrt over DD-WRT despite lower device compatibility. DD-WRT really looks like a hack job when you try to build it, cobbled together with a lot of scripts and custom code. It works great but is somewhat difficult to extend their functionality without maintaining and updating lots of patches.
 
I confirmed that the rPi and LM PCB continue communicating after my Edimax goes offline (no flashy blue led). So, at least the rPi is not completely locking up.

I'm going to start testing tomorrow without the LM PCB connected; I'm not sure at this point if the issue is the Edimax, rPi, or poor solder joint on my LM PCB. Unfortunately, the wifi issues are intermittent; I've seen it drop after 4 minutes and run as long as 36 hours before I manually stopped it.

Random thought ... would it be possible to convert the temperature probe inputs to measure voltage drop? This way I could connect back to points on the rPi and have the HM look for supply voltage anomalies on the USB/ethernet. It wouldn't have to be accurate to scale, just something to confirm a drop and correlate the general time of occurrence to log files.
 
I'm not sure how you'd be able to hook it up in a way that would give you any meaningful data. You could modify the HeaterMeter code to do it though. If you're just looking for droops you could switch the probes to resistance mode by entering a setpoint ending in 'R' on the config page. That would give you a relative value, and it doesn't display if the value is 3.3V, but if it drops below that you'll get a point on the graph. I don't know it will work though because if the voltage is drooping, the reference voltage might also droop and then it will still look like 3.3V.
 
You must log in or register to reply here.

 

Back
Top