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.

Ethernet bootloading to a core other than core0

I've been trying to work with the EMAC bootloader on the C6472 multicore DSP.

What I have is a very simple code that writes to the DDR. It writes a constant, and then the number of the core running.

I have managed to make this program run on core 0 (I just load the program, and then check the DDR and see what's written there), but I don't really understand how to make a program run on another core.

The bootloader documentation has a multicore section regarding the C6474, and I assume the C6472 works the same way. What it says is the other cores start running from the beginning of their L2 SRAMs. But how do I get the code there? Do I need to make core0 write there?

  • Arya,

    Would you please share your experience with how you did the EMAC bootload to Core 0 to get your first program working, by posting a reply to the C6474 EMAC bootloader thread in this same forum? Please include as much detail there as you care to write. This would make a good Wiki topic.

    I did not see it at first, either, but the Bootloader User's Guide does have a section on the C6472. The text in section 4.1 is interesting reading, but not necessarily as directly to the point for someone like you who has already accomplished basic EMAC bootloading.

    To load programs onto the other cores, use the Global SRAM addresses to write to. For example, for Core1, write to DSP1 L2 SRAM at 0x11800000. This will correspond to Core1's Local L2 SRAM address of 0x00800000.

    The C6472 is a little different from the C6474 in that it has independent boot registers for each DSP core. These are detailed in the datasheet rev A in section 3.9. Look for the DSP_BOOT_ADDRn registers, in which you place the corresponding core's entry point - remember to shift the address right 10 bits so the 22 MSbits of the entry point address go into the 22 LSbits of the DSP_BOOT_ADDRn register. Then look 2 pages earlier for the BOOT_COMPLETE_STAT and its BCn bits. Set BC1 = 1 to release Core1 to start running from the entry point loaded into DSP_BOOT_ADDR1.

    You can choose to write directly to these registers through the data payloads in your EMAC bootloading process, or include writes to these registers from Core0 once it starts running. In either case, once the BCn bit is set to 1, the corresponding CoreN will start running from its DSP_BOOT_ADDRn entry point. And also in either case, after writing to the DSP_BOOT_ADDRn registers, you can write to all of the BCn bits in a single write to BOOT_COMPLETE_STAT, which will cause all the other cores to start running at the same time.

    Please let me know if this helps, and if I can help with the Wiki topic.

  • Hello Randy,

     

    Thank you for your reply.

    First of all, I posted an answer to the requested thread. I hope this is specific enough, I can expand if there are more questions.

     

    As for starting core1 - This is what I tried to do, and for some reason it doesn't seem to work.

    What I do exactly is this - In addresses 0x11800000 and the couple of following addresses, I put a branch command that'll jump to my main program (Which is on the DDR). I then update the DSP_BOOT_ADDR1 register to 0x2000 (Which is 0x800000 shifted right by 10) and set BC1 to 1.

    I see that core1 starts running, as I see that its PC changes, but it doesn't do what I tell it to.

    I'd put a basic program on the SRAM, but my problem is I'm not so sure how to do that. When I load a program, its start address is never the beginning of the memory (Which seems to be the BSS), and the program itself seems to start several hundreds of bytes afterwards. So the only option I see is to write something really small that'll just jump to my main program.

    Am I understanding this wrong? Is there an easier way to do this?

     

    Thanks in advance.

  • One option would be to load the test program into Core1's SRAM instead of DDR, to avoid the branch to the actual program. But there is no reason that what you are trying to do would not work.

    Could you send the exact instructions you are loading into Core1's SRAM? Using common code from multiple cores is not trivial, but it is also not too difficult. The Multicore Programming Guide has some very useful information for working with multiple cores.

    One way to force an entry point at 0x00800000 for your program is to create a fixed memory region that is used only for this purpose:

    1. Change the memory allocations in your tcf or cmd file to insert an 8-word memory area at 0x00800000. For example,
      in MEMORY change
          IRAM              : origin = 0x800000,    len = 0x200000
      to
          ENTRYPT    : origin = 0x11800000,    len = 0x000020
          IRAM             : origin = 0x11800020,    len = 0x1FFFE0
      and add to SECTIONS
              EntryPoint: {} > ENTRYPT
      If you are using DSP/BIOS, you will need to add a second linker command file and add that file to your project, put the SECTIONS line in there, like this
          SECTIONS
          {
              EntryPoint: {} > ENTRYPT
          }
    2. Put your entry point code in a small assembly file, entry.asm. Assuming the normal C entry point of _c_int00, it would read
          .global    _c_int00
          .global ResetEntryPt
          .sect    "EntryPoint"
      ResetEntryPt:
          MVKL    _c_int00, B0
          MVKH    _c_int00, B0
          BNOP    B0, 5        ; branch to program entry point
          .word    0,0,0,0,0    ; filler space
    3. Add entry.asm to your project. It will get linked to reside at 0x11800000 which is also 0x00800000 for Core1.
    4. If you prefer more consistency, you could set the value in DSP_BOOT_ADDR1 to 0x11800000 >> 10.

    To debug what you have already, remove the write to BC1, and instead just let the bootloader complete. Then use CCS to put the PC at 0x00800000 and single step to see what is going wrong.

    You seem to have everything setup pretty well, so there is probably just one small item that needs to be changed.

  • Thank you, it works now. :-)

  • Excellent work!

    Since you are now one of the experts, if you are willing, please post a zip of your project for the benefit of the next engineer after you. Include the PC-side source, too, if you would. Personally, I would like to run it.

    Thank you for your help on the other thread, too, BTW.

  • Arya,

    I would also be interested in taking a look at the source for your Ethernet bootloader, if that's something you're willing to share.

    Regards,
    David