• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1192 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Boot Parameter Table entry in case of Boot through PCIe

chandan singh
Prodigy 130 points
Other Parts Discussed in Thread: TCI6638K2K

Hi All,

I have a query regarding Boot Parameter Table in case of booting DSP image through PCIe.

As per the Table 8-20 "PCIe Boot Parameter Table" in section "8.1.2.4.4" of TCI6638K2K datasheet(SPRS836D),there are parameters which are not Configured through Boot Pins,like Options at offset 22,SerDes cfg msw at offset 46 and SerDes cfg lsw at offset 48.So how the value of these parameters can be modified.

Is the Default Boot Parameter Table loaded by RBL sufficient to Boot application image through PCIe on TCI6638K2K?

Thanks in advance,


Chandan  

  • 0
    TI__Mastermind 28085 points
    Hi,

    Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages (for processor issues). Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics (e2e.ti.com).

    Yes, it is OK for pcie boot.

    Thanks,
  • 0 in reply to Ganapathi Dhandapani95
    Prodigy 130 points

    Hi Ganapathi,

    Thanks for the reply.

    I have still doubt that if the values of the fields like Link Rate and SerDes cfg msw in Boot Parameter Table needs to be modified,which are shown as not changeable through Boot Configuration Pins,how can it be modified?

    Also as per the 3.2.2 "Boot Table" of sprugy5(DSP bootloader guide),the boot table format should be
    like below  
          (1) 32-bit header record indicating where the bootloader should branch after it has   completed copying the data.
          (2)     For each initialized section:
            – 32-bit section byte count
            – 32-bit section address (destination address for the copy)
            – The data to be copied                          
          (3) A 32-bit termination record (0x00000000)

    I understand that it is Boot Table format for single application image.

    But if we want to load different images on different cores of DSP in case of TCI6638K2K,
    then what should be the format of Boot Table and how RBL will know that which portion of
    Boot Table should be loaded to which core.


    Thanks in advance,

    Regards,
    Chandan  

                
        

  • 0 in reply to chandan singh
    Prodigy 130 points

    Hi Ganapathi,

    Waiting for your reply.

    Thanks in advance.

    Regards,
    Chandan 

  • 0 in reply to chandan singh
    TI__Mastermind 28085 points
    Hi,

    I will check with my team and get back to you.

    Thanks,
  • 0 in reply to chandan singh
    TI__Genius 12320 points
    Hi Chandan,
    The fields marked as 'not changeable' in the Boot Parameter Table are indeed not configurable through the boot pins. The boot ROM is able to set it up to complete the boot process.

    For your second question, which boot mode are you planning to use?
    Typically Linux is boot on the ARM which has tools to load DSP images to DSP cores and start executing them. Is this an option for you?

    Regards,
    Mike
  • 0 in reply to chandan singh
    TI__Genius 12320 points
    I just noticed you are intending to use PCIe boot. PCIe boot is considered a host boot where your PCIe host is responsible for loading in all sections of code into the 6638, filling in each cores Magic Address, and issuing a PCIe legacy or MSI interrupt. Your core0 will be responsible for waking up the rest of the cores and cause them to execute the code pointed to by their Magic Address.

    All of this information is available in the DSP bootloader user guide and the 6638 user guide.

    On 6638 the option to do all of this via Linux is available and typically is what is used.
  • 0 in reply to Michael Scherban
    Prodigy 130 points

    Hi Michael,

    Thanks for the information.

    Your reply : The fields marked as 'not changeable' in the Boot Parameter Table are indeed not configurable through the boot pins. The boot ROM is able to set it up to complete the boot process.

    My Query --> So if any such fields needs to me modified, then Boot ROM (Rom Boot Loader) needs to be modified, Am i correct?But since RBL source code for TCI6638k2k has not been released yet to customers, so how to modify these parameters values? We are not using IBL here. Only RBL and then boot via PCIe.

    Your reply :  PCIe host is responsible for loading in all sections of code into the 6638, filling in each cores Magic Address, and issuing a PCIe legacy or MSI interrupt.

    My Query -> So filling of values(entry point values) in each core magic address is responsibility of Host? or Host will only populate Magic Address for Core0, load all sections to all Cores then,Core0 is responsible for populating values in magic address of all cores?

    Thanks & Best Regards,

    Chandan

  • 0 in reply to chandan singh
    TI__Genius 12320 points
    Hi Chandan,
    The boot ROM is read only and is unable to be modified.

    There is a way to add in an additional stage to boot, where this stage will modify this table and branch back into the boot ROM using the new table. But this isn't usually done for PCIe boot. Typically it is done so that the first stage sets up DDR, or to increase the SPI clock. It's usually done by boot modes that have no user intervention. I can provide examples where this is done if you'd like.

    The host should be able to fill in the magic address using the global L2 registers. The magic address is 0x8f_fffc for each core, but this can be accessed external of each core by prepending it like: 0x1n8f_fffc. So core0 is 0x108f_fffc and core3 is 0x138f_fffc. But the other DSPs will be in IDLE waiting for an interrupt, and I am not too sure if the PCIe interrupt will make them branch to their magic address. It might be left up to core0 to wake them.

    Regards,
    Mike