I have a device that is run by a MX51 cpu what I would like to know are:
what steps to take to replace an sd slot with mini usb 3.0 thumb drives? This means physically remove the hardware and install a usb 3.0 port in place of the SD slot.
What drivers would i need to install into the OS on the device?
What else do i need to know hardware men?
Look at the http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX515 from the block diagram click on Block pic. You can see this only support USB2.0
Related
In ESXi console I can see my device with lsusb list
And in vm settings I add new USB Device and select my usb from dropdown list, and save settings.
But after that, I could neither see my device in windows server nor in vm configuration!
And when I try to add new device it doesn't show up in dropdown list anymore.
But still can see my device in lsusb list.
This is because the device in question is a USB storage device, specifically a flash drive. A quick Google has this hit: "S102 Pro Advanced USB 3.2 Flash Drive | Buy Now". AFAIK there is no workaround. Gory details follow in the next paragraph. Peruse at your own risk.
In vSphere ESXi 6.5 and earlier releases of ESXi the USB driver stack was a "vmklinux" driver stack with individual drivers for each device type, including USB host controllers. Thus if your installation was on a SCSI disk or PXE booted over the network you didn't need the USB storage driver at all and you could unload it and then pass the device through to a VM. Unloading the driver wasn't offically supported but could be done at the esxcli command line or if you wanted to be really daring you could delete it from your bootbank image. Note that "deleting" was only theoretical as you would really be replacing the driver module with a file of size 0 in the last loaded tar image (the only one that is customer configurable) and could thus be undone, but I digress.
The new USB native driver stack that debuted in vSphere ESXi 6.7 is a monolithic driver which means that it is not possible to unload only the storage driver. You could unload or clobber the entire USB stack but then you'd lose the keyboard and perhaps other things plus the ability to pass any USB device through to a VM. The disadvantages of monolithic USB drivers are well known and are the reason that Linus himself got involved in the redesign of the long gone Linux monolithic USB driver from over a decade ago, but I again digress. As to why VMware "improved" things by replacing a USB stack with half a dozen or more USB drivers with a monolithic stack with all the attendant disadvantages, you'd have to ask them. Feel free to request that they break the driver up into constituent modules as they know how to do this.
I made a STM32F042k6, battery powered device, that I would to flash vi DFU protocol.
In order to do so I disconnect the battery, I pull BOOT0 to VCC, and then plug the device in USB3 port of PC (no USB2 available). The device is not recognized and showed
VID:0000 PID:0002 (case I)
However, when I first connect battery, and then connect the device to PC it is recognized without a fuss (case II).
The problem I face is that I would like to initiate jump to bootloader program by command in software - but then I reach exactly the same condition as in case I.
Could you help me to identify what conditions for proper boot I am violating?
EDIT:
The way I have discovered the problem was when I implemented software jump to bootloader. It seemed not to work at all (VCP device dissapeared, and erroreous <> device appeard in system PID:0002 VID:0000).
I wanted to enter bootloader by pulling up BOOT0 pin, but I could see that I sucseed only when battery-power cycled. USB power cyccle resulted in the same "failed descriptor" device.
I suspect that when powered on via USB, the booloader has som ecommunication problems and cannot establish proper PID and VID. When powered via battery - this problem is not existing.
Do you have a discovery board?
I read in the STM32F042x4/x6 Reference Manual (DocID025832 Rev 5):
The STM32F042x4/x6 embeds a full-speed USB device peripheral compliant
with the USB specification version 2.0.
(part 3.19, p.27).
In the AN2606 (Rev 33), a table shows the USB configuration which is used by the DFU Bottolader in USB FS (Full-speed):
I assume that the USB in the bootloader is the 2.0, but USB 3.0 must be USB 2.0 compliant. So it is possible to use an USB 3.0 port.
I suggest you use the DfUSe Demo from ST. Its interface consists of a tab where the DFU devices available are displayed when detected. I try it on another STM32x by following these steps:
Open DfuSe Demo software.
Plug BOOT0 to Vdd to put the micro on DFU mode.
Plug the USER USB to your computer port.
The name of your device should appear in “Available DFU Devices” field.
You could try to use directly PA11 and PA12 as well (according to Table 12) instead of the USB port of your board.
EDIT:
Another solution to upgrade your firmware without driving boot0 is to jump directly into the DFU bootloader of ST inside your firmware. Else you could design your own IAP bootloader (In-Application Programming).
I hope that helps.
I faced this same issue with the STM32 Mini F401 and dug into it for several days. Unlike the OP I was unable to find any electrical conditions which reliably got the bootloader to do the right thing. I was able to program my board maybe once every 20 tries, which was really slowing down my process.
In the end I discovered that I can go to the Windows device manager, show hidden devices, and there will be an entry in Universal Serial Bus Devices called STM32 BOOTLOADER. When the issue is happening the board is connected in dfu mode but that device is not marked active in the device manager.
To resolve the issue consistently, you can manually delete the hidden STM32 BOOTLOADER entry, uninstalling the device (no need to delete the driver, just uninstall the device). Then reboot your board in DFU mode and it should connect as expected every time. Unfortunately I need to do this process every time I want to program, but that's far better than the inconsistent/intermittent failures before.
Right. So I've been looking at VBS Scripts and batch files recently and autorun.inf would really be the cherry on the cake (don't worry I don't plan on using it as a tool for evil). I know that it has been turned off by default on Windows 7 onward but I read somewhere that it is still on for CDs. So naturally, I wonder - Is it possible to make the USB drive look as if it were a CD to make autorun work?
a USB pen drive and a USB CD tray have the same device class (USB mass storage device class). the problem is that despite the same device class there are other parts in USB protocol that differ (interface descriptors, configuration descriptors, endpoint descriptors,...) These usb descriptors that are also responsible for what driver / kernel module is loaded by the os, are hardcoded in the firmware of the device. your only chance to make a pen drive appear as a CD is to change these hardcoded descriptors or what is easier, to build your own device using a microcontroller with USB functionality in that you program your custom descriptors. Note that kernel modules and drivers are based on standardized protocol so your descriptors have fit these standards for the device to work.
In http://www.beyondlogic.org/usbnutshell/usb1.shtml is more information about USB protocol and the descriptors...
I am working on Freescale P2041RDB, I have designed my own customized board similar to the RDB. But my board has few changes, like it doesn't have SPD controlled RAM and the CPLD is used only for Reset purpose and my board has a Pericom 1-to-4 PCIe switch. My problem is that when I try to access the PCI devices I am not able to do so. But when I try accessing it through U-Boot the device gets read, but the same thing when I try doing it with the Kernel, my system can't read the devices.
With the P2041RDB the PCIe works fine, I am able to access the PCI Devices.
I am using Yocto Embedded Linux kernel by Freescale.
You need to modify your device tree file according to your custom hardware. Devices are detected through uboot which means hardware wise it is ok but in kernel it is not able to detect which means device tree need to be modify.
Ｉ think you should check the device tree file, to make sure the configuration of PCIe is correct according your board. since u-boot can access your device then there should not any hardware fault on it.
How is it possible to determine the commands to operate a usb device, if that device comes from another operating system and traffic monitoring software cannot be installed on that OS. The only method i can think of is sending random commands to the device, until the device responds, but this seems implausible for more complex commands, and potentially dangerous. For example, consider the DualShock 4 controller. Sony has not made an official driver for this device, so what method can i use to create a linux driver for it?
Get a hardware protocol analyzer. Then you won't need to install any software on the host or device under test. Here is one that I have used:
http://www.totalphase.com/products/beagle-usb12/