Gumstix as USB Storage device
These are my notes as of 28Nov 2011..
Download the build system, but don’t build, just get it all setup as here.
Add
CONFIG_USB_GADGET_MUSB_HDRC=y
to org.openembedded.dev/recipes/linux/linux-omap3/overo/defconfig
Add
MUSB_MODE = "peripheral"
to:
${OVEROTOP}/build/conf/local.conf
bitbake linux-omap3
This actually worked and resulted in a completed build! Though when I tried it multiple time before it failed.
You can then build a complete image, for example:
bitbake omap3-console-image
Once the build is complete install the image on your device/SD Card for example, as here. MLO didn’t appear to be built as part of the build process, I just used a copy from the gumstix site.
If you don’t want/can’t complete the build, see the precompiled files below.
You can now load the file storage device kernel module, for example:
root@overo:~# cat /dev/zero > /tmp/file # best to control-C it before you use up all the SD free space. root@overo:~# modprobe g_file_storage file=/tmp/file # load the kernel module!
You can mount the filesystem on the gumstix too via a loopback interface:
losetup /dev/loop0 /tmp/file mkfs.vfat /dev/loop0 mkdir /media/t mount /dev/loop0 /media/t
You may run in to trouble reading/writing from the gumstix and host at the same time though.
Here are the compiled rootfs/uImage/uboot for overo in peripheral mode:
Composite device notes
“Composite device” is provided by the g_multi kernel module, so you need to add it (it’s not in the above images, I’m still trying this out)
set:
CONFIG_USB_G_MULTI=m
in org.openembedded.dev/recipes/linux/linux-omap3/overo/defconfig
Clean the build…
bitbake linux-omap3 -c clean
and rebuild as above.
Other notes
http://wiki.gumstix.org/index.php?title=Category:How_to_-_usb
Open Embedded build system setup:
http://www.gumstix.org/software-development/open-embedded/61-using-the-open-embedded-build-system.html
fakeroot failed on my first attempt, but not my second… hmmm. I needed to do this:
ERROR: The checksums for “/home/new/overo-oe/sources/fakeroot_1.9.6.tar.gz” did not match. so had to:
Because this version of fakeroot is no longer present in the Debian repositories.
Edit: ~/overo-oe/org.openembedded.dev/recipes/fakeroot/fakeroot_1.9.6.bb
Change:
SRC_URI = "${DEBIAN_MIRROR}/main/f/fakeroot/fakeroot_${PV}.tar.gz \
file://configure-libtool.patch"
to
SRC_URI = "http://www.atmel.no/buildroot/source/mirror/fakeroot_1.9.6.tar.gz \
file://configure-libtool.patch"
To clean a build:
bitbake linux-omap3 -c clean
Composite device notes:
From http://blog.felipebalbi.com/?p=44 (now offline):
USB Composite Gadget Framework
Hi all,
Let’s take a look at the brand new, yet-to-be-merged USB Composite Gadget Framework.
The framework was introduced by Linux USB Developer David Brownell and, thanks to his great work, we’re gonna be able to reuse what we now call usb function drivers into another entities, combining them to create a usb composite gadget.
Quoting Dave himself:
We want to split most of the current gadget drivers into reusable/combinable “usb_function” entities, making it easier to set up composite and multi-configuration gadgets.
The framework allowed us to write simpler usb function drivers and glue code between the various kernel APIs and later on, with the framework provided in drivers/usb/gadget/composite.c, create our own composite gadget.
Basically, we just have to provide a struct usb_function with the correct function pointers to the upper layer and that’s all. This is how struct usb_function is defined:
struct usb_function {
const char *name;
struct usb_gadget_strings **strings;
struct usb_descriptor_header **descriptors;
struct usb_descriptor_header **hs_descriptors;
struct usb_configuration *config;
int (*bind)(struct usb_configuration *,
struct usb_function *);
void (*unbind)(struct usb_configuration *,
struct usb_function *);
int (*set_alt)(struct usb_function *,
unsigned interface, unsigned alt);
int (*get_alt)(struct usb_function *,
unsigned interface);
void (*disable)(struct usb_function *);
int (*setup)(struct usb_function *,
const struct usb_ctrlrequest *);
void (*suspend)(struct usb_function *);
void (*resume)(struct usb_function *);
struct list_head list;
};
Let me explain each member of this structure.
name: give a name to this usb_function
descriptors: fullspeed descriptor headers
hs_descriptors: same as above but with highspeed endpoints
config: the configuration
bind: will be called on an upper layer (likely) to bind this interface and combine it into the device structure, also allocate any needed resources
unbind: release used resources
set_alt: set alternate setting we need to use now
get_alt: get the current alternate setting been used
disable: disable endpoints
setup: setup ep0 functionality
suspend: put the function driver in suspend mode (for pm)
resume: wake function driver up from suspend mode
In Dave’s series, he already splitted (the example gadget) and Gadget Serial into reusable function drivers. In the case of Gadget Serial he also wrote the glue code for the TTY over USB.
All of you are invited to help us writing other function drivers and also splitting the existing gadget drivers into reusable entities like it was done for Gadget Serial.
I’m putting together some small tips in this page so feel free to take a look and start hacking the Linux Kernel.
Don’t forget to check out linux-usb archives here to keep track of what’s happening with this framework.
See y’all
That links to this post:
http://marc.info/?l=linux-usb&m=121130809918740&w=2 text:
We’ve had various discussions on this topic in the past, and I think
this approach is pretty much ready to go now, apart from finishing
some of the gadget driver conversions. (Which I’m on the hook for…)
A brief recap: we want to split most of the current gadget drivers
into reusable/combinable “usb_function” entities, making it easier to
set up composite and multi-configuration gadgets. Examples include
CDC WHCM (wireless handsets) and utility combinations like combining
an Ethernet model network link and a mass storage function. A device
class that’s standardized by USB-IF is an especially good candidate
for combining in this way with other functions.
Following this are eight patches:
– Add some new utilities to support descriptor copying. When
one function shows up multiple times (in the same configuration
or different ones) each instance generally needs new descriptors
because the endpoint and interface IDs are not the same.
–
into which functions can be plugged by the gadget driver.
– Gadget Zero updated to use this framework, in three parts.
This driver is just for testing, and isn’t aiming for re-use
so much as simplified code; its current clients don’t expect
to talk to composite devices.
* Split out a source/sink configuration driver.
* And a loopback configuration driver
* Convert the core to use those split-out drivers,
along with the new mid-layer code
– Serial gadget (with recent updates posted last week) updated,
also in three parts. This is more of a real-world example of
how this framework can work and add value.
* Split out a CDC ACM function driver
* And a “generic serial” one
* Convert the core to use those split-out drivers, etc
Unfortunately these changes are extensive enough that intermediate
patches wouldn’t be even vaguely useful … the only patch splitting
that seemed like it would facilitate review is what I did here: to
show the split-out functions (reviewable in conjunction with original
code) in patches of their own, and then a conversion patch which is
probably not very reviewable.
That is: the easiest review is probably of the resulting files,
not the conversion patches. I suspect you’ll agree that these
function drivers are a *lot* cleaner looking than the gadget
drivers they came from!
————————————————————————————-
More composite device info here: http://lwn.net/Articles/395712/
RSS