This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CDC Ethernet does not work the same in newer Linux kernel (for OMAP L137 and L138)

Other Parts Discussed in Thread: OMAP-L137

We have been using the OMAP-L137 EVM boards for proof of concept for a system we are building. We have four boards that need to communicate with each other over the USB 2.0 interface. The easiest way was to implement the CDC Ethernet drivers and set up a local network between the OMAPs. This was over kill since we didn't need the slaves talking to each other but just a single master talking independantly to the three slaves. It also adds a lot of overhead and that seems evident in the low throughput numbers we were getting (5MBps). In short this was to be a somewhat temporary solution until we could develop our own driver to get the high speeds we eventually will need.

We had success in setting up this system. We used the Montavista Pro 5.0 Linux Kernel for out LSP and this more or less got us to where we wanted to be. BUT then we had a design change and we needed to use a OMAP L138 for our master unit. This forced us to change the Linux kernel to the more current LSP (this is the community solution maintaind using git). I was able to get a snapshot of the LSP and to build and run kernel. Everything seemed to work fine until I tried to setup the network.

It turns out that if I connect two boards I get a usb0 interface and I can set it up and all is well. However, if I connect the second card a few hubs downsteam I run into a stange problem. The master Identifies the board and creates a usb0 interface. BUT when I try to set it up it fails.

Ex:

ifconfig usb0 10.0.0.1 up

I get the following error message:

ifconfig: SIOCSIFFLAGS: No space left on device

 

The interesting this is this. If I hook up the board to the first hub and I leave extra hubs (say two more) connected in a chain then I get the same failure. If I then disconnect the extra hubs IT WORKS. I think there is some resource problem that occurs in the USB enumeration. Another interesting point is that the Montivista kernel would enumerate unlimited hubs connected in a chain (as far as I could tell...I had 6 connected with no problems--the spec has a 5 hub limit) but the new kernel stopped at 5 which is in line with the spec.