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.

keystone dsp做PCIE RC端, 并枚举PCIE设备的问题

Hi 各位管理好,

我在使用EVM6657开发板,因为需要6657做PCIE主设备,并且外挂pcie桥设备,所以需要进行PCIE设备枚举。

使用的测试例程是 6657_STK中的PCIE例程, 见附件

例程中配置 bus-0 dev-0 func-0

配置PCIE Application 寄存器中的 cfg 寄存器配置PCIE从设备地址

Configuration Transaction Setup Register (CFG_SETUP)

remote_cfg_setup.config_type= 0; //remote device is EP

remote_cfg_setup.config_bus= 0;

remote_cfg_setup.config_device= 0;

remote_cfg_setup.config_function= 0;

KeyStone_PCIE_remote_CFG_setup(&remote_cfg_setup);

经过KeyStone_PCIE_Init 之后, 可以在 0x2180_2000 地址上读出地址为(bus-0 dev-0 func-0 )设备的配置空间,

这个设备是一个pcie-to-pci bridge设备,其内容如下:

对pcie-bridge 的初始化如下:

1. 配置 bridge 配置空的 memory_base meory_limited 和 prefetch_memory_base prefetch_memory_limited

在例程中定义 memory_base 为 0x1000_0000 size为256M

prefetch_memory_base 为 0x8000_0000 size 为256M

2, 配置 primary bus num 为0, secondary bus no 为1 , subordinate bus no为1 (硬件连接上 pcie-to-pci 桥设备下只有一个pci设备)

3, 配置 command寄存器, 使能memory 和 prefetch memory , disable IO

配置之后的配置空间内容如下:


配置过PCIE-bridge之后, 设置bus-1 dev-0 fun-0 配置application 中的cfg寄存器,

之后,重新读取 0x2180_2000中的配置空间, 按照我的理解, 重新配置pcie设备的地址,从0x2180_2000中读出的配置

空间应该是新设备的配置空间, 如果vendor id为0或者全F,表示设备不存在,

但是我重新配置了 cfg寄存器之后, 读取出来的 0x2180_2000 的配置空间还是桥设备的配置空间, 没有变化,

请教下在扫描过程中, 重新配置 cfg 寄存器中pcie设备的地址之后, 是否需要进行其他操作, 才能从 0x2180_2000位置读取到对应设备的配置空间。

  • 我使用的 STK6657 例程

    STK_C6657.7z
  • 我在 PCIE 的 wiki 

    http://processors.wiki.ti.com/index.php/PCI_Express_(PCIe)_Resource_Wiki_for_Keystone_Devices?keyMatch=6657%20pcie&tisearch=Search-EN

    上面找到一些对PCIE RC端枚举设备的介绍, 其中介绍通过配置 application中的cfg寄存器设置从设备地址, 就可以直接从0x2180_2000地址读出对应的配置空

    间, 但是现在我使用设个步骤, 发现读出的配置空间还是 地址为 bus-0, dev-0 func-0 的桥设备的配置空间,

    Q How to develop the PCIe RC mode driver? Is there any example?

    TI doesn’t provide PCIE RC enumeration example/driver source. Normally the RC runs some operating system that performs the enumeration with the following steps.

    If C66x device is configured as RC, then CFG_SETUP register is used to specify the target bus/device/function numbers for the target device (switch/EP) and try to read/write the remote device space in MMR (from offset 0x2000 in PCIe MMR space) to generate those configuration requests.

  • 如果按照memory 路由访问,bridge上挂接的PCI设备能否正常读取呢?

    另外在访问新的PCI设备时,配置CFG_SETUP新的BUS,DEVICE,FUNCTION number后,代码是怎么去访问新设备的CFG空间的?

    还有一点,可以通过RC去读取PCIe 桥接上的状态寄存器,以此来判别 PCIe 的down stream端口上的PCI设备是否正常,具体要看PCIe协议

  • 如果按照memory 路由访问,bridge上挂接的PCI设备能否正常读取呢?

    管理, 这里的memory路由访问是指通过访问bridge上bar空间的memory地址来访问下级PCI设备吗, 这个bridge两个bar空间的长度都是0

    另外在访问新的PCI设备时,配置CFG_SETUP新的BUS,DEVICE,FUNCTION number后,代码是怎么去访问新设备的CFG空间的?

    配置CFG_SETUP寄存器之后, 我就直接访问 0x2180_2000 地址, 希望从此地址中读到对应设备的配置空间, 但是没有成功, 读到的还是地址0 0 0的桥的配置空间, 是不是我在配置CFG_SETUP寄存器之后, 还需要进行其他操作来重新让新地址的设备配置空间映射到 0x2180_2000地址来, 这里是我比较疑惑的地方

    还有一点,可以通过RC去读取PCIe 桥接上的状态寄存器,以此来判别 PCIe 的down stream端口上的PCI设备是否正常,具体要看PCIe协议

    这部分我来找PCIE桥的文档来找下相应状态

  • 在X86系统上, 可以通过

    0xCF8和0xCFC端口 对应 寄存器CONFIG_ADDRESS与CONFIG_DATA

    首先配置 CONFIG_ADDRESS 即 PCI设备的 bus dev fun reg

    则可以从 CONFIG_DATA 中读出对应配置空间的内容

    在TI芯片上, 这个步骤是不是只要在 CFG_SETUP中配置 PCI设备地址后, 系统就会自动将对应设备的配置空间映射到 0x2180_2000 地址

    还是中间需要其他步骤

  • 需要管理的帮助

  • 1 是的,是指通过memory 空间来访问下级PCI 设备,BAR空间长度都是0?那数据怎么访问下级PCI设备呢?无论BRIDGE的端口还是PCI 设备都应该是作为EP的,由RC统一编址

    2  能不能一上电枚举完成后,直接通过CFG_SETUP然后访问PCI设备,即第一次先配置PCI,不去配PCI桥

  • 1 是的,是指通过memory 空间来访问下级PCI 设备,BAR空间长度都是0?那数据怎么访问下级PCI设备呢?无论BRIDGE的端口还是PCI 设备都应该是作为EP的,由RC统一编址

    如果PCIE-bridge 本身没有需要操作的内存区域,则bridge的bar长度就是0的, 这个是正常的,

    hipcie-bridge 通过 memory_base 和 memory_limited 和 prefetch_memory_base prefetch_memory_limited 来标示 本桥下面所挂的设备的 PCIE地址范围,  

    2  能不能一上电枚举完成后,直接通过CFG_SETUP然后访问PCI设备,即第一次先配置PCI,不去配PCI桥

    这个应该是不可以的,  PCIE扫描的过程是如果扫描到桥, 需要配制桥的 primary_bus , secondary_bus, 和 oriented_bus , 然后才可以访问到 bridge 下面的设备, 不能绕过桥直接初始化下面挂载的设备.

    我觉得现在一个非常关键的问题就是 c66x dsp 中 CFG_SETUP 寄存器,配制完成之后, 是否需要其他的操作步骤, 才能从 0x2180_2000 地址读取对应设备的配制空间

  • primary_bus , secondary_bus, 和 oriented_bus 确实需要枚举软件去配置,以便找到下一BUS上挂的设备。

    PCI 桥上可能也有LINK 状态寄存器或者类似状态寄存器,能不能先读下这类寄存器,首先看看LINK是否能SETUP,下一步再去看CFG空间能不能访问。

    回到您的问题,受限于我们的实验环境,目前我们还只测试过直通的,如果经过桥接,DSP作为RC的场景还没有测试,所以不确定是否需要其他操作。但从协议来看,如果前面LINK正常建立,CFG_SETUP正确,应该是可以的。我们还需要确定一下。

    能否把你这部分的配置代码和PCI桥的手册发上来,我们一起看看

  • HI , 谢谢 Thomas Yang1

    现在可以枚举设备了, 只是要注意, 在PCIE application中配置 CFG_SETUP时候, 要注意设置 type

    根据文档中有

    Configuration type for outbound configuration accesses.
    0 = Type 0 access.
    1 = Type 1 access.

    文档中介绍 type 0 为 EP端(有6个bar空间), type 1为rc或者桥(只有2个bar空间)

    但是代码中实验的情况与此相反, bus-0 dev-0 func-0 type-0 可以在x02180_2000地址读到桥设备的配置空间

    如果要读取pcie-bridge下面的EP设备, 需要将type设置为1, 如 bus-1 dev-4 fun-0 type-1 则可以在0x2180_2000读到桥下面EP设备的配置空间

    另外还有个奇怪的现象, 如果设置 bus-1 dev-0 fun-0 type-1 准备扫描bus1下面的pci设备, 在读0x2180_2000地址的时候,程序会跑飞, 然后我只有放弃循环扫描, 而用初始化固定地址的EP设备来代替

    以上问题在去年一个帖子中, 有人曾经提问过, 也遇到类似问题, 帖子地址:

    http://www.deyisupport.com/question_answer/dsp_arm/c6000_multicore/f/53/p/94550/336383.aspx#336383

  • 谢谢反馈,

    1

    “文档中介绍 type 0 为 EP端(有6个bar空间), type 1为rc或者桥(只有2个bar空间)

    但是代码中实验的情况与此相反, bus-0 dev-0 func-0 type-0 可以在x02180_2000地址读到桥设备的配置空间

    如果要读取pcie-bridge下面的EP设备, 需要将type设置为1,”

    那之前您的实验中,在配置桥的寄存器的时候,已经将type 定义为0了?

    这个我会向designer求证这个问题

    “如 bus-1 dev-4 fun-0 type-1 则可以在0x2180_2000读到桥下面EP设备的配置空间”

    您系统的拓扑关系是怎么样的?为什么会有dev-4存在。

    3

    按照PCIE协议,以1个RC链接1个switch,switch 1个口 链接1个EP为例:RC BUS 是0,SWITCH upstream BUS是1, switch internal BUS是2,Switch downstream port0 BUS上挂的EP是3,

    TI PCIE IP设计时,作为RC,是将上面序号都减去1进行枚举编址的(除了RC BUS),

    SWITCH upstream BUS是0, switch internal BUS是1,Switch downstream port0 BUS上挂的EP是2

    那么你之前提到的 dev-1 应该是switch internal BUS,而dev-2是downstream port 0 bus上挂的EP

     

  • “如 bus-1 dev-4 fun-0 type-1 则可以在0x2180_2000读到桥下面EP设备的配置空间”

    您系统的拓扑关系是怎么样的?为什么会有dev-4存在。

    我的拓扑关系如下 6657 PCIE 接 pcie-bridge ,  pcie-bridge 下面的 dev 4接了 pci设备

    所以我这里定义 接pcie-bridge的bus为 bus 0,  pcie-bridge 下面的bus为 1  所以枚举 pci设备的时候使用了 bus-1 dev-4 fun-0的地址

x 出现错误。请重试或与管理员联系。