• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 1111 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.

C6678 PCIe-Boot with wrong BAR-configuration?

Bernd Erbe
Expert 2065 points

Hello,

I've tested the PCIe-Boot with a TMDXEVM6678LE and a AMC to PCIe-Adaptor-Card. Everything is fine, but the registered BARs are not as expected. I've patched the IBL with the workaround (for PLL locking...) and the BARs were configured in this way:

BAR0: 1M, 32 bit, non-prefetch
BAR1: 512K, 32 bit, prefetch
BAR2: 4M, 32 bit, prefetch
BAR3: 16M, 32 bit, prefetch
BAR4: 64K, 32 bit, prefetch
BAR5: 4K, 32 bit, prefetch

As I just want to use 4 BARs and the BAR0 only with a size of 4K or 8K, I just modified the IBL as shown below. Problem is that the BAR0 always has the size 1M regardless what I write into the BAR0-Mask register. Furthermore I've an unassigned memory for BAR4, see also below.

Furthermore I've checked the board by only powering the EVM and connecting to it with CCS. Reading the BARs from 0x21801010 (by writing 0xFFFFFFFF to them) the result was not the one expected to the code in the IBL. I've not found any other part in the IBL which is writing to the BAR registers.

Have anybody an idea what's going wrong here?

Best Regards,
Bernd

// Changed IBL

if (flag_6678)  {
        /* 6678 */
        DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_BAR0), 0x00000FFF);   /* 4K */
        DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_BAR1), 0x0007FFFF);   /* 512K */
        DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_BAR2), 0x003FFFFF);   /* 4M */
        DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_BAR3), 0x00FFFFFF);   /* 16M */
        DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_BAR4), 0x00000000);    /* Empty Bar */
        DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_BAR5), 0x00000000);    /* Empty Bar */
    }

   ...

    DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_APP_CMD_STATUS), 0x0);    /* dbi_cs2=0 */

    DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_STATUS_CMD), 0x00100146); /* ENABLE mem access */
    DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_DEV_STAT_CTRL), 0x0000281F); /* Error control */
    DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_ACCR), 0x000001E0); /* Error control */
    DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_BAR0), 0); /* non-prefetch, 32-bit, mem bar */

// Output of lspci -v

01:00.0 Multimedia controller: Texas Instruments Device b005 (rev 01)
        Subsystem: Siemens Medical Systems, Ultrasound Group Device 0615
        Flags: bus master, fast devsel, latency 0, IRQ 11
        Memory at fba00000 (32-bit, non-prefetchable) [size=1M]
        Memory at f9400000 (32-bit, prefetchable) [size=512K]
        Memory at f9000000 (32-bit, prefetchable) [size=4M]
        Memory at f8000000 (32-bit, prefetchable) [size=16M]
        Memory at <unassigned> (32-bit, prefetchable)
        Capabilities: [40] Power Management version 3
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
        Capabilities: [70] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting <?>

// Results of the BAR registers

BAR0: 0xFFF0 000F
BAR1: 0xFFF8 000F
BAR2: 0xFFC0 000F
BAR3: 0xFF00 000F
BAR4: 0x0000 0008
BAR5: 0x0000 0000

  • 0
    TI__Genius 12065 points

    The BAR0 register is fixed to be mapped to PCIe application registers region. So the BAR0 mask setup does not affect BAR0 register.

    If you want to use 4 configurable BAR registers, please configure BAR1~BAR4 accordingly.

    In your setup, BAR4 is disabled in the BAR4_MASK setup (bit0=0). So it is normal to see unassigned memory for BAR4.

    In disabled status (for BAR4 and BAR5), the default values of BAR4 (0x0000_0008) and BAR5 (0x0000_0000) are a little bit different, but they do not affect any functionality since both of BAR4&5 are disabled.

    If you enable the BAR4 and BAR5 in BARn_MASK register (bit0=1), you will see that the default values of BAR4 and BAR5 are the same (0x0000_0008), showing the BAR region is prefetchable.

    Hope it helps.

  • 0 in reply to Steven Ji
    Expert 2065 points

    Hello Steven,

    thanks, this answers all my questions.

    Best Regards,
    Bernd

  • 0 in reply to Bernd Erbe
    Expert 2065 points

    Hello Steven,

    just another question: in every document I read that BAR0 is always mapped to the address space 0 (Application registers) so that the DSP as EP can be configured. Additionally the inbound translation for IB_BARn [n=0-3] always should be mapped to BAR0-5. So the inbound translation for BAR0 should always be fix and it should be possible to read the application registers with the default setting done in the IBL.

    But that's not possible. Reading from BAR0 with any offset (e.g. VendorID on 0x21801000) always return not the expected value. BAR0 is configured for 1M starting on 0x21800000 so also the configuration registers should be possible.

    Where's my error? Is the inbound translation not fix for BAR0?

    Moreover, I wonder about the code in the IBL which always uses and configures BAR0. This shouldn't be necessary as this mapping is always declared as fixed mapping. Also the inbound translation is done for BAR0 in the IBL which is always said "Region 0-3 only to BAR1-5" in the documentation.

    Best Regards,
    Bernd

  • 0 in reply to Bernd Erbe
    Expert 2065 points

    Hello,

    after some more tests, it is possible to read the Application registers via BAR0 (but only the Application registers, not the configuration registers). But with this everything is fine.

    Only the IBL is not consequent by using BAR0 for Region 0 with the Inbound translation. Moreover it is not clear with this fact: if 4 Regions are configured with the Inbound Translation (not BAR0 with the Application registers), are the Application Registers accessible via BAR0 as before?

    Best Regards,
    Bernd

  • 0 in reply to Bernd Erbe
    TI__Genius 12065 points

    Bernd,

    There is no need to setup the Inbound translation registers (IB_BARn, IB_OFFSETn, etc) for BAR0. The PCIe module will internally direct the packets accepted by BAR0 to the Application registers region, that is why we called it fixed. As long as the BAR0 value in the local device is matching the PCIe address of the packets from remote device, those packets can be directed to the Application registers region (I think you have already verified that).

    For the BAR1-5 registers, by default (without Inbound translation setup), the packets accepted by the BAR1~5 will be sent to the locations with the same address value as the PCIe address of the packets, which may not be what we prefer. So we may also want to associate the Inbound translation registers (IB_xx 0~3) to BAR1~5. In this way, we could direct the packets to any internal memory region in the local device, indicated by the IB_OFFSET and other registers. We should have the example in the PCIe user guide and use case application note.

  • 0 in reply to Steven Ji
    Expert 2065 points

    Hello Steven,

    thanks, now everything is clear. What you wrote was what I've expected from the documentation, but is not what the IBL do, e.g. within the PCIe Boot example as BAR0 is associated with Region 0.

    Best Regards,
    Bernd