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.

RBL PCIe boot default bar mapping

I am planning to use C6678 rev 2.0 chips in PCIe boot mode. Since the PLL errata (Advisory 8) is not applicable to these revision chips, I don't want to use the I2C boot workaround.

I went through the documents: PCIe Use Cases for KeyStone Devices and DSP Bootloader UserGuide for the same. Are there any other documents which I can refer to?

The Bootloader user guide explains that the bootloader configures the PCIe registers by getting default values from boot param table. Where is the boot param table present or is it to be laoded by the host? 

Also, in PCIe primary boot mode, the RBL maps the BARS to what address offsets?

I couldn't understand the procedure explained in Bootloader Userguide for host transferring the application and writing to BOOT MAGIC ADDRESS. What is the BOOT MAGIC ADDRESS?

Thanks in advance.

  • Hi,


    I am planning to use C6678 rev 2.0 chips in PCIe boot mode. Since the PLL errata (Advisory 8) is not applicable to these revision chips, I don't want to use the I2C boot workaround.

    I went through the documents: PCIe Use Cases for KeyStone Devices and DSP Bootloader UserGuide for the same. Are there any other documents which I can refer to?

    The PLL errata is fixed on C6678 rev 2.0 chips, but the PCIe workarounds are not fixed. So IBL is required for C6678 rev 2.0 chips PCIe boot mode.


    The Bootloader user guide explains that the bootloader configures the PCIe registers by getting default values from boot param table. Where is the boot param table present or is it to be laoded by the host?

    Refer section "2.5.3 Boot Parameter Table" on C6678 data manual. You can also find this information from the tiboot_c66x.h file provided in the MCSDK under the path $(MCSDK_INSTALL_DIR)\\tools\boot_loader\ibl\src\device\c66xx


    Also, in PCIe primary boot mode, the RBL maps the BARS to what address offsets?

    I couldn't understand the procedure explained in Bootloader Userguide for host transferring the application and writing to BOOT MAGIC ADDRESS. What is the BOOT MAGIC ADDRESS?

    Refer section "2.5.2.4 PCI Boot Device Configuration" and "2.4 Boot Sequence" on C6678 data manual.

    Thanks,

  • Thanks for the reply.

    We plan to use IBL but we don't want to use an I2C EEPROM. Is this fine?

    I am yet to go through tiboot_c66x.h. Thanks for providing the information. Section "2.5.3 Boot Parameter Table" of C6678 data manual, 2.5.3.4 for PCIe boot parameter table, gives information of the different fields of boot param table but what are the default values? The header file which you have mentioned is a part of IBL code. Is this not required by RBL?

    Also, with PCIe boot mode as the primary bootmode, what are the configurations done by RBL and what configurations are done by IBL?

    Section "2.5.2.4 PCI Boot Device Configuration" does not mentions about the default BARS to address mapping. Only BAR0 is specified to be mapped to PCIe MMRs. I plan to load IBL from host via PCIe. For this, one of the BAR should be mapped to IRAM by RBL and hence I need to know the default mapping of BARS, done by RBL. I am aware of window sizes which can be configured by boot configuration pins. I believe that the host can re-map the BARS after configuration but if by default any BAR is mapped to IRAM, I can skip this step.

    Regards,
    Mohnish
  • Hi,


    We plan to use IBL but we don't want to use an I2C EEPROM. Is this fine?

    Yes. It is fine.


    Also, with PCIe boot mode as the primary bootmode, what are the configurations done by RBL and what configurations are done by IBL?

    DSP PCIe clock(FCLK) issue is not fixed on the Rev 2.0 chips. For more information refer section “2.4 Clock Domains” on TMDSEVM6678L EVM Technical Reference Manual. This workaround is enough for PCIe boot, you can implement on your secondary boot loader.

    It is fixed on Rev 3.0 chips.

    Thanks,
  • Hi Ganpathi,

    Thanks for the answer. I went through section 2.4 Clock Domains of TMDSEVM6678L EVM TRM. The section says it is fixed on Rev 3.0 EVM and not chip. I was referring to C6678 Silicon chip revisions in all the previous discussions. Is this issue related to the Silicon chip or the EVM? If it is a C6678 issue, is it mentioned in the Errata ?

    We are planning to make a custom board with C6678 in PCIe boot mode without I2C EEPROM and want to test the PCIe boot on EVM without taking any binary from the I2C EEPROM. Is this possible? The README document (MCSDK\tools\boot_loader\examples\pcie\docs) mentions the FPGA forces the DSP in I2C boot mode and then IBL is taken from I2C EEPROM.

    Thanks in advance.
  • Hi,


    Thanks for the answer. I went through section 2.4 Clock Domains of TMDSEVM6678L EVM TRM. The section says it is fixed on Rev 3.0 EVM and not chip. I was referring to C6678 Silicon chip revisions in all the previous discussions. Is this issue related to the Silicon chip or the EVM? If it is a C6678 issue, is it mentioned in the Errata ?


    It is a EVM issue with FPGA bit file. Not issue on C6678 silicon chip.


    We are planning to make a custom board with C6678 in PCIe boot mode without I2C EEPROM and want to test the PCIe boot on EVM without taking any binary from the I2C EEPROM. Is this possible?

    Yes, it is possible with C6678 rev 2.0 chips.

    Thanks,
  • Thanks for the quick response. We have Silicon chip rev 2.0 C6678 EVM. So in order to test PCIe boot on this EVM, do we have to update the FPGA logic to not force the C6678 bootmode pins to I2C boot mode?
  • Please take a look at TMDXEVM6678L EVM Known issues document.
    wfcache.advantech.com/.../TMDXEVM6678L_EVM_A101-1_Known_Issues_v0%203.pdf

    For more information refer EVM manufacture product page:
    www2.advantech.com/.../6678le_download3.aspx

    Thanks,