Hi,
In the C6670 data manual (SPRS689D), the description for the BOOT_ADDR is in Table 3-2 Device State Control Registers. There are no details about whether this register is readable. The table entry is:
0x02620040 0x02620043 4B DSP_BOOT_ADDR0 The boot address for C66x DSP CorePac0
I am finding that if I read this register from a Linux host across the PCIe bus I sometimes get rubbish values and sometimes get a valid value. Is this register readable?
I am renaming my original post and adding new questions to it:
We are basing our code on the TI example found here: C:\TI_MCSDK\mcsdk_2_01_00_03\tools\boot_loader\examples\pcie\linux_host_loader\pciedemo.c
Is this a good example if we want to implement the "Local Reset" as described in section 7.4 Reset Controller of tms320c6670_revD.pdf (TMS320C6670 Data Manual)?
We are finding that writing to the DSP_BOOT_ADDR register does not always seem to work. The Linux host says that it has written to that address and we are doing the kick unlocks as given in the setBootAddrIpcgr function in the TI example. However, looking at that address with CCS shows that instead of the expected value of 0x8f8001, we see the bootROM address of 0x20b00001. It is unclear whether the attempt to write a value to DSP_BOOT_ADDR failed, or whether the value is being overwritten. From slowly removing code from our example it looks like the write is just not working. We do have a scenario where we reset two DSPs, one after the other, and the reset of the second one works and we see the expected value in DSP_BOOT_ADDR so we have seen it work but if we reset only one DSP it does not ever work.
Our scenario is that the DSP boots from SPI and we expect value 0x31D0D in the DEVSTAT register at 0x02620020. After running the reset code we frequently see the value 0x350FF in the DEVSTAT register which does not make sense. Is there any part of the reset example code which could overwrite DEVSTAT?
The reset scenario we need to implement is as follows: When the DSP is powered on, it boots from flash (SPI). Later, the DSP can be running code or can be in an unknown state during normal operation. The Linux host must be able to reset it across the PCIe bus and download code which will run in a loop which watches the magic address then jumps to it if it is populated. Is the TI example quoted above a good way to implement this kind of reset?
In the example, once a value is successfully written to DSP_BOOT_ADDR, what actually tells the DSP to use the value in that register and jump to that code? In the example code, this line causes the code to jump, is that correct: "myIowrite32(1, pReg + IPCGR(core)/4); " ? From the data manual, "The C6670 has four IPCGRx registers (IPCGR0 through IPCGR3) registers. This can be used by external hosts or CorePacs to generate interrupts to other CorePacs. A write of 1 to IPCG field of IPCGRx register will generate an interrupt pulse to CorePacx (0 <= x <= 3)."
How is this interrupt serviced? Do we need to provide some sort of ISR? We are not setting up any interrupt sources. Where will the code go?
Thanks,
Geraldine
