C6A816x PCIe subvendor & subdevice ID

Hi,

Yes, this is user configurable that is usually initialized prior to enumeration. See device memory map for Type 0 Configuration registers (SUBSYS_VNDR_ID Register) for details.

Best regards, Zegeye

Zegeye

Would the PCI IDs be configured by Xloader, Uboot or Linux?

thanks

steve

 

 

 

 

 

 

 

 

 

 

Zegeye

>>Having said that, if you have selected the PCIe Boot, then the above registers (VENDOR ID and DEVICE ID) would be initialized with the values shown above.

The vendor and Device ID belong to TI and I'm not concerned with changing them. 

What I am concerned with is setting the Subvendor  and Subdevice ID before the OS (i.e Windows) has enumerated the PCIe bus.  This would have to be done by some sort of bootloader running on the ARM when it comes out of reset.  I'm trying to understand which bootloader will do this.

We will eventually be loading ARM+DSP code via PCIe boot.

-steve

 

Hi,

I have asked the Linux guy to reply to you and he will do so. I am not familiar with what Linux.

In the mean time, I think one way to handle your concern is by you developing a secondary bootloader. You then can use PCIe Boot or any other Boot Mechanism of your choice that is available as a primary bootloader to download your code and your coder reconfigures the PCIe for enumeration.  The secondary bootloader will re-configure the controller by writing onto the sub-VendorID and sub-DeviceID. The PCIe bootloader does not modify these fields.

Linux might have a way to handle this. Wait for a response from a Linux knowledgeable person.

Btw, if you use other booting mechanism, you would probably need to modify the VENDOR ID since the default value is a wrong value.

Best regards, Zegeye

Zegeye

Sounds like Xloader needs to set the PCI IDs

>>you would probably need to modify the VENDOR ID since the default value is a wrong value.

Is it not 0x104C?.

-steve

Hi,

Yes, the default value should have been 0x104C and it is not.

Best regards, Zegeye

So if there is no loader, it sounds like we could customize/patch boot to set the pcie Ida. This assumes that boot loads and runs BEFORE the host OS enumerates the PCIe bus -Steve

I have now read the C6A816x Boot section of the updated Tech Ref manual

Section 19.8.5 states that only the vendor and device ID are set (by the boot ROM)

So what happens when Vendor A and Vendor B both have C6A816x based PCIe devices on a PCIe bus?. 

During enumeration, because the subvendor+subdevice ID cannot be set, then the root complex cannot tell the products apart.

-steve

Steve,

You are considering a system with two different  kind of C6A816x based devices right? In such case, both the devices/boards need to use alternate boot method as I mentioned to override Subsystem IDs before root complex enumerates them.

While, if the devices/boards are of same type, they can have same IDs and the driver running on root complex (RC) should support handling multiple devices and identify them with device numbers given by the RC.

Do you see concerns here?

-

Hemant

Hemant

The product I am envisioning would be a PCIe plug in card for a Windows based computer (PC)

It must have a subvendor/subdevice ID to distinguish it from other C68A8xxx based devices and also to identify iys PCI class code

Originally, I thought that all code would be loaded by Windows after the computer has booted up using the PCIe boot mode (Boot mode 11000).

Now, because I have to set the PCIe subvendor/device info, I will be forced to boot from say an SPI flash device, set my PCIe info and then somehow branch to the original PCIe boot code - how would you do this?. (I see no documentation on this.)

Sounds like the PCIe boot process was not thought out too well........

thanks

steve

 

Hi Steve,

I agree that it seems that this is the only way forward, although I doubt it's supported to work this way. I think (but don't know for sure) the intention for the peripheral boot mode is to be used only in the production (where the IDs most properly doesn't matter) and not for final end product usage. At least this is the way that peripheral booting over UART/USB is intented to work...

I however totally agree, that this would had been a smart feature (assuming that the PC can reset/power-up an add-on card over PCIe when the host OS is running? I don't know if this is supported in the PCIe-interface, but I assume it is?), thereby not needing any flash on the board itself, but being able to load all board software form the host OS over PCIe :-)

For the future however, with a little luck the PCIe IDs are as well made of EFUSES, which (again with a little luck and being a high volume customer) might be changed on a customer basis? For further info about this idea please see my reply to your other recent post with respect to MAC addresses at: http://e2e.ti.com/support/dsp/integra_dsparm/f/625/p/82859/285701.aspx#285701

For now I think the most official way forward will be to have a boot loader (stored in SPI flash) loading a linux-kernel over PCIe and thereby not usilize PCIe ROM code booting. The idea of setting the IDs and jumping back to the ROM code might work, but I bet it's not designed to work this way (=> you won't find any information about it in the TRM - Unfortunately)

Best regards - Good luck
  Søren