Dear support,
I hope you can help me with this very strange issue that we are experiencing. I am not sure if I should classify my problemas a Boot Issue or Pcie Issue.
The RBL enables the C6670 to boot from PCIe. However, the default window size are too big for our host to allocate memory and access all the bars.
Because of this problem, we created our own IBL based on the code provided by TI in the function iblPCIeWorkaround from mcsdk_2_01_00_03\tools\boot_loader\ibl\src\device\c66x\.
For the last 2 month, we have been using successfully a bootstrap that starts the RBL in from SPI in CS1, retreives our IBL from flash memory, runs the IBL and we can see our board on the pcie bus with 5 bars from a linux host. (if you need I can provide the detail lspci command)
When looking at this command we can identify 5 BARS that are configured as our IBL set them up.
BAR0: 32k
BAR1,2,3: 1M
BAR4: 4M
We are updating our boot process to boot from EEPROM. We changed the boot strap. Since it is the same code, we just regenerated the binary file (updating the parameter passed to romparse.exe) and we store it in EEPROM. We did not change one line of the source code of our working IBL
For the last week we have beleived that the board was booting properly as we did not really need to do any memory/register access via the host. Moreover, the linux host sees the board (lspci) and updates the BAR registers (0x21800000+0x1010) on the EP.
However, we started to have strange issues reading and writing memory regions on the DSP from the host.
We we looked a bit further, lspci -x -v here was our surprise:
BAR1,2,3: 1M
BAR4: 4M
BAR0 has disapeared. According to you manual, BAR0 is the only bar that can be used to access the pcie registers. We spent a lot of time investigating and we narrow it down to:
Once the RBL boots from flash => all is good
Once the RBL boots from EEPROM (same problem for eeprom @0x50 or eeprom @0x51) => Not good
I can provide you the source code of the IBL under NDA if you need but perhpas you have an idea of what is going on or perhpas you have heard of such a problem.
Is there additional settings required in the IBL when booting from i2c that I do not require when I boot from SPI
Thanks in advance
Aymeric