During reading various documents I found that:
The PCI Power Management capability ID is 0x1
The MSI Capability ID is 0x5
Is there a list of pre-defined/standardized PCI capability IDs?
Related
I have started reading about PCI and PCIe. I came across a point "From a software standpoint, PCI and PCI Express devices are essentially the same. PCIe devices had the same configuration space, BARs, and (usually) support the same PCI INTx interrupts".
PCIe uses a serial interface while PCI uses a parallel interface. Then how can a linux driver written for the PCI can be used for a PCIe device? I am confused. Please help.
regards,
Ajmal
PCI and PCIe are completely different at physical layer. PCI is parallel where as PCIe is serial. PCI bus is shared by all the PCI devices whereas PCIe has dedicated channel for data transfer.
These differences are taken care at the software layer. So, programmer doesn't need to worry about it.
PCI supports 256B config space. PCIe has 4K config space and is backward compartable for the first 256B
Yeah, PCI is parallel and PCIe is serial and that change is inherent in PHY layer.
PCI supports INTx (1-4) SW interrupts while PCIe supports PCI interrupts and additional 32 interrupts from PCI-X and 2K interrupts
from PCIe.
AER (Advanced Error Reporting) is supported by PCIe
The form of hardware id of nic is like PCI\VEN_8086&DEV_153A&SUBSYS_309717AA&REV_04
I want to get it in UEFI program, but I haven't gotten any tips in UEFI specification.
What you need is EFI_PCI_IO_PROTOCOL.
Refer to UEFI spec 2.6 "13.4 EFI PCI I/O Protocol".
Get all PCI devices handles by calling gBS->LocateHandleBuffer().
Get EFI_PCI_IO_PROTOCOL attached on PCI device handle. (gBS->HandleProtocol)
Call EFI_PCI_IO_PROTOCOL.Pci() to load the PCI configuration space. Everything you need (Device id, Vendor id, Subsystem, Revision) can be found in PCI configuration space.
I've been having quite a time trying to use IPMI tools (such as OpenIPMI, FreeIPMI, and ipmitool) to discover and monitor a PCI device in my server. Using an IBM server going through IMM over the network using the IPMI tools, I can't seem to be able to get any information on the PCI devices in the server. The IPMI tools only return basic information on the system such as the BMC, chassis, power supplies, fans, etc. No information on the devices plugged into the PCI slots.
I've tried basic commands like "fru list", "sdr elist", etc. and haven't been able to get any information from the PCI slots.
Just hoping someone has had experience using these tools and is able to get information from the devices in the PCI slots.
Specifically, I would like to get the FRU information as well as device ID, I2C slave address, etc. for accessing the device.
Thanks for any information that you can provide...
There is no requirement in the IPMI spec that the PCI connector A side pins 40 and 41 that contain the SMBus are routed to the BMC. A vendor may do it but most do not.
Look at it this way, the BMC can turn off power to the PCI bus and main CPUs. You would not be able to read anything from them anyway.
This is why the AdvancedTCA specification requires management power and two IPMB buses to each blade slot. The AdvancedTCA spec requires the IPMB bus from each slot is connected to the BMC. The blade can power up and use a max 15 watts to supply IPM Controller and you can read the data you are looking for without powering on the main CPUs.
Hank Bruning
JBlade
I am looking for vendor independent way of accessing Bluetooth profiles like A2DP, AVRCP , MAP, HFP on XP either using SP2 or winsock.
I am in process of finalizing way to create application for Bluetooth.
I would need to use following profiles apart from service discovery : HFP, A2DP , AVRCP ,MAP.
Till date my study is :
Microsoft XP SP2 provides a basic stack.
I have figured out following ways to do it after going through MSDN:
Winsock.
Winsock support for Bluetooth as a network protocol suite includes the Bluetooth Personal Area Network (PAN) and Dial up Networking (DUN) profiles. Bluetooth support in Windows also includes Bluetooth Human Interface Device (HID) profiles for connecting to keyboards, pointing devices, and other input devices which are unrelated to network protocols. However I don't know how to access profiles of my interest using Winsock.
Microsoft XP SP2 which provides basic stack. It says that profile drivers need to be installed from other vendors. However then these vendors will provide their interface. This will make my application vendor dependent.I am not sure if there is some standard way for communicating with profiles. A From where can we buy profile drivers to build a vendor independent application for accessing profiles as well
So I am trying to figure out that is their some way by which i can make a vendor independent Bluetooth application on Windows XP? How can we access profiles independent of vendor we choose for profile driver installation.
Bth_FAQ.docx (http://msdn.microsoft.com/en-us/windows/hardware/gg487349.aspx)
What is new in Windows Vista?
[...]
• Synchronous connection-oriented (SCO) link support. This support is necessary for the headset and hands-free profiles.
• Kernel-mode device driver interface (DDI) support for Logical Link Control and Adaptation Protocol (L2CAP), Service Discovery Protocol (SDP), and SCO.
[...]
So, in XP there's no API for L2CAP, and apparently there is no SCO support at all. So most of the profiles you list there can't be implemented. :-( MAP is ok as it uses GOEP (i.e. RFCOMM) afaik.
Other stacks may have support: either support for the profiles in-box, and/or an API. Widcomm/Broadcom has API support for L2CAP and apparently Audio too, don't know abut build-in profile support. BlueSoleil doesn't have a L2CAP API but does have built-in support for various of the audio profiles. I don't know much about Toshiba.
As you wrote the supported in-box profiles in Windows XP are: SPP (Serial Port Profile), DUN (Dial-Up Networking), HID and HRCP (Hard-Copy Replacement Profile). The response to your question lays in Microsoft statement: profiles vendors can be added, so what you can do is write your own profiles. The specification of those profiles are public on Bluetooth SIG website, and interoperability should be guaranteed this way between devices.
As per the PCI standard, devices are identified on the basis of Vendor Id, Device Id and the bus no. All devices of same type have identical vendor id and device id. If I put two such devices on the same bus say bus 0. How will the PCI Software Subsystem distinguish between the two?
If such a case is not possible in PCI, then can such thing be possible through PCI Express Switch?
Yes, it's perfectly fine. The host distinguishes identical devices by slot.
PCI and PCI Express devices are identified by Bus/Device/Function, which is necessarily unique per device in the system. Vendor and Device ID are just properties of a device found at a certain Bus/Device/Function.
When enumerating board, a driver will typically scan PCI configuration space (iterate through all the installed PCI devices), until it finds one or more devices that match the expected Vendor and Device ID, and possibly also the subsystem IDs. Once it finds a match, it should record the bus/device/function as a "handle" to the open device.
Properly written software should find all vendor/device matches, put them in a table, and let you pick which one you want to use (e.g. /dev/mydevice0, /dev/mydevice1, etc). However, I have seen lazy software that simply stops at the first match.
As I know, each PCI device can be uniquely described by (Bus,Device,Function). Consider your case(2 devices have identical VID and DID installed) and I think they must be located at different PCI bus ! If they must be in the same bus then please make their Device or Function number different