As I know, on PPC460GT doesn't support for USB functions. But I saw in my PPC460GT, it has a FT313H Chip, a USB 2.0 Host Controller Device. Can anyone tell me what can I do to enable USB 2.0 function based on FT3131H Chip on my PPC460GT.
You have to know how you can communicate with this controller. If you have it on board then it has to be accessible somehow from CPU point of view - at some address. If you have address you can remap it for linux kernel and then you have access to it EHCI registers.
Related
My embedded linux board has usb-net gadget functionality. From my host computer I am able to establish ethernet over usb connectivity. I am trying to understand how the different layers of the usb gadget subsystem layers work together.
In the device tree, I can see the platform specific udc driver and in the kernel configuration I can see the USB Gadget and Ethernet Gadget support being enabled in the kernel drivers. So as I understand the g_ether driver gets built-in part of the kernel.
What configuration creates the usb gadget interface and endpoint and links it to the upper layer driver (g_ether) and creates the usb-net gadget ethernet interface ?
Where to define the usb class function of the gadget and load a different upper layer driver ?
I am running version 5.10.36 kernel on my system. After some research and study, this is what I know so far.
So during linux kernel build, I have following option setup in menuconfig.
Symbol: USB_ETH [=m]
Prompt: Ethernet Gadget (with CDC Ethernet support)
Defined at drivers/usb/gadget/Kconfig:628
Depends on: <choice> && NET
Location:
-> Kernel configuration
-> Device Drivers
-> USB support (USB_SUPPORT [=y])
-> USB Gadget Support (USB_GADGET [=y])
-> USB Gadget Drivers (<choice> [=y])
This configuration gives a predefined USB net gadget interface with CDC ethernet support and required end-point configuration. This driver is g_ether.
The end point configuration is predefined in the file
drivers->usb->gadget->function->f_ecm.c
configFS can be used to configure a custom usb gadget interface from the user-space level.
I'm trying to create a usb based ethernet device on my computer, basically I want to tell my computer (linux based) that one of its usb ports is actually an ethernet port. I have done extensive research and while it's supposed to be possible, I can't find any examples of code / commands to run.
According to wikipedia:
The USB-eth module in Linux makes the computer running it a variation of an Ethernet device that uses USB as the physical medium. It creates a Linux network interface, which can be assigned an IP address and otherwise treated the same as a true Ethernet interface. Any applications that work over real Ethernet interfaces will work over a USB-eth interface without modification, because they can't tell that they aren't using real Ethernet hardware.
So in theory, this should be possible, I just need some help or a gentle nudge in the right direction to get this thing rolling. What I'm NOT trying to do is plug a usb to ethernet dongle/adapter into my computer, I have several of those lying around and that doesn't help me out at all.
this is ethernet-over-usb
https://en.wikipedia.org/wiki/Ethernet_over_USB
without external hardware you can try the CDCether kernel module and ethtool ( then you can only connect to a usb device that operates in usb device mode )
( https://developer.ridgerun.com/wiki/index.php/How_to_use_USB_device_networking , http://tldp.org/HOWTO/Motorola-Surfboard-Modem/usb.html, http://www.linux-usb.org/usbnet/ )
else you need a physical adapter for this. the adapter translates between the protocols and the different hardware interfaces.
in usb protocol can only be one host in a network, therefore you need at least a host-to-host cable ( http://www.linux-usb.org/usbnet/ ) if you want to connect two usb host devices, i.e. two pcs
required kernel module ( driver ) when using a physical adapter is either usbnet ( with its minidrivers ) or usb-eth
I would like to implement a USB device driver in user space by means of libusb. I'm using a Linux machine supporting a USB OTG controller which is switched to device mode. The USB host is another machine which needs to communicate with my Linux machine by means of a USB vendor specific interface with a bulk in/out interface.
I would like to know if it is possible to use libusb to communicate with the USB host on the other side. Or, if libusb could be used only for host side functionalities.
If libusb can't be used is there any other way to implement the device driver in user space?
Thank you.
As of my knowledge this is not possible. (Vanilla) libusb is only for host usage because the whole process of how to use libusb can only provide this mode.
You can find an answer in the FAQ of the old libusb (before libusbx, the abandoning of the old libusb and the rename of libusbx to the new libusb):
libusb FAQ
Also there is a question on SO to this topic with some suggestions:
How to communicate with the USB Host from a Linux USB Client
I have a linux platform* that is connected as a usb device to an automotive device which acts as the USB host. The two devices should communicate over CDC/NCM, but the linux platform is not recognised by the automotive device and therefore the connection is not established. Surprisingly a connection to my computer is established correctly.
I now need to create a trace of that USB connection in order to check if there is an error in the USB handshake that can't be handled by the automotive device. As I cannot access the USB host, I need to create the trace from the gadget side.
I tried using usbmon and tcpdump, but this seems to work only for USB controllers configured as hosts on the tracing platform, not for ones configured as devices.
How can I configure usbmon to work also on devices?
If that is not possible are there any other possibilities to achieve this? (preferrably without hacking any drivers...)
Or do I have to use a Hardware USB sniffer?
BTW, all required modules (esp. g_ncm) are correctly loaded.
Thank you for your help!
stefan
*custom distribution on a freescale iMX6 processor (ARM), Kernel Version 3.0.35
I've finished developing a pcie driver for an FPGA under a linux distributiuon. Everything works fine. But I'm wondering where the base address register in the PCI Endpoint of the FPGA gets the base address. When I've generated the PCIe Endpoint I was able to set up the length of the BAR, but not more.
In the PCIe driver I do the standard functions like pci_enable_device, but I do not set up specifically a base address.
So does the operating system set up the base address during startup? or how does it work?
By the side I would like to know what initialisations the operating system gernerally do if an pcie pcie device is connected. Since I do see my pci device in lspci even if the driver is unloaded.
Kind regards
Thomas
The address allocation for the PCI devices are generally done at the BIOS level. Let us refer to the x86 platform. If we look closely at the system address map, it would be something like this (image taken from BIOS DISASSEMBLY NINJUTSU, by Darmawan Salihun)
On the address map, there is a dedicated space to map the PCI memory regions. The same could be replicated using the output of /proc/iomem.
This implementation is platform dependent, and as the BIOS "knows" about the platform, it would set aside the addresses dedicated to the PCI slots. When a device is plugged into the slot, the BIOS interacts with the firmware on the device and actually sets up the memory regions for the device, such that the OS could make use of it.
Now coming to the drivers part. In Linux, the drivers follow a specific standard known as the 'Linux Device Model', which constitutes a Core Layer(PCI core), Host Controller Drivers(PCI Controller/Masters) and Client Drivers(PCI devices). When the PCI device(client) is plugged into the slot, the corresponding host controller knows about the attachment and it further informs the PCI core about it, and hence appears in the output of lspci.
lspci shows the devices which are identified by the host controller, in which case, it may or may not be tied to a driver. The core further traverses the drivers in the system, finds a matching one, and attaches to this device.
So, the reason you are seeing the device in the output of lspci is because the host controller has identified the device, and has informed the PCI core. It doesn't matter even if any driver is attached to the device or not.
On most consumer grade computers, BAR allocation seem to be done in the BIOS.
I suppose that in a hotplug capable architecture this must be done or at least triggered by the OS.