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.

DM816x SPI boot clk speed

We are using a DM8165 as a pci endpoint booting u-boot from spi flash (spi boot mode).

In order to meet PCI specification, I believe u-boot needs to have the pcie configured within 100ms of reset.  Our u-boot image is approx. 50k in size.  From the 816x trf, spi boot mode should be using a 12MHz clock which should load the image in ~50ms, but it is actually taking ~100ms.

I have looked at the SPI clk rate used by the boot rom, and it looks like it is ~6.6MHz instead of 12MHz as called out in the TRF.

What should the SPI clock rate be for the boot rom?  Is there a way to have a higher clock rate?

  • O.K., I see an errata for this

    http://www.ti.com/lit/er/sprz329d/sprz329d.pdf  advisory 1.1.22 although it doesn't give any details except that there is no workaround.

    So is there a way to have a the DM816x boot from spi and be a pci endpoint?  I'm not sure how small u-boot can be but I imagine probably not much below 50k.  Would this require another boot stage with with a minimal application that would transfer u-boot to on chip memory?  Any examples of something like this?

  • I'm not very clear on the limitation of the PCIe timings. Since there is no way to improve the SPI clock, you can try to create a minimal image of u-boot by stripping off most of the commands from it. You can have a very tiny image of around 80-90KB in size or even lesser. 

  • Hello Renjith,

    That's basically what I ended up doing some time ago.  I ended up creating a very minimal u-boot that is around 40k in size and minimal delays and was able to get it to set up PCIe in around 90ms.


    It just surprises me that I haven't seen others having a similar problem, but maybe the PCIe endpoint is not such a common usecase for the DM816x.

  • Glad to know that your problem is resolved.

    You are right. This is not a very common use case for most customers.