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

admin

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1256529/tms320c6678-c6000-boot-magic-address-changes-text

器件型号：TMS320C6678

我们在 c6678 DSP 上运行、并将 CCS8与 CGT C6000_8.3.2配合使用、并且可以看到写入 boot_magic_address 时.text 段似乎损坏了。

extern volatile cregister unsigned int DNUM；

uint32_t getDspId (){
返回 DNUM；
｝

core0写入引导魔术地址之前的汇编

写入内核1的引导魔法地址后、从内核0开始汇编所有内核、但0暂停

当 core1的第一次内核写入 boot_magic_address 时、asm 代码会同时更改。据我所知、在写入 IPC 后释放这些内核之前、引导魔法 addr 实际上并没有太大作用。

#define MAGAIC_ADDR 0x87fffc

#define boot_magic_ADDR (x)(MAGIC_ADDR +(1<<28)+(x<<24))

写入 boot_magic_address 时是否会进行更多处理？写入 boot_magic_address 时、我看到程序的.text 段已修改其存储器、特别是有一个字设置为 c_int00值。写入的地址没有位于更改的.text 存储器附近的位置(一个实例中为0x9004007C)

1 年多前

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

此致

尚卡里

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

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

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

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

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

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

谢谢！

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

John：

让我看看它,然后回来。

此致

尚卡里

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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
}

此致

尚卡里

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

谢谢！我主要关注的是0x90000000地址以及它实际的作用。部分数据出现在 L2SRAM 中、但映射文件的地址为0x90000xxxx。假设地址是虚拟的、并不实际存在、我不知道剩余的0x90000000数据位于存储器中的什么位置。

我不知道我们为什么要使用0x90000000地址、或者先前的开发人员从何处获得它。

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

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

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

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

John：

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

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

此致

尚卡里

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

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

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

使用调试器或 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) 不应损坏...

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

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

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

此致

尚卡里

0 admin 1 年多前

TI__Guru**** 1791630 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

此问题已确定为一个程序性问题、即 L2 RAM 何时从引导加载程序模式更改为用作缓存存储器。

仅当使用 CCS 从 JTAG 启动 DSP 时、才会出现此问题。如果程序最初加载到所有8个内核上、则内核1-7将在它们运行之前切换到使用 L2SRAM 作为缓存。

当 Core0启动时、它正在写入引导魔法地址、此时其他内核切换到缓存模式、并且相关地址根本不能用作引导地址。

处理器（参考译文帖）

处理器（参考译文帖）(Read Only)

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