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.

TMS320DM8147: PCIe boot loader

Part Number: TMS320DM8147

Is there a very fast bootloader available (in source code) that brings up a DM8147 as a PCIe slave and configures PCI Hardware IDs? The DM8147 is on a PCIe card designed to be plugged in to a host x86 PC. The TI published uboot based bootloader works, but is too slow to load and run relative to the BIOS PCIe enumeration of a modern PC.

  • I'm not aware of any other bootloaders that would be available for this device with PCIe capability.  That said, how fast are you able to startup your existing u-boot implementation, and how fast does it need to be?

  • We currently measure 90 milliseconds. We required less than 20 milliseconds.

  • Does that time require you to load SPL and u-boot? Or can you achieve your goal in SPL?

  • Hi Brad,

    We only load SPL right now and that's enough to bring up the minimum set of peripherals we need. We actually have a lot less than 20 ms. The boot ROM starts checking if the SPI flash is a viable boot device 12 ms after reset is de-asserted. The boot ROM then reads one sector (using the default 12MHz clock) then there is short pause and it resumes reading the rest of the bootloader image. The way I see it, if we want to have some margin, we have 4ms for image download and minimal CPU and PCIe setup (DRAM and DSP setup can wait). Allocating half of the time budget to bootloader read allows for a 2kbytes bootloader so u-boot isn't an option. I searched far an wide for the DM814x ROM API jump table which is mentioned in "Section 4.3.1 ROM Memory Map" of the TRM but is not present the TRM or in any other 814x document I could find. It would be great to be able to call ROM code because it would probably greatly reduce the size of the bootloader.

    Thank you!

    --

    Delio

  • Delio Brignoli said:
    The boot ROM starts checking if the SPI flash is a viable boot device 12 ms after reset is de-asserted.

    How are your boot pins configured?  Is SPI configured as the first boot device?  I don't have any specific data points for how long the boot ROM takes, so I want to make sure there's not any extra devices being checked first.

    Delio Brignoli said:
    Allocating half of the time budget to bootloader read allows for a 2kbytes bootloader so u-boot isn't an option.

    I can't imagine any bootloader can get all this done in only 2KB.

  • Brad Griffis said:
    Is SPI configured as the first boot device?

    Yes, it is.

    Brad Griffis said:
    I can't imagine any bootloader can get all this done in only 2KB

    Not a general purpose one, but I think a very simple custom one could. To your knowledge, is the boot ROM API table documented anywhere?

    Thank you very much for your help!

    --

    Delio

  • Delio Brignoli said:
    To your knowledge, is the boot ROM API table documented anywhere?

    Sorry, no.

    Delio Brignoli said:
    Not a general purpose one, but I think a very simple custom one could.

    Unfortunately you are in uncharted territory.  Your requirements are very aggressive and I don't have anything readily available to point you to.  Perhaps you could write an extremely minimal bootloader that does nothing except for some very basic PCIe configuration and then loads SPL to kick off the rest.  In other words, your bootloader would NOT do DDR configuration nor would it do pinmux configuration.  It would do the absolute bare minimum which is to configure the PCIe and load SPL which would then do pin muxing, DDR, etc.

  • Hi Brad,

    Brad Griffis said:
    Unfortunately you are in uncharted territory.  Your requirements are very aggressive and I don't have anything readily available to point you to.  Perhaps you could write an extremely minimal bootloader that does nothing except for some very basic PCIe configuration and then loads SPL to kick off the rest.  In other words, your bootloader would NOT do DDR configuration nor would it do pinmux configuration.  It would do the absolute bare minimum which is to configure the PCIe and load SPL which would then do pin muxing, DDR, etc.

    Thank you for your advice. If we were to try the approach I described above we would probably try init'ing DRAM after PCIe and stop there. The host can then take over and load the DSP firmware via PCIe which in turn can setup anything else it might need.

    --

    Delio