• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 102 subscribers
  • Views 175 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320C6654: PCIe access from x86 host

Sven Vogler
Prodigy 80 points
Part Number: TMS320C6654

With the 'old' DM642 with a PCI interface any x86 BIOS can access and identify the DM642. Consequently, after booting e.g. Linux in the host, the DSP will be found over PCI and memory map can be programmed. With that I can load over PCI the DSP program and start it to be executed.

I wonder if the same scenario is possible for the C6654 (using PCIe instead of PCI). I doubt that this is possible as I cannot see that the PCIe factory inside the DSP is already prepared with some default memory mapping (as the DM642). Basically, I would like to have the C6654 somehow been set up already as a PCIe endpoint that could be found on boot by any standard x86 host boot process. Once found, memory could be mapped and program code could be loaded to the C6654, either to internal memory or external memory. The 642 has already some memory windows mapped on Power up, I fear the 6654 doesn't.

As far as I see I should be able to boot the DSP over PCIe, but for this, the PCIe endpoint must have been found, and for this some DSP registers must have been already set up, but how could I set them up without having access to them over PCIe ???

Hope that this is not too confusing:  I would like to boot the DSP (loading my program) over PCIe from a Linux x86 system. How would I have to set up this ?

  • 0
    Guru 13042 points

    Hello!

    I have not used this process on my own, so please take following considerations as hypothetical ones.

    With that disclaimer, I think that PCIe was in mind as device booting interface. For that device has BOOTMODE pins, refer 6.24 Boot Modes Supported and PLL Settings clause in data sheet. So lower 3 pins have to be set to b100 for PCIe booting. As you reasonably note, booting process assumes certain access to endpoint memory. Now take a look as Device Configuration field in the same clause, it spans over bits [9:3]. Clause 6.24.2.4 PCI Boot Device Configuration (C6654 Only) provides details about possible configuration upon reset. As one can read in Table 6-68, 6-69, there is a number of BAR combinations possible, and once taken out of reset device will expose these BARs to host. To my understanding, bus enumeration process on the host side will determine number of BARs and their sizes, so host could assign them appropriate windows in its memory map. Also device exposes its configuration registers through BAR0, so host can provide necessary settings there too.

  • 0 in reply to Victor Kazmirenko
    Prodigy 80 points

    Thanks for your answers. In the meanwhile I found some example for a similar processor (C6657) for host-boot loading over PCIe

    (..\ti\pdk_c665x_2_0_16\packages\ti\boot\examples\pcie\linux_host_loader). With this example it becomes clear that the BAR0 is initially always mapped to the PCIe application register space. This means, you have access to those register where you can write other registers that configure the Bar1-Bar5 mapping. Finally I found this in the generic PCIe device description manual for the Keystone devices. Would have been good if this topic (host BOOT from PCIe) would be explained in this document somehow, otherwise people are lost and have to search for examples of how things can be done.

    Thanks