• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 975 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.

C6670 / C6678 SRIO boot constraints and SPRUGY5 questions

Michael P
Expert 1810 points

SPRUGY5 describes DirectIO and messaging modes for SRIO booting.  For messaging mode, SPRUGY5C says the RBL uses a 32 KB block of L2 RAM for message reception, but the C6670 and C6678 data sheets (at least SPRS689D and SPRS691E) describe a ~53 KB block as being reserved.  Which document is correct?  Does the C6670 use the same layout for that block as the C6678?

SPRUGY5 says that "RBL reserves a portion of the L2 in all the cores in the device to perform the boot process", but only the BOOT_MAGIC_ADDRESS word appears to have a function on secondary CorePacs.  Can the loaded image arbitrarily overwrite the other parts of the "reserved" block on those cores, or is the entire block reserved across all cores?

How, if at all, does SRIO boot mode use the "Boot progress register stack", "Boot table arguments" and "RAM table" regions that are listed in Table 2-3 of SPRS691E?

When, if at all, do changes to the "Boot parameter table" region take effect?  (One other forum post noted that the "Mailbox enable" bit needs to be set even for DirectIO mode, so if I use DirectIO mode, I want to understand the required sequence.)

Section 2.2.1 of SPRUGY5 very briefly discusses how to use the "DDR configuration table" in the L2 SRAM block.  Does its phrase "the DDR enable magic word" mean the word at byte offset 0 in SPRS691E's Table 2-23 (which is named "configselect")?  If they are the same thing, how are the bits in "configselect" mapped to the following words in the table?  If they are different, where is the "DDR enable magic word"?

SPRUGY5 is not very clear on how secondary cores exit their boot sequence.  Section 2.2.1 says they execute IDLE and wait for an interrupt from CorePac0, but does not specifically say when or how CorePac0 will decide to generate such an interrupt.  Does it poll the other cores' boot magic addresses at roughly the same time as its own?

I realize a lot of this is probably covered by the RBL source code, but source code by itself seldom shows where an interface contract ends and implementation details begin, and I would rather limit my assumptions to things that TI (at least currently) expects to stay true for the production life of the parts in question.

  • 0
    TI__Guru* 81335 points

    Hi Michael,

    Q: said:
    Q: SPRUGY5 describes DirectIO and messaging modes for SRIO booting. For messaging mode, SPRUGY5C says the RBL uses a 32 KB block of L2 RAM for message reception, but the C6670 and C6678 data sheets (at least SPRS689D and SPRS691E) describe a ~53 KB block as being reserved. Which document is correct? Does the C6670 use the same layout for that block as the C6678?


    Please refer data manual. In Table 2-3, The 0x7f80 bytes reserved for Ethernet/SRIO packet/message/descriptor memory. Yes.

    Q: said:
     

    Q: SPRUGY5 is not very clear on how secondary cores exit their boot sequence. Section 2.2.1 says they execute IDLE and wait for an interrupt from CorePac0, but does not specifically say when or how CorePac0 will decide to generate such an interrupt. Does it poll the other cores' boot magic addresses at roughly the same time as its own?


    The user can decide when to generate the IPC interrupt. The simple example of wakeup and run other cores is available in MCSDK.
    PATH: ..\ti\mcsdk_2_0x_0x_0x\tools\boot_loader\examples\srio\srioboot_helloworld

  • 0 in reply to Raja
    Expert 1810 points
    Okay, from looking at the SRIO helloworld code, I conclude that the RBL will not interrupt the other cores, and that user code is responsible for doing so. That seems like information that should be in a user's manual rather than buried in an example app.

    Does the fact that the SRIO helloworld example loads a DDR initialization image mean that SPRUGY5 is wrong about the RBL being able to initialize the DDR EMIF, at least for SRIO booting? Was it just an implementation choice for the example? Or is there some limitation in the RBL that means using its built-in DDR EMIF initialization support is a bad idea? (I don't see any mention of such a limitation in the silicon errata documents, the data manuals or the RBL user manual.)
  • 0 in reply to Michael P
    Expert 1810 points
    After a bit more digging through old forum posts: Is the DDR initialization image in the example to work around Advisory 8 from the C6678 silicon errata ("Multiple PLLs May Not Lock After Power-on Reset Issue")? If I expect to only run on revision 2.0 (or later) chips, is it safe to have the RBL initialize the DDR EMIF?