X-Git-Url: https://git.kernelconcepts.de/?p=karo-tx-redboot.git;a=blobdiff_plain;f=doc%2Fhtml%2Fref%2Fusbseth-host.html;fp=doc%2Fhtml%2Fref%2Fusbseth-host.html;h=0000000000000000000000000000000000000000;hp=a6db01224d4e3509ce6f858e0c142e017dc151d9;hb=739c21725ce2774a605a0f1de3edaac2c43aea0f;hpb=ae71e0fa8076a1b59600b3a0ea10155a2cb534ae diff --git a/doc/html/ref/usbseth-host.html b/doc/html/ref/usbseth-host.html deleted file mode 100644 index a6db0122..00000000 --- a/doc/html/ref/usbseth-host.html +++ /dev/null @@ -1,338 +0,0 @@ - - - - - - - - -
The USB-ethernet package is supplied with a single host-side device -driver. This driver has been developed against the Linux kernel -2.2.16-22, as shipped with Red Hat 7. The driver is provided as is and -should not be considered production quality: for example it only -checks for a bogus vendor id 0x4242 rather than an -official vendor id supplied by the USB Implementers Forum. Also, if the -peripheral involves multiple configurations or multiple interfaces, it -will fail to detect this. However, the driver can be used for simple -testing and as the basis of a full device driver. Details of the -protocol used between host and peripheral can be found in the Communication Protocol section.
The host-side device driver can be found in the host subdirectory of the USB-ethernet -package, specifically the file ecos_usbeth.c, and -comes with a Makefile. Both files may need -to be modified for specific applications. For example, the vendor id -table ecos_usbeth_implementations may need to be -updated for the specific USB peripheral being built. The -Makefile assumes that the Linux kernel sources -reside in /usr/src/linux, and -that the kernel has already been configured and built. Assuming this -is the case, the device driver can be built simply by invoking -make with no additional arguments. This will result -in a dynamically loadable kernel module, -ecos_usbeth.o, in the current directory.
Note: As normal for Linux kernel builds, the generated files such as -ecos_usbeth.o live in the same directory as the -source tree. This is very different from eCos where the source tree -(or component repository) is kept separate from any builds. There may -be problems if the component repository is kept read-only or if it is -put under source code control. Any such problems can be avoided by -making a copy of the host -subdirectory and building that copy.
Loading the kernel module into the current system requires root -privileges. If the generic USB support is also a loadable module and -has not been loaded already, this must happen first:
# insmod usb-uhci -Using /lib/modules/2.2.16-22/usb/usb-uhci.o |
Depending on the host hardware, the uhci or -usb-ohci modules may be more appropriate. Loading -the generic USB module will typically result in a number of messages -to the logfile /var/log/messages, giving details -of the specific host-side hardware that has been detected plus any -hubs. The next step is to load the USB-ethernet module:
# insmod ecos_usbeth.o |
This should result in a number of additional diagnostics in the -logfile:
Apr 1 18:01:08 grumpy kernel: eCos USB-ethernet device driver -Apr 1 18:01:08 grumpy kernel: usb.c: registered new driver ecos_usbeth |
If a suitable USB peripheral is now connected the host will detect -this, assign an address in the local USB network, obtain enumeration -data, and find a suitable device driver. Assuming the peripheral and -device driver agree on the supported vendor ids, the -ecos_usbeth.o module will be selected and this -will be reported in the system log:
Apr 1 18:04:12 grumpy kernel: usb.c: USB new device connect, assigned device number 3 -Apr 1 18:04:12 grumpy kernel: eCos-based USB ethernet peripheral active at eth1 |
What can happen next depends very much on the software that is running -on top of the USB-ethernet package inside the peripheral. For example, -if there is a TCP/IP stack then it should be possible to bring up a -network connection between host and peripheral using -ifconfig.