Hi
I am trying to set up a USB TCP/IP network connection between my
beagleboard (Rev C3) and my host PC (Ubuntu 9.04). I followed a
tutorial that suggested that I do this by modifying the kernel image
(Angstrom 2.6.29-R35).
cd ~/oe/tmp/work/beagleboard-angstrom-linux-gnueabi/linux-omap-2.6.29-
R35/git
make menuconfig
Then changing the relevant USB Gadget parameters to allow for an
Ethernet connection. I save, recompile the kernel, then rebuild the
image via bitbake console-image. After copying the image over to my
SD card, I successfully reboot Angstrom, however there is no network
support. I expect to see a usb0 connection with ifconfig. Can anyone
add anything to this?
I have had the USB Gadget networking working for almost a week now. I
made changes to the kernel by changing the "USB Gadget Drivers" from
"CDC Composite Device" (removing the "M" to be clear) to "Ethernet
Gadget" (adding the "M" to be clear).
Occasionally, I do still have a hiccup similar to your problem. What
I have done and it seemed to cut down on problems for me is to ensure
that the interfaces file in "/etc/networking/" has the following:
on my system the only change to that file was the "auto usb0" which
starts the network interface on start up.
I have also made adjustments to my bootargs for u-boot. I added
"g_ether.dev_addr=00:01:02:03:04:05 g_ether.host_addr=06:07:08:09:0a:
0b" to the end. This sets the MAC addresses for both sides
(beagleboard is dev and PC is host) of the USB Gadget TCP/IP
connection. Since the MAC addresses are random by default, Ubuntu
seemed to think it had a different network adapter on every reboot of
the beagleboard, thus defeating the purpose of my static IP address
settings for the Gadget connection. Forcing the MAC addresses seemed
to fix that.
Oh, and I'm running the standard "console-image" bitbake.
I'm not sure if anything I've mentioned will help directly with the
problem, but hopefully it will help you bypass some of the headaches
that I experienced.
Are you sure that g_ether is being loaded (is it built in to the kernel or a module) and that it is working (what does “dmesg | grep ether” produce). I have on many times used a USB network between a desktop and a BeagleBoard. IIRC the usb0 interface doesn’t appear until the host is detected… make sure that the host is seeing the BeagleBoard, what does “lsusb” produce on the desktop…?
I went to go rebuild the kernel and found that the rootfs that came
out of bitbake was very incomplete (had only 3MB of data). Have any of
you guys experienced this? Would it be a result of the messing with
the modules that I have been doing? I would like to avoid doing a
clean rebuild of the console-image, that would take all night. Sorry
if this is unrelated, I still don't completely understand the system
yet.
I went to go rebuild the kernel and found that the rootfs that came
out of bitbake was very incomplete (had only 3MB of data). Have any of
you guys experienced this? Would it be a result of the messing with
the modules that I have been doing? I would like to avoid doing a
clean rebuild of the console-image, that would take all night. Sorry
if this is unrelated, I still don't completely understand the system
yet.
Which image are you building? Are there any error messages?
No errors, just no real file output. Here is the build output:
NOTE: Handling BitBake files: / (6659/6659) [100 %]
NOTE: Parsing finished. 6377 cached, 0 parsed, 282 skipped, 0 masked.
NOTE: Cache is clean, not saving.
NOTE: Resolving any missing task queue dependencies
NOTE: preferred version git of u-boot not available (for item u-boot)
NOTE: preferred version git of u-boot not available (for item u-boot)
NOTE: Preparing runqueue
NOTE: Executing runqueue
NOTE: Running task 2118 of 2119 (ID: 10, /home/mimosa/oe/openembedded/
recipes/images/console-image.bb, do_rootfs)
NOTE: Running task 2119 of 2119 (ID: 0, /home/mimosa/oe/openembedded/
recipes/images/console-image.bb, do_build)
NOTE: Tasks Summary: Attempted 2119 tasks of which 2117 didn't need to
be rerun and 0 failed.
Everything appears normal, but it tries to build the rootfs every time
now rather from taking from a cached version. The output is always the
same. I used to be able to build a working file system, I am not
exactly sure what caused this. I haven't done a bitbake console-image
in a while to be keeping tabs on it.