Re: Why does this have to be so ##@&$@$! difficult?

Some Success!  I was able to get my CHB connected with a TP-Link dongle.  I can ssh and all that good stuff.  Node.js works like a champ, BTW.  CHB is now free of the serial tether!  On to the Infocast 8...

52 (edited by mwalimu 2012-04-29 08:38:13)

Re: Why does this have to be so ##@&$@$! difficult?


So I'm struggling with the infocast 8 wifi.  I can get it up and running, but not connected.  Here's what I think...

When the infocast is powered on, the wifi card is not "up".  That is if I enter:

iwlist mlan0 scanning, it will tell me the system is not up.

If I enter: iwconfig mlan0 up, nothing happens (actually I get something about ioctls, but the point is that mlan0 doesn't come up).  In order to get results I have to:

iwpriv mlan0 setregioncode 0x10
iwconfig mlan0 up

then if I do iwlist mlan0 scanning, I get results, mlan0 is "up".  "iwpriv setregioncode 0x10" seems to be essential to getting mlan0 working.  I don't believe it is necessary on the CHB.

My hypothesis is that "iwpriv mlan0 setregioncode 0x10" is not in whatever setup code OE does for setting up the wifi connection and as a result it fails.  However, I have no clue where that set up code is to check it out.

Any ideas?

Re: Why does this have to be so ##@&$@$! difficult?

I see in this discussion that on the SqueezeBox Marvell requires region codes in /etc/network/config along these lines:


You might try that - at a glance it looks very similar to our environment.  Note that decimal 16 is the same value as hex 0x10 that you are using.

Re: Why does this have to be so ##@&$@$! difficult?

I found /proc/mwlan/mlan0/info that has that information.

Re: Why does this have to be so ##@&$@$! difficult?

Cool.  I trust you also understand that /proc is just echoing config data from the running driver and you can't SET persistent configuration there, right?  /proc isn't a real file system stored on disk, it's a magic virtual file system that gives you a way to interact with processes in a file-system-like way.

Re: Why does this have to be so ##@&$@$! difficult?

I think I have found the problem.  I found /proc/mwlan/mlan0/info.  It lists all the information about mlan0...  He then notices that GuyC has just posted what I am about to write...

It appears that the bootup value of region is 40.  When I did "ifpriv mlan0 setregioncode 0x10" i righted the wrong, but it isn't a permanent fix.

So.  I tried to follow the /proc fs discussion.  I got lost at "echoing into".  I figure it means something like echo: "region_code="10"" > /proc/mwlan/wlan0/info , but I don't know.  I'll try to sort it out.

However two things occur to me.

That information is hard coded somewhere.  Where?  Can it be changed?  I could see that it might be in a .bin file, but I don't see why that would be.

Also, it has to be in the source files used to roll OE.  Since that's a crucial feature, it would be nice to fix it.  I don't mind looking, but where do I start?

Re: Why does this have to be so ##@&$@$! difficult?

Here's another thought.  I figure that OE has a script that is followed when it is booting up.  I can follow the messages on screen and it comes to the point:

Cleaning: /etc/network/run/ifstate.
Configuring network interfaces... done

This is where I would think the information the wifi needs is loaded.  I can't imagined that is in an unreachable file because one can't know where one's chumby is going to be.  I should be able to make a change like that. 

I was just wondering, what's Australia's region code?  Could the chumby be getting the region code from some other file with 40 as a default?  When i set up my chumby it asks where I am.

Re: Why does this have to be so ##@&$@$! difficult?

Did you try setting REGIONCODE in /etc/network/config or is there some reason you have not?  That looks like the right solution to me.

Re: Why does this have to be so ##@&$@$! difficult?

Yep, the file does not exist.

I have tried a hack.  I inserted the following code in /etc/init.d/networking:

     echo "hack"
     iwpriv mlan0 setregioncode 0x10
     ifconfig mlan0 uo
     echo "hacked!"

Wifi is on and scans, but is not connected to the net.

Re: Why does this have to be so ##@&$@$! difficult?

Have you come across this post by Eduardo Silva? Eduardo used to be active in this forum but has been awol for a while.
Seems the links are now dead, but his post does provide wifi configuration steps for OE Silvermoon on an Infocast 8:

# iwpriv mlan0 setregioncode 0×10
# ifconfig mlan0 up
# iwconfig mlan0 mode managed
# iwconfig mlan0 key YOUR_WEP_KEY
# iwconfig mlan0 key on
# iwconfig mlan0 essid YOUR_ESSID
# udhcpc -i mlan0

Re: Why does this have to be so ##@&$@$! difficult?

Yes I did find that post.  That's how I got this far (again, thanks for your work and your interest - apparently Mr. Silva used your advice also).  Unfortunately I have a WPA wifi hub and WEP won't cut it.  I'm nearly considering using another wifi hub, but that seems a bit much.

Re: Why does this have to be so ##@&$@$! difficult?

I've put the infocast 8 aside for a while, it's distracting me from my real project, which was to give my Roombas better brains.  So on to another problem.

The plan was to do one of two things here.  Roombas are controlled over a RS232 serial port.  So I have to either go directly through the console on the Chumby or go through USB.  I tried the console, but while it worked to control the Roomba, the Chumby won't boot whilst the cable is attached (don't know why). 

So the other alternative is over USB.  The problem I'm having is that an FTDI chip plugged into a USB port is supposed to be recognized as either /dev/ttyAM0 (or AM1) or /dev/ttyUSB0 and my ROM images don't seem to have either of those in the /dev directory.  I found a similar project from Maddox at  He has an OE rom image that DOES have ACM0, etc.

When I plug in an FTDI chip I get something like:

[    3.360000] usb 1-1.2: new full speed USB device using fsl-ehci and address 3
[    3.480000] usb 1-1.2: configuration #1 chosen from 1 choice

Now /dev does have devices that look like /dev/usbdev1.2, but I'm not sure they are right and before I go chasing wild geese, I thought I'd ask.

1) How do I get /dev/ttyACMx into my device directory?
2) is /dev/usbdev1.x the same thing?

Re: Why does this have to be so ##@&$@$! difficult?

I've used FTDI connections from my Chumby One for my Chumbilight project.  The /dev/ttyUSB0 device will appear once the FTDI is recognized by the USB system since the device is running udev to dynamically create devices.

Re: Why does this have to be so ##@&$@$! difficult?

Ben, are you using the stock kernel or an OE kernel?  I think if Chris is using an OE image, it is likely that it does not include the kernel module ftdi_sio.  You can list the available loadable modules with

find /lib/modules -name '*.ko'

You need both usbserial.ko (present) and ftdi_sio.ko (not present) for this to work.  There is a second issue of making sure the vendor id and product id are mapped to the ftdi driver which we can ignore until the drivers are working.

FWIW I did a quick test on my silvermoon CHB; copied the kernel modules manually from the OE working files, plugged an Arduino into the USB port, and forced the driver to load as follows:

lsusb # to get the vendor and product ID of my device
 modprobe ftdi_sio vendor=0x2341 product=0x0001

The result was not good: it created TWO tty devices, and accessing the first of them causes a nasty system crash, accessing the second returns no data.  However it is probably worth repeating this experiment with a cleaner OE kernel.  My currently installed kernel has some non-standard USB code merged in from the Freescale source tree that might be causing problems.

For the record here are my results in detail:

>> Plug Ardino UNO into USB port:
[   38.610000] usb 1-1.2: new full speed USB device using fsl-ehci and address 4
[   38.720000] usb 1-1.2: configuration #1 chosen from 1 choice

>> Find the Vendor and Product Id's
root@chumby-falconwing:~# lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 002: ID 05e3:0608
Bus 001 Device 003: ID 0718:044e
Bus 001 Device 004: ID 2341:0001  << This is the new device

>> Force the ftdi driver to load
root@chumby-falconwing:~# modprobe ftdi_sio vendor=0x2341 product=0x0001
[  113.590000] usbcore: registered new interface driver usbserial
[  113.600000] USB Serial support registered for generic
[  113.600000] usbcore: registered new interface driver usbserial_generic
[  113.620000] usbserial: USB Serial Driver core
[  113.690000] USB Serial support registered for FTDI USB Serial Device
[  113.690000] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[  113.720000] usb 1-1.2: Detected FT2232C
[  113.740000] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[  113.740000] ftdi_sio 1-1.2:1.1: FTDI USB Serial Device converter detected
[  113.800000] usb 1-1.2: Detected FT2232C
[  113.800000] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB1
[  113.870000] usbcore: registered new interface driver ftdi_sio
[  113.870000] ftdi_sio: v1.4.3:USB FTDI Serial Converters Driver

>>> Two devices ttyUSB0 and ttyUSB1 created - something is wrong

>>> Try reading from USB0
root@chumby-falconwing:~# cat /dev/ttyUSB0
[  193.350000] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity
[  193.360000] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[  193.370000] ftdi_sio ttyUSB0: urb failed to clear flow control
[  193.380000] Unable to handle kernel NULL pointer dereference at virtual address 00000030
[  193.390000] pgd = c3dd4000
[  193.390000] [00000030] *pgd=43dcd031, *pte=00000000, *ppte=00000000
[  193.400000] Internal error: Oops: 817 [#1] PREEMPT
[  193.400000] Modules linked in: ftdi_sio usbserial ipv6 sd_mod usb_storage scsi_mod mousedev
[  193.400000] CPU: 0    Not tainted  (2.6.28-chumby #1)
[  193.400000] PC is at ftdi_open+0x1dc/0x24c [ftdi_sio]
[  193.400000] LR is at update_mctrl+0xf8/0x214 [ftdi_sio]
[  193.400000] pc : [<bf097da4>]    lr : [<bf097228>]    psr: 60000013
[  193.400000] sp : c3ddbd88  ip : 00000002  fp : c3ddbdc4
[  193.400000] r10: c394ec80  r9 : 00000001  r8 : c396b804
[  193.400000] r7 : c28acc00  r6 : c28ac000  r5 : c289ad00  r4 : c396b800
[  193.400000] r3 : 00000000  r2 : c0000480  r1 : 00000000  r0 : ffffffe0
[  193.400000] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  193.400000] Control: 0005317f  Table: 43dd4000  DAC: 00000015
[  193.400000] Process cat (pid: 429, stack limit = 0xc3dda268)
[  193.400000] Stack: (0xc3ddbd88 to 0xc3ddc000)
[  193.400000] bd80:                   00000000 00000001 c3ddbda4 00000000 00001388 c3ddbda8 
[  193.400000] bda0: c020cb60 c01e9740 c396b800 c39c7f60 c28acc00 c396b83c c3ddbdf4 c3ddbdc8 
[  193.400000] bdc0: bf08b364 bf097bd8 bf08b218 c3fef600 c394ec80 0bc00000 00000000 c3dda000 
[  193.400000] bde0: 00000000 c28acc00 c3ddbe34 c3ddbdf8 c0206e18 bf08b228 00000000 c3debd20 
[  193.400000] be00: 000000bc 00000000 00000000 c3debd20 c394ec80 c3fef608 00000000 00000000 
[  193.400000] be20: c3dda000 00000000 c3ddbe64 c3ddbe38 c009e078 c0206b68 00000024 00000000 
[  193.400000] be40: c3ddbe5c c3fd5b80 c34f2480 c394ec80 c3debd20 c009de80 c3ddbe8c c3ddbe68 
[  193.400000] be60: c0098b24 c009de90 c394ec80 00000000 00000000 00020000 00000000 40025000 
[  193.400000] be80: c3ddbeac c3ddbe90 c0099edc c0098994 00000000 00000000 00000000 00020001 
[  193.400000] bea0: c3ddbf64 c3ddbeb0 c00a60dc c0099eb0 00020001 c398c898 c3ddbfb0 400dd000 
[  193.400000] bec0: 00000000 c3bdec34 c3dd4000 00000000 00020000 00000024 c3fd5b80 c34f2480 
[  193.400000] bee0: 000000b7 00000000 00000000 00000101 00000001 00000000 c3dd5000 000000dd 
[  193.400000] bf00: 00000200 00000000 4f97d20d c398f800 c398f800 c3ddbfb0 00000000 00020001 
[  193.400000] bf20: 00000000 c394ec80 00020000 00000003 c3ddbf64 c3ddbf40 c00afd58 00000003 
[  193.400000] bf40: c399e000 ffffff9c 00020000 00000000 c3dda000 40025000 c3ddbf94 c3ddbf68 
[  193.400000] bf60: c0099f50 c00a5d84 00000002 40025000 c3ddbf9c bef87f05 00008000 0000005e 
[  193.400000] bf80: 00000005 c0025fa4 c3ddbfa4 c3ddbf98 c009a004 c0099f04 00000000 c3ddbfa8 
[  193.400000] bfa0: c0025e20 c0099fec bef87f05 00008000 bef87f05 00020000 00000000 00000000 
[  193.400000] bfc0: bef87f05 00008000 0000005e 00000005 00019248 00000002 40025000 00000000 
[  193.400000] bfe0: 400dd730 bef87bb0 0000949c 400dd774 60000010 bef87f05 40578031 40578431 
[  193.400000] Backtrace: 
[  193.400000] [<bf097bc8>] (ftdi_open+0x0/0x24c [ftdi_sio]) from [<bf08b364>] (serial_open+0x14c/0x1b8 [usbserial])
[  193.400000]  r7:c396b83c r6:c28acc00 r5:c39c7f60 r4:c396b800
[  193.400000] [<bf08b218>] (serial_open+0x0/0x1b8 [usbserial]) from [<c0206e18>] (tty_open+0x2c0/0x41c)
[  193.400000] [<c0206b58>] (tty_open+0x0/0x41c) from [<c009e078>] (chrdev_open+0x1f8/0x220)
[  193.400000] [<c009de80>] (chrdev_open+0x0/0x220) from [<c0098b24>] (__dentry_open+0x1a0/0x2bc)
[  193.400000]  r8:c009de80 r7:c3debd20 r6:c394ec80 r5:c34f2480 r4:c3fd5b80
[  193.400000] [<c0098984>] (__dentry_open+0x0/0x2bc) from [<c0099edc>] (nameidata_to_filp+0x3c/0x54)
[  193.400000] [<c0099ea0>] (nameidata_to_filp+0x0/0x54) from [<c00a60dc>] (do_filp_open+0x368/0x738)
[  193.400000]  r4:00020001
[  193.400000] [<c00a5d74>] (do_filp_open+0x0/0x738) from [<c0099f50>] (do_sys_open+0x5c/0xe8)
[  193.400000] [<c0099ef4>] (do_sys_open+0x0/0xe8) from [<c009a004>] (sys_open+0x28/0x2c)
[  193.400000]  r8:c0025fa4 r7:00000005 r6:0000005e r5:00008000 r4:bef87f05
[  193.400000] [<c0099fdc>] (sys_open+0x0/0x2c) from [<c0025e20>] (ret_fast_syscall+0x0/0x2c)
[  193.400000] Code: e1822403 e3822103 e5943070 e3822080 (e5832030) 
[  193.760000] ---[ end trace 2a70456d12a8a105 ]---
Segmentation fault

Like I said, my CHB kernel code isn't in a very clean state right now, so your mileage may vary.  I hope it does.

Re: Why does this have to be so ##@&$@$! difficult?

So, how do I put  ftdi_sio.ko into my image?

Re: Why does this have to be so ##@&$@$! difficult?

I tried this.  I copied the ftdi_sio.ko file from the Maddox OE image to the appropriate file on the Clearwater OE image.  I followed your other steps and Voila! my two fdti devices are recognized as /dev/ttyUSB0.

However, the Pololu Maestro and Mbed micro, which should be recognized as /dev/ttyACM0 are not.

Re: Why does this have to be so ##@&$@$! difficult?

I haven't figured out why a bunch of kernel modules are being built, but not copied to the installed image - still picking through the details.  Here's how I kluged it:

Edit meta-chumby/conf/local.conf and comment out the rm_work line which causes work files to be deleted after a build.
Commented out it looks like this:

# Remove build directories after building them
# INHERIT += "rm_work"

Rebuild the kernel.  I forced just the linux kernel to build something like the following (in truth I have UNIT set to linux-falconwing_2. inside my Makefile, but you may not, and the following will override your Makefile's definition of UNIT.) 

make uniclean UNIT=linux-falconwing_2.
make unit UNIT=linux-falconwing_2.

That causes the kernel to be rebuilt, and the first change ensures the work files are not cleaned up.  The kernel module files you want are now in this directory:

I tar'd those files up and copied them to the CHB and installed them manually in /lib/modules/2.6.28-chumby/kernel/drivers/usb/serial.

Re: Why does this have to be so ##@&$@$! difficult?

> However, the Pololu Maestro and Mbed micro, which should be recognized as /dev/ttyACM0 are not.

Maybe you need to do the same thing for the cdc-acm.ko driver?

Re: Why does this have to be so ##@&$@$! difficult?

No luck getting all those drivers on my image.  Any idea where cdc-acm.ko is located?

Re: Why does this have to be so ##@&$@$! difficult?

With my setup it is built here:


And if it were installed it would be here:


Re: Why does this have to be so ##@&$@$! difficult?

Ah, I see... yeah, all my work was on stock Chumby 1 kernels.

72 (edited by mwalimu 2012-05-04 15:03:15)

Re: Why does this have to be so ##@&$@$! difficult?

OK.  Adding cdc-acm.ko worked.  It would be nice if I could be part of the build.  How can I do that?

Re: Why does this have to be so ##@&$@$! difficult?

GuyC  How does one change the versions of packages in the OE image?  For instance, the version of node.js is 0.4 and I want the newest version of node.js.

Re: Why does this have to be so ##@&$@$! difficult?

The latest version of nodejs at is 0.6.17.

The package definitions are in openembedded/recipes/nodejs and I see the latest version in our tree is 0.4.2. 

My advice is to check if openembedded folks have a newer definition in their master tree.  Turns out they do not. 

In that case you can try creating a new recipe by copying and editing the one that is there.  The difficulty depends mostly on how much the dependencies of the new version have changed; it might work by just changing the version numbers, or 0.6 could have new dependencies that require a cascade of updates to other packages.

I'll do a quick test here and see what happens.  If it goes smoothly I'll push the update to the git repository. 

Update, while I was waiting for the spam blocker to let me post, I started checking this out - there is an issue with V8 not building cleanly on arm4.  It looks like it is solvable.  I'll see what I can do.  For the record here's my start at

DESCRIPTION = "nodeJS Evented I/O for V8 JavaScript"

DEPENDS = "openssl"

SRC_URI = " \${PV}/node-v${PV}.tar.gz \

SRC_URI[md5sum] = "55641d5d280cdd4e0c030c203107599d"
SRC_URI[sha256sum] = "8dfe5948de27e37a14af184f06e7bd89a23c3b248af44c8ef5cffcd0e\

S = "${WORKDIR}/node-v${PV}"

# v8 errors out if you have set CCACHE

do_configure () {
  ./configure --prefix=${prefix} --without-snapshot

do_compile () {

do_install () {
  DESTDIR=${D} oe_runmake install


Re: Why does this have to be so ##@&$@$! difficult?

Thanks Guy.  I actually meant that as a general question, many of the packages I'd like are out of date (ie Python is up to 3.0 and Lua at 5.2).  Also I'd like to try to get Cloud9 on the Chumby, but that's not in the list of packages.  This is frustrating because I know just enough to get in trouble, but not enough to get out of it...