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.
Related
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...
For testing purposes I need to power off a USB device from my computer programmatically. The microprocessor in the USB device is ARM Cortex M4.
I have tried using Devcon, although the device was disabled, power was still provided to the device.
I have also tried to disable the USB root hubs ,that also didn't work.
I have read some other posts indicating that a SSR could be used, this option is not desired. I would rather choose the software solution(if there is one of course).
Some other answers have indicated that this is an OS issue, and some others a chip-set architecture issue.
So my question is what options are there available. And also is this purely something dependent on the computer side or do we need to implement something on the USB device side as well.
Thank you in advance.
I am currently trying to use LibUSB to directly access the firmware controller on a USB device. How do I directly download firmware off a USB device so it can be modified later (using either the SCSI commands or the LibUSB library)?
The closest thing you'll find to a standard here is the USB Device Firmware Update (or "DFU") protocol. However, there are a number of major caveats:
Most USB devices do not have updatable firmware at all. The majority of devices have their functionality fully defined in hardware, or in mask ROM.
Of the devices that do have updatable firmware, most do not use USB DFU to do so.
Even of the few devices that do support USB DFU, most do not support the "UPLOAD" command to retrieve firmware from a device. (It serves very little purpose in most devices.)
If you run into one of the rare devices that does fully support DFU, you may be able to interact with it using dfu-util. However, this is very unlikely.
We are developing an embedded system which will use a PC motherboard running Linux or Windows Embedded (have not decided which one). The board will read data from FPGA via PCI Express.
Novice question: do we have to develop our own PCIe driver or we can use something from the operating system? If we need our own, can you recommend a resource?
It really depends on what kind of data you want to transfer with the device. If you just want register read/write you could just mmap /dev/mem and have a user space driver.
If you need to do DMA or interrupt then you'd likely have to write your custom driver.
Yes, unless your device corresponds to a standard device profile, you will need a custom device driver. Because you have not selected your operating system yet, your question about resources is pretty wide open still since obviously the OS selection directly affects driver design. For Windows you probably want to start here. Under Linux, perhaps here.
Is there anyway that you can expose local partition or disk image through your computer usb to another computer to appear like external drive on mac/linux/bsd system ?
I'm trying to play with something like kernel development and I need one system for compiling and other for restarting/testing.
With USB: Not a chance. USB is unidirectional, and your development system has no way of emulating a mass storage device, or any kind of other USB device.
With Firewire: Theoretically. (This is what Apple's target disk mode is using.) However, I can't find a readily available solution for that.
I'd advice you to try either virtualization or network boot. VirtualBox is free and open software, and has a variety of command line options, which means it can be scripted. Network boot takes a little effort to set up, but can work really well.
Yet another option, is to use a minimal Linux distribution as a bootstrap which sets up the environment you want, and then uses kexec to launch your kernel, possibly with GRUB as an intermediary step.
What kind of kernel are you fiddling with? If it's your own code, will the kernel operate in real or protected mode? Do you strictly need disk access, or do you just want to boot the actual kernel?