Category Archives: Wandboard

Bluetooth on the Wandboard (bcm4329)

As you might now, I’ve recently bought a Wandboard Quad which is a small RasperryPi-like ARM development board. The difference to my beloved raspberry is, that it has much, much more features and beef (quad core armv7, wifi, sata, bluetooth…).

While another post has already covered getting the Wifi AP mode to run on the wandboard, this post will be around bluetooth (which also involves that particular Broadcom Chip).

The bluetooth-chip on the wandboard (the bcm4329) is connected to the OS via UART and requires the user to load a firmware into the devices ram before it can be used.
On the wandboard, this can be done using the ‘brcm_patchram_plus’-utility included in the firmware package.

After you compiled the utility, you can load the firmware at runtime via
brcm_patchram_plus --scopcm=1,4,0,0,0,0,0,0,0,0 --patchram /bcm4329.hcd --baudrate 3000000 --use_baudrate_for_download /dev/ttymxc2
I got this particular line from here and talked with Tapani on irc about it, it’s fine.

After you loaded the firmware, you’ll have to attach a hci device to the UART, this can be accomplished via
hciattach -n /dev/ttymxc2 any 3000000

I tried to get PAN to work using the method I just described but was not able to get a working connection. After fooling around with it for days, I figured out that you have to change the MAC address of the device at runtime by adding
--bd_addr $MAC_ADDR
(where $MAC_ADDR is a valid MAC address) to the brcm_patchram_plus line. I use a 00:23:76:XX:XX:XX address and everything seems to work fine.
Also, I used bluez4 instead of the normal version 5. Using version 5 I was not able get a PAN connection working.

As usual, ArchLinux ARM users can instead get a PKGBUILD here. After installing, you should add your desired MAC address in /etc/conf.d/bcm4329 to avoid the behaviour I explained above.
If you enable the bluetooth.service, the bcm4329.service should get started automatically.

Wifi AP mode on the Wandboard

Getting to ap mode has been a struggle due to closed source firmware, vendor-modified driver… I am going to reiterate the whole story here, so if you just want the solution simply skip to the end of this post.

The wandboard has a bcm4329 which is a design by Broadcom and therefore requires a binary firmware and a compatible driver.
A few months ago, someone posted a thread asking for ap mode on the wandboard because the chip apparently supporty it but the backported brcfmac with the firmware delivered by linux-firmware or the one in wandboard-firmware doesn’t.

Mr. Tapani (he’s with the wandboard-project) then asked their manufacturer for a better firmware and/or a better driver and finally received a response (though hindered by a forwarding chain… business reasons of course).
The packaged they received was later posted in the forums and it included a firmware and a the “bcmdhd” driver which should support the ap mode.

After some trouble compiling the kernel (which needed a kernel patch) I got it to compile and inserted the module. Using hostapd, I even got it to run as an ap (it was visible on my android phone) and was able to connect and ping afterwards. It all worked on open mode, but after I added encryption it stopped working. With enabled WPA/WPA2, the ap was still visible, but you could not connect to it.

Tapani replied to the manufacturer and received new instructions (README as a PNG File…) involving a mysterious ‘wl’ utility. I tried the instructions from the PNG and tried to improvise using the manual I found here, but I did not have any success with it (ap wasn’t even visible).

Afer all that, I’ve realized that the brcmfmac driver (which is completely open source but relies on the binary firmware) does actually include ap support! The version used in the wandboards 3.0.35 kernel (which is still the stable release for i.MX6 devices :/) is backported by Tapani from 3.5rc7 and is too old to support ap mode though :/
I tried using the (early) 3.10.17 kernel which includes a new brcmfmac driver and it actually worked! Even with WPA2 I was able to connect, authenticate and ping on the newly established connection! Sadly though, this driver was not available on 3.0.35.

But there is help for the older kernel after all: The backports-project allow you to compile and run drivers from the most recent linux (3.13 in this case) to run on kernels as old as 2.6.xx (in the case of brcmfmac it’s 2.6.29). This allowed me to compile the driver from 3.10.17 and run it on 3.0.35! And here we go again, ap mode worked!

The problem with this method was, that I had not tried to have any actual traffic on the wandboard (more than just a simple ping, iperf for example). Heavy traffic resulted in loads of

on serial and huge connection problems on client side.
But as I have come this far, I just could not resign and tried the newer version from 3.13 (again, using the backports-project). Again, ap mode worked with WPA2 and this time the error message was gone! I was actually able to sustain like 10mbit over the wandboards ap!

I wrote down my build-instructions using a Archlinux PKGBUILD file which you can find here. It downloads the 3.13-stable kernel source, the 3.13-compatible version of backports and compiles the modules ‘compat/compat.ko’,’net/wireless/cfg80211.ko’, ‘drivers/net/wireless/brcm80211/brcmutil/brcmutil.ko’ and ‘drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.ko’ and adds them to the updates/ folder of your kernel. It also extracts the firmware from the archive Tapani posted and puts it in the respective /usr/lib/firmware/brcm location for the brcmfmac driver.

Afer running a depmod and then modprobe’ing the brcmfmac module, your wandboard will now support ap mode (via hostapd).

If you need more build instructions, just drop me a note.

Fixing HDMI-CEC on the Wandboard

I (Hanny) have recently bought a Wandboard Quad and have been playing with it since I got it. My primary objective was to get XBMC running on that device using ArchLinuxARM which was possible after some fiddling with the proprietary stuff (this deserves its own post some time in the future). Many thanks to Stéphan Rafin, without his work, I would not have been able to do that.

After finding out (also, thanks Stéphan) that the Freescale i.MX6 SoC on the Wandboard supports HDMI-CEC, I was eager to get it running on the wandboard. Sadly though the CEC signal is not properly routed on the wandboard.

But according to a post in the wandboard forums with instructions, you can actually fix this if you have some soldering skills (which I have absolutely not!). So I handed my board to a fellow PI member (Neutrino) who will describe the things he did:

The pins for CEC are available but there is no connection from the SoC to the HDMI-connector. But if you have some SMD-soldering skills (or a friend who can do that), you can fix it yourself. Be careful though as this WILL VOID YOUR WARRANTY.

It isn’t hard to solder the 3 things but you should be careful not to damage a pad. You need a soldering tip with 1,5-3mm width, thin solder, an electronic tweezer and a good loupe (or microscope). Soldering flux is also helpful for good joints.

1. You have to remove the 0Ω resistor R383 on the bottom side of the processor board. Maybe you could unsolder it carefully, to recycle it in step 2. Because it is in tiny 0402 package I unsoldered it at one time with a 2mm width soldering tip on the side over both soldering joints and add a bit solder until I could smoothly push the resistor from the pads.
2. We need to connect the 2 empty pads of R405 on the bottom of the baseboard. We could use the R383 resistor or a piece of wire which we cut after soldering on both pads or maybe we simple solder a soldering blob over the two pads (I took a new 0Ω resistor in 0402 package because I had it in my reach).
3. The “most difficult” part is to solder a wire from the connector-side pad of R383 to the testpoint TP78 on the bottom side of the processor board. Cut a 2cm piece of insulated thin wire bend it right and remove insulation or enamel the ends before soldering it.
 

Bottom side of processor board.

Bottom side of processor board. The white line shows to the testpoint-labels. The purple line illustrate the wire.

Enamelled copper wire from below pad of R383 to testpoint TP78.

Enamelled copper wire from below pad of R383 to testpoint TP78.



This two empty pads of R405 have to be short connected together.

This two empty pads of R405 have to be short connected together.



Thanks again Neutrino!

To me(Hanny), the needed software-modifications are far more simpler :)

Now that you have routed the cec signal to the right pins, you just need a slightly modified kernel and a modified libCEC (thanks again, mighty Stéphan :)).

You’ll have to compile the modified kernel (be sure to set CONFIG_MXC_HDMI_CEC in the kernel config) and the modified libCEC and install both (you can find PKGBUILDs for ArchlinuxARM here).
If you now connect hdmi to a CEC-enabled tv (every manufacturer calls it differently!), cec-client should spit out some data!

Compiling xbmc with

should enable libCEC in xbmc. Afterwards, xbmc should recognize your TV as CEC input device and the whole thing should work!