This is just what popped into my mind immediately as I was reading this, so your mileage may vary, but I am using an AirSTORM with a Pinto-TH board using both Bluetooth and WiFi. I am also using a custom OpenEmbedded image, not Linaro. Though both are Debian-based.

I have about a dozen of these that I'm working with right now and I've noticed that udev will assign a different device name to the wlan device based on the MAC address. So the image is configured to bring up wlan0, but udev has assigned it wlan1, for example. Every time I put the microSD in another COM and boot it adds another entry into /etc/udev/rules.d/70-persistent-net.rules based on the wlan MAC and increments the wlan device name.

The file basically ends up looking like this:

# net device ()
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:88:00:00:00", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

# net device ()
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:88:00:00:01", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan1"

# net device ()
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:88:00:00:02", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan2"

It's a long shot, but it's an idea :-)

Good luck.


On Fri, Jul 12, 2013 at 4:34 PM, Ross Berteig <> wrote:
I have been developing with an AirSTORM mounted on a Chestnut43 without
issues since I got a booting Linaro-ALIP image. All is going well. Now
it is time to move the prototype to the first-article packaging, which
involves replacing the Chestnut43 with a Tobi due to size constraints.

Since our final application is headless, we have no reason other than
size to prefer one board over the other. From the schematics, there are
no apparent differences in the design of the ethernet on the two boards.

However, mounted on the Tobi, it fails to finish configuring the wired

The smc911x controller is detected by U-Boot, and again by the kernel.
The kernel loads smsc911x driver version 2008-10-21, which claims to
have found both the chip and the PHY and even reports a MAC address for
eth0. Later in the boot, the kernel stalls waiting for network
configuration, and then prints the two failsafe status messages (and
delays the full two minutes) before completing the boot without eth0

At that point, saying "ifup eth0" is not helpful.

This is a showstopper for us, as the whole point of the box we are
building is to provide a wired ethernet connection for an embedded
system. Replacing the Tobi with Chestnut43 is a conceivable option, but
will incur unplanned expenses and waste resources already committed on
the assumption that the Tobi is a viable board.

I am hopeful that this is a software configuration issue that can be
worked around at worst by generating a different boot image for the
microSD card.

Any ideas?
Ross Berteig                     
Cheshire Engineering Corp. 

See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
gumstix-users mailing list

Michael Wynne