I am facing a problem when i try to read from usb device at u-boot.
When i do
fatls usb 0:1
it says bad device. But as soon as i do
usb start
fatls usb 0:1
then it shows me correcly the fat partition in USB.
I was looking to add both commands in the common/main.c so that whenever the board boots it looks for the fat partition of USB.
It is tough but i need to do it.
Anybody has a clue??
As has been said in the comments, "usb start" is what initializes the USB subsystem and scans attached devices for things U-Boot can deal with (USB sticks, ethernet, etc). Unlike some buses such as MMC that we will do an initial scan on prior to starting the shell, for USB you must run the start command first if you expect to use devices that are attached.
Now, you don't add things to common/main.c, you add things to the bootcmd environment variable (and this can be changed in the boards config.h file so that the default environment is changed, if you are working on a board where you cannot do 'saveenv' to save your changes in a persistent way). So what you would want to do is:
=> setenv bootcmd 'usb start;fatls usb 0:1'
or whatever commands you wish to do with the files present on the USB stick.
Related
I know that the Raspberry Pi Zero supports OTG and USB Peripheral protocols, and there's a lot of cool built in peripherals shown here: https://learn.adafruit.com/turning-your-raspberry-pi-zero-into-a-usb-gadget?view=all#other-modules
The problem is that I need to emulate a USB Peripheral device that does not appear on this list. I have a vendor ID and product ID for the device, and I'm trying to figure out how exactly to go about doing this. Do I need to modify the OTG USB drivers in the Raspbian kernel? Do I have to completely build my own kernel? Or is there a better option I don't even realize?
Thanks in advance!!
Do I need to modify the OTG USB drivers in the Raspbian kernel?
The answer to your first question is "it depends", but if your device
doesn't do anything too unusual this could be a No: you need not
modify source code for kernel modules nor the kernel.
You're fortunate that Raspbian supports a modern kernel with ConfigFS support. Once you are set up with dtoverlay=dwc2, you can open up a FunctionFS bulk endpoint as root like so:
modprobe libcomposite
modprobe usb_f_fs
cd /sys/kernel/config/usb_gadget
mkdir -p myperipheral; cd myperipheral
echo 0x1234 > idVendor # put actual vendor ID here
echo 0xabcd > idProduct # put actual product ID here
mkdir configs/c.1
mkdir configs/c.1/strings/0x409
echo "My Peripheral" > configs/c.1/strings/0x409/configuration
mkdir functions/ffs.my_func_name
ln -s functions/ffs.my_func_name configs/c.1/
mkdir -p /tmp/mount_point
mount my_func_name -t functionfs /tmp/mount_point
# compile ffs-test from source, then copy and run it from /tmp/mount_point
ls /sys/class/udc > UDC
If you need to emulate the other device more closely, it's up to you to set bcdDevice, bcdUSB, serial number, manufacturer, product string, max power, os_desc, and possibly other fields.
AFAIK FunctionFS does not support isochronous endpoints, interrupt transfers, nor out-of-the-ordinary control transfers. If you require this, you may need to start looking into extending existing gadget modules, with source code here.
Update: When I got home to test this, I encountered a severe caveat with Raspbian. It'll initially fail to create ffs.my_func_name because usb_f_fs is not enabled by default. Although you need not modify any kernel modules, you must recompile with an alternate configuration. make menuconfig -> Device Drivers -> USB support -> USB Gadget Support -> USB functions configurable through configfs / Function filesystem (FunctionFS) + some other modules to test. After uploading a new kernel/modules, I tested the above script on Raspbian 8. I would also recommend setting USB Gadget Drivers / Function Filesystem to (M) in case you resort to the simpler g_ffs legacy module in lieu of ConfigFS.
I read from LDD3 chapter 14 about hotplug drivers.I need to write a usb mouse driver which load when I plug the hardware. Now, doing some experiment I come to know that there is a driver named "hid-generic" which is called when plug-unplug.
[ 6654.232046] usb 3-1: new low-speed USB device number 3 using uhci_hcd
[ 6654.462061] usb 3-1: New USB device found, idVendor=093a, idProduct=2510
[ 6654.462067] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 6654.462071] usb 3-1: Product: USB OPTICAL MOUSE
[ 6654.462074] usb 3-1: Manufacturer: PIXART
[ 6654.489316] input: PIXART USB OPTICAL MOUSE as /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/input/input12
[ 6654.489445] hid-generic 0003:093A:2510.0004: input,hidraw0: USB HID v1.10 Mouse [PIXART USB OPTICAL MOUSE] on usb-0000:00:1d.1-1/input0
Also lsmod shows,
Module Size Used by
hid_generic 12541 0
usbhid 47259 0
hid 105241 2 hid_generic,usbhid
psmouse 102541 0
My doubts are as follows,
1) To make my module load (hotplug) when this mouse plugs in, I have to disable these 3 drivers in kernel and build whole kernel with my driver with vendor and device ID in id_table. Right?
2) I also read about USB core drivers and USB device drivers. So these HID drivers are core drivers or device drivers?
3) Which are core drivers and device driver in case of USB mouse? And where can I find them in kernel source?
Thanks,
Sunil.
I'll try to answer your questions one by one :
1) To make my module load (hotplug) when this mouse plugs in, I have to disable these 3 drivers in kernel and build whole kernel with my driver with vendor and device ID in id_table. Right?
Yes, but there are some additional things you need to take care of. First understand how a particular module(driver) gets loaded. The key to this is MODULE_DEVICE_TABLE(usb, &my_id_table); Whenever a particular module is "installed" (using make modules_install), an entry, according to the id table passed in MODULE_DEVICE_TABLE gets created in /lib/modules/<your_kernel>/modules.usbmap and /lib/modules/<your_kernel>/modules.dep file(search for the string "usbhid" in the files). Whenever a new usb device is detected, the kernel reads these files to find the matching parameters. If it is found, the following module is loaded from the corresponding path found in /lib/modules/<your_kernel>/modules.dep which holds the info. about the path where the driver is located and also its dependencies.
So, now even if you unload(rmmod) usbhid from the kernel, it will be loaded again when you re-insert your mouse. To avoid this from happening you need to modify those files, i.e. remove the entries from the files. To do so, "move" the usbhid driver from its original path(generally located at /lib/modules/<your_kernel>/kernel/drivers/hid/usbhid/usbhid.ko to a safe place. Now rebuild the dependencies such that the entries would be removed from the dependency files.
Now you need to create entries of your driver. Just install your driver and you are good to go!
So, to summarize :
$ sudo rmmod usbhid # Unload the usb mouse driver
$ cd /lib/modules/$(uname -r)/ # Move to your current kernel
$ vim modules.usbmap # Check for the "usbhid" string
$ vim modules.dep # Check for "usbhid.ko:" string
$ sudo mv kernel/drivers/hid/usbhid/usbhid.ko ~/Desktop # Take backup of your current
usb mouse driver
$ sudo depmod -a # Rebuild the dependency files
Now check the dependency files for the string "usbhid" again. It shouldn't be there!
$ cd /path/to/your/driver
$ sudo make modules_install # Install your driver into /lib/modules/$(uname -r)/extra
$ sudo depmod -a # Rebuild the dependency files
After this step, search for the string corresponding to your module in the dependency files, and it should be there! From this moment on, whenever you insert the mouse(or from boot itself) your driver will be loaded, instead of the original.
Once your are done playing with your driver, you may copy back the original usbhid file to its original destination and rebuild the dependency files (sudo depmod -a)
Now I also see that you are trying to use vendor and device id to match your device, in which case, the driver would work only for your mouse. The recommended way is to use class ids, which makes your driver work for any usb mouse.
2) I also read about USB core drivers and USB device drivers. So these HID drivers are core drivers or device drivers?
usbhid is basically a "device driver". The classification of drivers could be briefed out as : core drivers, host controller drivers and device drivers :
Device Drivers : This is the software used to control the devices. For example usb mouse, pci based ethernet card, usb pendrive, i2c based accelerometer.
Host Controller Drivers : This is the software written to control the bus controller. For example USB Host Controllers(EHCI, UHCI, OHCI, etc.), PCI Host Controller, I2C Masters, etc.
Core Drivers : These actually glues up the above discussed drivers. Examples are USB core, PCI core, etc. Core drivers provides helper routines(APIs) such that the device and host-controller driver could make use of them(concept of module stacking!). These are the ones, which bind the correct device to its driver. There are many other services provided by the core drivers.
Example code for USB Device Driver :
http://lxr.free-electrons.com/source/drivers/hid/usbhid/usbmouse.c
You may find the USB Host Controller Drivers under :
http://lxr.free-electrons.com/source/drivers/usb/host/
USB Core resides here : http://lxr.free-electrons.com/source/drivers/usb/core/
I think this also answers your third question!
Hope this helped.
The device driver is usbhid.
To prevent it from attaching to your device, add a HID_QUIRK_IGNORE entry to drivers/hid/usbhid/hid-quirks.c, or use the quirks parameter of the usbhid module.
After having set-up and customized my "master" BeagleBone Black (BBB) with applications etc. on the on-board eMMC, I want to duplicate it on other BBB boards.
What is the best way to duplicate the BBB?
My understanding of options:
SD-Card: Programming each board by inserting a prepared SD card containing an image and pressing the "boot" switch while powering up.
How should I prepare that .img file or the SD card from my master BBB?
The image should copy to the on-board eMMC, so that the SD-card can be removed afterwards.
USB: Programming by connecting the board over USB to a (Win7) PC.
Is it possible to write the full on-board eMMC from the PC?
With which app to do the writing?
How to prepare the image which will be written, starting from the master BBB?
Ethernet: Programming over LAN after boot-up with default angstrom distro.
Is it even possible over LAN?
How to do the writing?
How to prepare the image which will be written, starting from the master BBB?
Which is possible/best?
Edit: My current solution is to flash with a standard image (from the BeagleBoe website) and then have a script do all modifications as expected. This includes disabling many services I don't need, installing applications and configuring stuff etc.
If there is an easier way for making a SD card with a full image on it, I'm still interested.
As noted at the bottom of the eLinux article, there is a much easier way if you are running the Debian distribution:
Boot master BBB with no SD card in
Insert SD card
Log in (e.g. with serial terminal, SSH etc.) and run sudo /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh. LEDs will flash in sequence whilst SD card is being written.
When the LEDs stop and the script terminates, remove the SD card.
Insert SD card into new BBB then power on.
eMMC will be flashed; LEDs on new BBB will flash in sequence until complete.
For anyone else that needs this, the best answer I've found to this is to do the following:
First setup your master Beaglebone Black the way you want it.
Backup the eMMC
FAT format a 4GB or larger SD card (must be a MBR/bootable formatted microSD card)
Download beagleboneblack-save-emmc.zip and extract the contents onto your SD card
Note: this is an image from Jason Krinder at his github https://github.com/jadonk/buildroot using the save-emmc-0.0.1 tag
Put the card into your powered off Beaglebone Black
Power on your Beaglebone Black while holding the S2 Button
The USR0 led will blink for about 10 minutes, when it's steady on you have an SD card with a copy of your eMMC in a .img file
Use the eMMC to flash a new Beaglebone Black
On the SD card edit autorun.sh
#!/bin/sh
echo timer > /sys/class/leds/beaglebone\:green\:usr0/trigger
dd if=/mnt/<image-file>.img of=/dev/mmcblk1 bs=10M
sync
echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger
where <image-file> is the image file you got after copying backing up your eMMC
Insert the card into your powered off Beaglebone Black
Power on your Beaglebone Black while holding the S2 Button
The Beaglebone Black should go into rebuilding mode and within about 20 minutes you'll have a newly flashed Beaglebone Black (when all 4 USR LEDs are solid) with a copy of your original
eLinux reference used for this article - http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents
I have the same need and am using dd and nc (NetCat) to save directly on my desktop without having to use an intermediary SD Card. You can do this over the USB connection, or ethernet connection, by changing the IP address in the steps below.
After setting up your BBB with the applications you want, the basic steps are:
On the desktop, run this command in a terminal:
nc -l 19000|bzip2 -d|dd bs=16M of=BBB.img
On the BeagleBone Black, run this command in a terminal (you can SSH into it, or do it directly from the BBB):
dd bs=16M if=/dev/mmcblk0|bzip2 -c|nc 192.168.7.1 19000
The 192.168.7.1 address is for the USB connection. (BBB is 192.168.7.2) If you're doing this over an ethernet connection, you should use your desktop's IP address.
This is taken from instructions here.
Finally, follow any method to install onto the next BBB. Here's an example of how to flash the emmc.
Copying your emmc Image back to a SD card is a bit tricky, since it will need to be formated in a certain way to get it to mount. Here are some tips to get that working: http://dev.gentoo.org/~armin76/arm/beagleboneblack/install_emmc.xml#expand
What might be easier is using an USB thumb drive, or USB SD card reader. Note, currently there are some issues hot-plugging USB devices, so boot with it plugged in.
You can copy your entire FS to the USB drive, then compress it. Create a new bootable linux sd image, and put your compressed FS on there and use one of the scripts Ottavio linked to to copy over the compressed image. you can make a systemd service to launch the script on startup.
We have noticed that on Beaglebones with the Jan 23rd 2015 release of Debian, the only way to successfully copy the image from SD is not to hold the boot button down when powering up.
I am writing a USB device drive for linux. it's for a joystick.
every time plug it in, linux loads a hid driver. is there a way to tell Linux to load mine when I plug it in? or at least not load the default one?
I can echo the id in unbind of the default driver and echo it in bind of my driver; but I would like something more automatic..
thanks
Own USB driver taking precedence over usbhid
If you want to prevent binding to the usbhid driver, you can use its HID_QUIRK_IGNORE (= 4) setting. To stick with the example Karl Bielefeldt used, add
options usbhid quirks=0x15c2:0x0043:0x04
to some /etc/modprobe.d/*.conf file (and perhaps recreate your initramfs). That will tell hid-core to ignore that device. So usbhid will have a look at it but leave it for some other driver instead.
Own HID driver taking precedence over hid-generic
However, if your other driver is a HID driver not an USB driver, then you need usbhid to bind to the driver on the USB level, and you need your own HID driver to take precedence over hid-generic. This is the problem I'm facing my self, and for which I haven't found a solution yet, short of unbinding and rebinding the device later on.
Here's a thread with a fix for a similar problem. To summarize, you add something like the following to one of your /etc/udev/rules.d files:
SYSFS{idVendor}=="15c2", SYSFS{idProduct}=="0043", MODE="0666", PROGRAM="/bin/sh -c 'echo -n $id:1.0 >/sys/bus/usb/drivers/usbhid/unbind;\
echo -n $id:1.1 >/sys/bus/usb/drivers/usbhid/unbind'"
http://lwn.net/Articles/143397/ is very similar to the above answer, maybe some more details.
I have a Linux USB HID device (a Hama MCE), and I can read its events manually by reading cat /dev/input/event7 and cat /dev/input/event8. Whenever I press a key on the device, a few bytes become available for reading with one of the cat commands above. I have a default installation of Ubuntu Jaunty 64-bit desktop on the machine.
I think I can write a parser to interpret the bytes emitted by the device, or I'll use libhid if it's more convenient.
My questions are:
How do I prevent the text-mode virtual consoles from receiving some of the key presses on the device as normal keypresses? As of now, some device keys result an Enter, a BackSpace, a PageUp or numeric keypad numbers.
Similarly, how do I prevent the X server from receiving keyboard and mouse events from this device? I have several USB keyboards and mice connected to the computer. I want the X server receive events from all of them, except for this device.
How do I set up that whenever the device gets connected to the computer, the command /usr/local/bin/keydumper /dev/input/event7 /dev/input/event8 (or one command for each /dev/ path) would get run, with the proper /dev/ paths substituted in the command line?
Answering my own question based on answers from the Linux USB HID driver developers:
Question 1. and 2.: Do
ioctl(open("/dev/input/event7", O_RDONLY), EVIOCGRAB, 1);
As long as this filehandle is open, the events generated would go only
to this filehandle (not to other open()s of the same device or to the
system keyboard or mouse event pool). At most one process can hold a
successful EVIOCGRAB at a HID device at a time. Lirc can be configured
to do an EVIOCGRAB.
Question 3.: Configure udev to start the program once the device is connected.
I do not have enough points to comment sadly.
If you are looking for the definition of EVIOCGRAB try
#include <linux/input.h>
I think solution for all questions can be writing own filter device driver, or custom driver for your device. I know such a thing (filter device driver) is available on windows so something similar can be on Linux. In that filter device driver you could block all unwanted events from the target device that you wish to block, I don't really get 3 question so I don't know how to answer for that.