[参考译文] TMS320C6678：C6000引导魔术地址更改.text

John：

有关引导地址的信息、请参阅此常见问题解答中给出的步骤。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1107106/faq-tms320c6657-how-to-wake-the-second-core-by-the-first-core-in-c6657-what-is-boot-magic-address-jump-boot-address

此致

尚卡里

感谢您提供这些信息。 我进一步调试了该问题、并隔离了损坏发生的位置/时间。

我们正在将许多内存段加载到 L2SRAM 和"程序"中。 如果应用程序的 L2SRAM 使用量增长到0x87FF80与0x87FFFF 重叠、似乎没有保护吗？ 这是您预期会发生的情况吗？在这些实例中、我们如何防止发生这种情况或至少无法编译？

如果在 app.cfg 中使用、"program"映射到什么？ 我怀疑它的 L2SRAM 也映射到了0x9000XXXX？

我们已设置 platform.XDC 以将程序映射到0x90000000、但数据表中未记录该地址。

               ["程序"、
                    {
                       名称："program"、
                       基地址：0x90000000、                    
                       LEN：0x10000000、                    
                       空白："代码/数据"、
                       访问："rwx"、
                    ｝
               ]、

最初90000000似乎映射到 L2SRM 直到87FFFF、对一项的更改会影响另一项。 我无法知道实际驻留后剩余的存储器位于何处。 我不确定0x90000000地址在做什么、能否详细说明这种行为、以及为什么允许像这样重用 RLB 存储器？

谢谢！

John：

让我看看它,然后回来。

此致

尚卡里

John：

请查看 Platform_test 代码的该内存映射、其中实现了引导魔术地址的代码片段。

"我不会介意的,我想要的只是要和你在一起。"

将内存部分与您的内存部分进行比较...

/*
 *  Linker command file
 *
 */

-c
-heap  0x41000
-stack 0xa000

/* Memory Map 1 - the default */
MEMORY
{
    L1PSRAM (RWX)  : org = 0x0E00000, len = 0x7FFF
    L1DSRAM (RWX)  : org = 0x0F00000, len = 0x7FFF 

    L2SRAM (RWX)   : org = 0x0800000, len = 0x080000
    MSMCSRAM (RWX) : org = 0xc000000, len = 0x100000
    DDR3 (RWX)     : org = 0x80000000,len = 0x20000000
}



SECTIONS
{
    .csl_vect   >       MSMCSRAM
    .text       >       MSMCSRAM
    GROUP (NEAR_DP)
    {
    .neardata
    .rodata
    .bss
    } load > MSMCSRAM
    .stack      >       MSMCSRAM
    .cinit      >       MSMCSRAM
    .cio        >       MSMCSRAM
    .const      >       MSMCSRAM
    .data       >       MSMCSRAM
    .switch     >       MSMCSRAM
    .sysmem     >       MSMCSRAM
    .far        >       MSMCSRAM
    .testMem    >       MSMCSRAM
    .fardata    >       MSMCSRAM
    platform_lib > 		MSMCSRAM
}

此致

尚卡里  

0x90000000地址以某种方式映射到 L2SRAM。

在编译器生成的映射文件中、如果显示 L2SRM 0x85ffff、并且 I 向上和向下翻页地址在0x9000000和0x86xxxx 透视图之间波动、则在调试器中报告为0x900xxxxx。

发生这种情况时、L2 SRAM 中的引导加载程序部分(c6678数据表中的表2-3)过载并损坏。 当达到 L2 SRAM 的末尾时、0x9xxxxxxx 地址空间会继续保留、但我无法确定它实际使用了什么存储器。

John：

无论如何、如果您有 C6678 EVM、请尝试查看我指出的常见问题解答、并检查它是否使用 Boot-Magic 来进行引导。

这样、您就有一个可运行的参考汇编代码、并将其与您的参考汇编代码进行比较。

此致

尚卡里

更多信息-我要查看的0x9000_0000地址实际上是似乎被高速缓存的 DDR 存储器。 我们打算通过此命令在 app.cfg 中禁用 DDR 缓存
Cache.setMarMeta(0x80000000,0xFFFFFFF,Cache.Mar_DISABLE);

使用调试器或 JTAG 加载是否有任何原因会影响缓存的完成方式？

使用调试器或 JTAG 加载是否有任何原因会影响缓存的实现方式？

否。无关。  

不会遇到其他客户的此类情况。

===

根据数据表、页号：111、图5-4：- L2存储器的块基地址从0x0080 0000h 开始、到0x0087 FFFFh 结束。

例如、地址位置0x10800000是 C66x CorePac 内核0 L2存储器的全局基址。 C66x CorePac 内核0可通过使用0x10800000或0x00800000来访问此位置。

事实上、"对于 C66x CorePac 内核0、如上所述、此值等效于0x10800000、对于 C66x CorePac 内核1、此值等效于0x11800000、对于 C66x CorePac 内核2、此值等效于0x12800000。 "

===

高速缓存用户指南位于： https://www.ti.com/lit/ug/sprugy8/sprugy8.pdf

===

是的、也许此地址、0x90000000映射至 DDR3。

在上面的带有 DDR3内存映射配置的采样连接器命令文件中、这一点非常明显。  

内存
{
L1PSRAM (rwx)：org = 0x0E00000、len = 0x7FFF
L1DSRAM (rwx)：org = 0x0F00000、len = 0x7FFF

L2SRAM (rwx)：org = 0x0800000、len = 0x080000
MSMCSRAM (rwx)：org = 0xc000000、len = 0x100000
DDR3 (rwx)：org = 0x80000000、len = 0x20000000
｝

===

请注意、" L2 SRAM 中的表2-3引导加载程序部分"从地址 0x0087 2DC0开始、到地址 0x0087FFFF 结束。

这里-->#define Magic_ADDR      0x0087FFFC (请注意、引导魔术地址是 L2SRAM 中引导加载程序部分的最后一个字段)

===

但是、L2SRAM 的引导加载程序部分 (起始地址0x0087 2DC0和结束地址0x0087 FFFF) 不应损坏...

如果此表损坏、则无法保证跳转引导。

也许,你可能必须找出根本原因的" 引导加载程序表损坏"。

在调试时、在哪个点不会发生损坏？  

==

此致

尚卡里