C6657 PCIe rom boot code not jump to _c_int00

Hi Yuan,

Do you have a C6657? In case of PCie you need to provide the boot magic address and also you might need to provide the MSI interrupt from RC to wake the core to boot in EP.

Thanks,

Arun.

Hi, Arun, thanks for the info.

Yes, I am working on a C6657 custom board, not EVM, without IBL.

I tried to send both MSI interrupt 0 and 8 to core 0, but it still does not work.

I trace the code of mcsdk_2_01_01_04/tools/boot_loader/pcie/linux_host_loader/pciedemo.c, it seems that in function setBootAddrIpcgr, we unlock the boot confing, write to DSP_BOOT_ADDR0@0x2620040, then send a IPCGR0 to the core 0. This function is called as part of dspLocalReset.

In function init_module of the same pciedemo.c file, it is just push data, get code entry, then write code entry to BOOT_MAGIC. This seems to match PCIe bootloading processing in the manual. Do I understand correctly?

It is interesting to note that the code  downloaded is correct: I checked both the first everal bytes of _c_int00 and main, they all match with the data I downloaded directly from jtag. The BOOT_MAGIC still contains the dsp entry we wrote through PCIe. The PC is at 0x20b010b0, in boot rom. The DEVSTATE# 0x02620020 is 0x00011808.

I also did an expereiment, trying to understand the boot process:

1. remove Global_Default_Setup_Silent from function of OnTargetConnect of the gel file so that I do not touch dsp when I connect

2. bring dsp out of reset and connect to core 0

3. now pc is pointing to 0x20B010B0, part of  bootrom.

4. DEVSTATE# 0x02620020 is 0x00011808, with PCIESSEN=1, PCIESSMODE=00 (EP), PCIe boot

5. I just write address 0x800000 into BOOTMAGIC (0x008FFFFC), set break point at this 0x800000, which contains just garbage, and let the dsp run.

6. The dsp does not hit the break point

I think, I should be able to hit the break point if I understand it correctly. Is there anything I miss?

thanks

Weichun

Weichun,

There is differences when you use IBL or RBL for PCIE boot.

For IBL, you need below 2 steps:
1)    load code via PCIE to DSP from host
2)    write BOOT_MAGIC address with the boot entry address via PCIE from host

The IBL code monitor the BOOT_MAGIC, when it is non-zero. It jumps to start your code.

For RBL, you need an extra step:  
3)    send a MSI interrupt to DSP via PCIE from host

This procedure is mentioned in the latest bootloader document http://www.ti.com/lit/ug/sprugy5b/sprugy5b.pdf, section 3.4.1:

“The bootloader code also configures the interrupt subsystem by configuring the chip-level interrupt controller, then executes the IDLE instruction (Mostly MSI or
legacy interrupts can be used). After the host transfers the boot table directly to the memory location and if the BOOT MAGIC ADDRESS register is non-zero, the ROM
code copies the start address of the application from the BOOT MAGIC ADDRESS to the program counter wakes up the DSP through an interrupt generated by poking the
MSI application register and executes the application loaded. If the BOOT MAGIC ADDRESS register is still zero the ROM code keeps the DSP in idle till the value is
non-zero”

Regards, Eric

Thank you, Eric, for the clarification. Sending a MSI triggers the DSP to jump to my dsp bootstrapping code and solved my problem.

After I push code, write BOOT_MAGIC and send MSI to dsp to start my bootstrap code to init DDR and some peripherials, can I jump back to ROM BOOTLOADER so that I can use the same procedure to push my DSP app once more?

We want to do this because the bootstrap code runs in L2, I have to keep stack and code in a separate section, so that my dsp application can't overwrite it during the bootloading. This create additional dependency between independent applications. If my dsp bootstrap code jumps back to DSP ROM BOOTLOADER when it finishes work, I can use L2 any way I want.

But this does not seem to work: After I jumped to ROM BOOTLOADER (0x20b00000), it immediately jump back to my bootstrapping. I even cleared the last 0xD230 bytes of L2 (the RAM used by rom bootloader), it still does not help. Is there anything I missed?

thanks

Weichun

Weichun,

How big is your bootstrap code in L2? If it is small enough, you can place it in the high-end of 0xD230 bytes of L2. At the end of bootstrap code (init DDR, some periphrals) you first clear the 0x87FFFC and then add a while loop to polling the 0x87FFFC again.

After bootstrapping, the code in L2 just start to monitor the 0x87FFFC. You don't need to jump back into BOOTROM. Instead, you can download your DSP application code via PCIE from the host (just make sure the application doesn't use the upper 0xD320 bytes). And then write _c_int00 to the 0x87FFFC. This should work if your bootstrap code is small.

Regards, Eric

Hi, Eric,

Thank you for the advice. I am using the loop in my bootloader to monitor the BOOT_MAGIC for now. The following is my bootloader's size, it used almost 3/4 of the L2. For now, I am moving the stack and the function containing the loop to the last 0xD230 RAM used by ROM bootloader to avoid trouble.

We have other dsp programs, power up diagnoistic, manufacture testing etc., developed by different groups. It is desired that we can boot the dsp independently. I am just curious, if I clear all the last 0xD230 and put the PC back to the entry of ROM bootloader, I would expect that it repeats the same sequence as power up, unless it saves something or changes something somewhere else, right?

thanks

Weichun

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  L2SRAM                00800000   00080000  0005ca1c  000235e4  RW X