[参考译文] CCS/66AK2L06：mpmcl 加载失败

您好、Ari、

"mem_reserve" U-boot 变量仅告知 Linux 自身需要使用多少内存。 它不会影响 DSP 存储器。 但是、您可以使用它来减小 ARM 存储器的大小、以便 DSP 存储器可以跟随。

DSP 存储器根据 Linux 中的 DTS 节点进行分配、您可以在此处查看我们的示例：  

git.ti.com/.../k2l.dtsi

主要看一下名为"dspmim"的文件。 /etc/mpm/mpm_config.json.上还有一个用于 DSP 的配置文件

 我注意到的一件事是、您的映像位于存储器地址0x8000_0000、ARM 将在 Linux 中使用此地址。 如果您使用我们的 MPM DSP 存储器示例、您将需要在0xa000_0000找到该映像。 否则、会发生冲突。

此致、

Mike

您好 Mike！

感谢您的回复。 设备树设置现在对我来说是清晰的。 我将研究这一点。

但这也意味着我需要为每个 DSP CPU 构建不同的.out 文件、以便将它们加载到特定的绝对地址、对吧？ 或者是否有方法可以自动定位它们？

我需要在3个 CPU 和中运行相同的应用程序。 我打算通过从 Linux 命令提示符、shell 脚本或从 Linux 上运行的 ARM 应用程序中使用 mpmcl 来加载和运行它们。 我真的需要3个.out 文件(= 3个相同二进制文件的副本、仅具有不同的加载地址)、每个 CPU 一个、还是只能使用一个.out 文件？

到目前为止、我还没有找到一种方法来更改 CCS 6或 CCS7中 DSP 应用的 DDR3地址。 它们都始终将其强制为0x8000 0000。 在 CCS3中、使用.cmd 文件更容易实现这一点。

我尝试在 CCS6中使用.cmd、但它会发生冲突、因为 CCS 从某些模板获取 DDR3起始地址。 我怀疑地址是在目标配置文件(.cXML)中定义的、但它允许我仅更改 ARM CPU 的 DDR3地址、而不是更改 DSP 的 DDR3地址。 这是怎么回事？

请帮我解决这个问题。

此致、

Ari

您好！

请有人告诉我如何使我的 DSP 应用.out 使用从0xa000 0000开始而不是从默认的0x8000 0000开始的内存。

BRS、Ari

太棒了！ 有人在家里吗？

这是不是一个太小的问题、一个问题太难回答还是一个用户太愚蠢？

如果问题很小、那么人们可以期待它能快速回答。 什么需要时间？

－Ari

您好、RAN、

我已经尝试编辑现有平台并为项目创建一个新平台、SYS/BIOS 和 XDCTools、用于 CPU 和 GPP、清理并重建了项目、并且在这两个阶段之间也对 CCS 进行了多次重述。 没有什么帮助。 DDR3地址始终是生成的.map 文件中的0x8000 0000。 每次重写映射文件、但始终具有相同的内容。

最后、CCS 开始抱怨不支持 K2L 目标、因此我卸载了我一直使用的 SYS/BIOS 6.45.1.29和 XDCTools 3.35.60、因为我可能会通过一些绝望的蛮力尝试将它们损坏。 现在、我正在尝试让它们返回。 :-)

我不知道有没有其他想法。

BRS、Ari

您好、RAN、

>我想您修改了一个平台，但您的系统使用了与其他位置不同的平台(同名)。

我想你是对的。 它的行为与此类似、我无法弄清发生了什么。

>但我知道你已经花了太多时间，你想要一些肮脏的快速诀窍继续下去

这正是我的感受和想法！ 你像一本开放的书一样读我！ ：D

我理解您的"肮脏把戏"是如何工作的。 我在很久以前的另一个项目中也做过类似的事情。

但是、您能否向我展示一下您在 main.c 开头到底是如何执行"肮脏的把戏"的 它对我来说不能正常工作。 下面是我尝试执行该操作的方法：

//从0x9000 0000而不是0x8000 0000开始强制使用存储器的脏窍门：
#pragma DATA_SECTION (".sysmem")；
#pragma DATA_ALIGN (256*1024*1024)；
int g_reserved[256 * 1024 * 1024]；
//#pragma DATA_ALIGN (256*1024*1024)；
//int g_reserved2[256 * 1024 * 1024]；

#include "../../dspPlatform.h
#include "../../mcmControl.h
#include "../../interrupts.h
#include "../../dspLink.h
#include
#include
#include
#include
#include

如您所见、我的肮脏把戏就在主程序的开头。 但是、它仍然会将某些内容(我猜是堆)放入0x8000 0000、例如、当我使用 CCS 加载程序时、ARM Linux 会崩溃。

下面是.map 文件中的一个片段、显示了实际发生的情况：

(笑声)

00822428  __TI_CINIT_Base
00822458  __TI_CINIT_LIMIT
80000000  __ASM__
8000000  g_reserved
80000000  ti_sysbios_堆_HeapMem_instance_State_0_Buf__A
80000068  __ISA__
80000080  __PLAT__
800000b0  __TAGR__
800000d8  __TRDR__
90000000  XDC_RAuntime_SysMIN_Module_State_0_outbuf__A
90000400  ti_sysbios_KNL_Task_instance_State_0_stack__A
(笑声)

在加载程序前后、我在0x8000 0000处检查了 DDR3存储器的内容、可以看到加载程序写入了从0x8000 0000开始的堆填充、然后用零将存储器填充到0x9000 0000。 最初在0x8000 0000处有一些 Linux 内容。

因此、我们需要尝试其他方法。

BRS、Ari

好的、我们来看看选项：

1.了解您使用的平台。  例如，不要更改平台，用不同的名称定义一个新的平台。  在与编辑平台相同的浴缸中、使用 NEW 并为其命名为 ti.platforms.myName。  从您始终使用的平台导入这些值、然后查看是否可以保存新平台、然后尝试使用该平台。 您可能需要搜索新平台 的位置并将路径添加到存储库列表中

2.将堆的表述移动到 L2 (我假设它不是共享堆)并查看发生了什么情况。  顺便说一下、我们可能需要将 g-reserve 定义为 volatile。  我建议改用 MSMC 存储器、但我认为 Linux 使用的是与 DSP 进行通信(但我可能会错)

3.使用 MPAX 寄存器将(对于 DSP)逻辑地址0x8000 0000映射到物理地址0xA000 0000。  如果使用 RTSC 在 main 之前定义存储器、则应在 main 之前完成 MPAX 寄存器的配置。  (我可能会向您展示如何操作、但首先了解它的工作原理)

已运行

您好、RAN、

我最终得到了"选项1起作用"。 我现在可以根据需要设置存储器映射。 非常感谢！ 这也是稍后使用的一个好技巧。

但这并没有解决我原来的问题：如果应用程序使用 DDR3、我无法使用 mpmcl 加载应用程序。 我从之前的帖子中得到一个提示、即我应该将起始地址0x8000 0000移动到0xa000 0000。

我注意到的一件事是、您的映像位于存储器地址0x8000_0000、ARM 将在 Linux 中使用此地址。 如果您使用我们的 MPM DSP 存储器示例、您将需要在0xa000_0000找到该映像。 否则、会发生冲突。

现在已经完成了、但问题仍然存在。 命令"mpmcl load dsp0 dspMain"给出了以下错误：

从套接字读取超时

加载失败(错误：o)

在尝试使用"mpmcl run dsp0"运行应用程序后、会出现以下错误：

无法向/var/run/mpm/mpm_demon 发送数据(错误：连接被拒绝)

运行失败(错误：0)

以下是我无法使用 mpmcl 加载的应用程序的存储器配置：

输出文件名：   
入口点符号："_c_int00" 地址：b00251a0


存储器配置

        名称           源   长度     使用    未使用  的属性   填充
------------  ----  ------  ----  ----  --------  
 L2SRAM               00800000  00100000 00000400 000ffc00 RW X
 MSMCSRAM             0c000000  00200000 00000000 00200000 RW X
 DDR3                 a0000000  60000000 1005214c 4ffadeb4 RW X

为了更好地确保不与 Linux 冲突、我尝试了另一个地址空间、但仍然失败：

输出文件名：   
入口点符号："_c_int00" 地址：f80251a0


存储器配置

        名称           源   长度     使用    未使用  的属性   填充
------------  ----  ------  ----  ----  --------  
 L2SRAM               00800000  00100000 00000400 000ffc00 RW X
 MSMCSRAM             0c000000  00200000 00000000 00200000 RW X
 DDR3                 f0000000  10000000 0805214c 07fadeb4 RW X

这里是另一个应用程序的存储器配置、它可以正常加载和运行、完全不使用 DDR3：

输出文件名：   
入口点符号："_c_int00" 地址：0080ec80


存储器配置

        名称           源   长度     使用    未使用  的属性   填充
------------  ----  ------  ----  ----  --------  
 L2SRAM               00800000  00100000 00018b42 000e74be RW X
 MSMCSRAM             0c000000  00200000 00000000 00200000 RW X
 DDR3                 80000000  80000000 00000000 80000000 RWIX

在将应用程序加载到任何 DDR3地址时、似乎存在一些问题。 mpm-daemon 在执行此操作时会崩溃。

我尚未在器件树或/etc/mpm/mpm_config.json.中触摸 mpm 和 dsp 设置 它们与 EVM 板出厂设置相同。

您是否有一些想法、可能出了什么问题？

此致、

Ari

好 的、这是一个内存问题。    在我为 K2H 编写代码的"旧"时代、我记得、如果 mpmcl 对 DSP 输出文件不满意、它不会加载它、但不会发送有关套接字的消息。 因此、它可能会从过去的日子更改为现在的日子。

如果内核使用内存、mpmcl 将不会加载内存-我认为这是最初的问题。我会建议两个问题-

确保 mpmcl 复位 DSP0正常工作

DSP DDR3代码应位于 mem_reserve 区域内。   在 mem_reserve 上执行搜索并查看其配置方式，或者在 U-boot 中停止引导并执行 printenv，并查看 mem_reserve 的位置  。  这就是您的 DSP 代码所在的位置

请告诉我它是否起作用

已运行

您好、RAN、

我一直忙于其他更紧迫的任务、但现在我又有时间面对 mpmcl 挑战。 :-)

复位 DSP 内核没有问题。 发出命令：

mpmcl 复位 dsp0

工作正常、就像我很久以前说过的、我可以将.out 文件加载到内部存储器中并在其中运行、因此 mpmcl 基本上可以正常工作。 我还可以通过 JTAG 将.out 文件加载到 DDR3中、但这样做会使 Linux 崩溃、尽管我仍然可以使用 CCS 调试加载的.out 程序而不会出现任何问题。

在 u-boot 中、我将 mem_reserve 修改为1536、这应使 DDR3存储器区域0xA000 0000 - 0xFFFF FFFF 可用于 DSP 内核。

"mem_lpae"设置为1。

我还使用检查了 Linux 中的内存使用情况

CAT /proc/iomem

它报告内核代码位于

0x8 0000 8000 - 0x8 008A a073

和内核数据

0x8 008f 2000 - 0x8 0097 cfc3

但现在我注意到、Linux 已将其存储器映射到更宽的存储器(36位？) 地址空间、而不是32位。 这是什么导致了现在的问题？ 您之前提到过 MPAX 寄存器。 我是否应该对它们进行编程、以便为我的 DSP 应用进行类似的映射？

在内核启动期间、它显示：

[0.000000]   将物理地址空间切换为0x8000000

和更高版本：

[12.802699]   KeyStone-DSP-mem a0000000。dspmem：注册的 MiSC 器件 dspmem

如果我需要对 MPAX 寄存器进行编程、那么您能否简单地告诉我写什么？

我希望 Linux 在0x8000 0000 - 0x9fff FFFF 处运行、而在0xa000 0000 - 0xFFFF 处的 DDR3其余部分可用于所有 DSP CPU、这样 ARM 也可以访问同一区域(0xa000 0000 - 0xFFFF FFFF)。

此致、

Ari

好  的、让我们清除36位和32位。   

首先、我附上关于 MPAX 寄存器的简短演示。   查看演示文稿的开头、看看您是否已经知道演示文稿的内容。  如果您在这里有任何问题帖子。

是的、DSP 的默认设置是地址0x8000 0000被映射到0x8 0000 0000如果 你查看 MPAX 寄存器、你可以看到什么是默认设置。

显然、ARM 使用 DSP 使用的部分物理存储器。  问题在于如何找到它。   它可以在器件树或 uBoot 环境中定义。  它可以是内核代码的一部分、也可以是用户空间使用的 cmem 代码。

可以肯定的是、DSP 根本不使用 MSMC 存储器。

阅读随附的文档、然后您可以执行以下操作：

1.了解 DSP 代码和数据占用的(36位)非时存储器是什么。 了解 ARM 使用的36位物理地址是什么。 验证是否确实没有碰撞。 (必须是、否则我们无法解释您看到的内容)

2.在加载 DSP 之前、请查看分配给 DSP 的代码、并确保 ARM 不使用任何此代码。  (例如、从 CCS 连接 DSP 并加载 DSP 物理地址、然后查看 ARM 代码是否仍然正常工作)

在您验证所有物理地址后返回此处、我们将从此处继续

已运行

好的、 我现在附加它/CFS 文件/__key/communityserver-discussions 组件-files/791/5633.0181.KeyStone-XMC-and-MPAX-Registers.pptx

您好、RAN、

我已经阅读了您上次发送的演示文稿。

根据它、我必须将 MPAX HI 和 MPAX LO 设置为特定值。 我尝试了第29页上的1GB 分段示例、该示例似乎最符合我的需求、但无法完成我尝试获得的内容。

启动后、0x0800 0000处的 XMC 寄存器为：

0：xmc_xmpax_xmpaxl：000000BF
0：xmc_xmpax_xmpaxh：0000001E
1：xmc_xmpax_xmpaxl：800000BF
1：xmc_xmpax_xmpaxh：8000001E
2：00000080
2：00000000
3：00000080
3：00000000
4：00000080
4：00000000

我无法编辑寄存器对0和1、但对2、3、4、... 我可以。 0和1用于 ARM、其余用于 DSP0、DSP1等、或者它们的含义是什么？

在 GEL 文件中、我有一个用于设置对2的 XMC 寄存器的函数(位于地址0x08000010和0x08000014)。 它写入 LO = 0x121010FF、HI = 0x2101000B、但它们没有帮助。

然后、我尝试使用示例中的值：0x1d、2和0x20到对2：Lo = 20FF、HI = 201D。 他们也没有做任何好。

我创建了一个定制平台、以便将 DSP 代码映像加载地址从默认的0x8000 0000更改为0xa000 0000。 我已经从.map 文件中并通过使用 CCS 和仿真器进行调试验证了代码和数据位于0xa000 0000区域。

在器件树中、我有以下设置：

DSP_common_mpm_area：DSP_reserved_mpm_area

<8   0x2000 0000   0x0000 0x2000  0000>

CMA_POOL

<8   0x1f80 0000   0   0x800000>

MPM_MEM：dspmem @ 0xa000 0000

0xa000 0000   0x2000 0000>

cmem_block_mem0

<8   0x2200 0000   0   0x1e00 0000>

cmem_block_meM1

<0  0x0c08 0000   0   0x000c 0000>

cmem_block0

<1   0   0x1e00 0000>

cmem_block1.

…

接下来如何进行？

BRS、Ari

您好、RAN、

在"CMA_POOL"中、我有：

< 0x00000008   0x1f800000   0x00000000   0x800000>

我理解我应该把它放在那里

< 0x00000008   0x20000000   0x00000000   0x20000000>

但这会与"mpm_area"重叠：

< 0x00000008   0x20000000   0x00000000   0x20000000>

现在、我对如何继续有点困惑。

如果我更改了"CMA_POOL "在该区域的位置、我应该为"mpm_area"设置什么？

如何知道实际在物理36位存储器空间中将 DSP.out 加载到何处？ Linux 端是否有一些方便的工具用于该目的、或者可以从 mpmsrv 日志中找到该工具？ 到目前为止、我还没有找到这样的日志、但我想它是在某个地方。 或者、我是否只需要进行一些存储器浏览来发现 DDR3中常见的看起来像字节？

此致、

Ari

您好、RAN、

感谢您的快速回复。 我将尝试您的建议、并告诉您结果。

顺便说一下，我注意到，在 CCS 中为 DSP 内核加载 RTOS 应用程序时，在到达 main()函数之前，EVM_init 函数(在.cfg 中设置为"Startup.firstFxns"函数)已在加载时间内调用。 Linux 命令提示符下的"mpmcl load"命令是否也会发生这种情况？ 我的意思是、RVM_init 中是否有会导致系统崩溃的内容？

在 EVM_init()中，我具有以下内容；

   platform_info 信息；
   platform_init_config sconfig；
   int32_t pform_status；

   platform_UART_init()；
   platform_UART_set_baudate (UART_BAUDRATE)；
   (void) platform_write_configure (platform_write_all)；
   uint32 uartBaudDivisor =(DSP_CPU_OSC_FREQ_Hz/6)/(16 * UART_BAUDRATE)；
   CSL_UartRegs* uartRegs =(CSL_UartRegs*) UART_BASE_ADDRESS；
   uartRegs->DLL = uartBaudDivisor；
   uartRegs->DLH=0；

   memset ((void *)&sFlags、0、sizeof (platform_init_FLAGS))；
   memset ((void *)&sconfig、0、sizeof (platform_init_config))；

   sFlags.pll = 1；// 0 /* 1 =更新用于计时的 PLL */
   sFlags.DDR = 0；//外部存储器*/
   sFlags.tcsl = 1；/*时间戳计数器*/
   sFlags.phy = 0；/*以太网*
   sFlags.ECC = 0；/*内存 ECC *
   sConfig.pllm = 0x14；//0；//使用自定义 PLLM 而不是库默认时钟分频值

   pform_status = platform_init (&sFlags、&sconfig)；

   platform_get_info (&info)；   platform_init_flags sFlags；

   platform_write ("平台信息：\n")；
   platform_write ("板：%s\n"、info.board_name)；
   platform_write ("修订版本：%d\n"、info.board_rev)；
   platform_write ("频率：%u MHz\n"、info.frequency);
   platform_write ("S/N：%s\n"、info.serial_nbr);
   platform_write ("版本：%s\n"、info.version)；
   platform_write ("cpu\n")；
   platform_write ("\tcount：%d\n"、info.cpu.core_count)；
   platform_write ("\tenderationales:%d\n"、info.cpu.endian)；
   platform_write ("\TID：%d\n"、info.cpu.id)；
   platform_write ("\tmegamodule revision：%d.%d\n"、info.cpu.megamodule_revision_major、info.cpu.megamodule_revision_minor)；
   platform_write ("\tname：%s\n"、info.cpu.name);
   platform_write ("\trevision：%d\n"、info.cpu.revision_id)；
   platform_write ("\tsilicon revision：%d.%d\n"、info.cpu.silicon_revision_maor、info.cpu.silicon_revision_minor)；
   platform_write ("emac\n")；
   uint8* mac = info.emac.EEPROM_mac_address；
   platform_write ("\tEeprom MAC 地址：%02x：%02x：%02x：%02x：%02x：%02x：%02x\n"、
      Mac[0]、Mac[1]、Mac[2]、Mac[3]、Mac[4]、 MAC[5])；
   MAC = info.emac.efuse_mac_address；
   platform_write ("\tEfuse MAC address：%02x：%02x：%02x：%02x：%02x：%02x\n"、
      Mac[0]、Mac[1]、Mac[2]、Mac[3]、Mac[4]、 MAC[5])；
   platform_write ("\tport count：%d\n"、info.emac.port_count)；
｝

此致、

Ari

是的、startup 函数是 main 之前可执行文件的一部分、因此当您从 mpmcl 加载代码时、它也会运行

这是在 main 开始之前配置 MPAX 寄存器的方法。 原因是 c_init 在 main 之前初始化存储器、如果尚未配置 MPAX 寄存器、则初始化可能在错误的物理存储器中发生

已运行

您好、RAN、

我尝试更改设备树中的"CMA_POOL "地址。 结果是内核根本没有启动。 :-)

我使用"tftpboot"命令在 u-boot 中载入了修改后的器件树、只运行内核、而没有启动。 它在"正在启动内核..."之后未显示任何内容

然后我又执行了同样的操作(当然在断电后)、再次加载了修改后的器件树、但随后重新修改了"CMA_POOL"的原始地址并引导、内核正常引导。

因此、修改地址不是一个好主意、或者至少使用 reg =< 8 0x2000000 0 0x800000>是不好的。

在默认 MPAX 设置下、这个36位物理地址(8 0x2000 0000)等于32位地址0xa000 0000、我对吗？

我只是想知道为什么这是如此困难。 在 DSP 应用中使用 DDR3应该只是基本的东西。 为什么我需要修改一些"难以理解"的设备树设置？ 难道不应该已经对它们进行设置、以便最终用户可以轻松地开始使用系统？

我之前问过、"mpmcl"是否有一些简单的方法来了解36位地址空间中"mpmcl"尝试加载映像的位置。 这将帮助我了解发生了什么。 您可以在目标系统中命名一些工具或日志文件吗？

如果我将 printf 或 platform_write 放入"evm_Init"函数中、它是否应在"mpmcl 加载"期间打印到控制台？ 这样我就可以打印出一些指针等

此致、

Ari

我让 Linux 专家来看看这个问题。  将提供帮助(希望)

已运行

您好、Ari、

您能告诉我您正在使用的 SDK 和版本吗？

(您使用的是 Processor SDK 还是 MCSDK 以及版本)

这将有助于我相应地指导您完成此过程。

此致、

Sam

Sam、您好！

我不明白为什么0x8000 0000范围仍在帖子中。 它来自实验的早期阶段。 我已经很长时间尝试使用0xa000 0000范围。

请参阅我的最新.map 文件的片段：

入口点符号："_c_int00" 地址：a8025880


存储器配置

        名称           源   长度     使用    未使用  的属性   填充
------------  ----  ------  ----  ----  --------  
 L2SRAM               00800000  00100000 000005c0 000ffa40 RW X
 MSMCSRAM             0c000000  00200000 00000000 00200000 RW X
 DDR3                 a0000000  60000000 08052c08 57fad3f8 RW X

但是、正如前面所说的、它只是不起作用。 如果我从 CCS 加载 DSP.out、并且我使用"mpmcl"从 Linux 加载它、Linux 会崩溃、在经过长时间等待(一分钟左右)后、Linux 会提示：

root@K2L-EVM：~/tests# mpmcl load dsp0 dsp.out

从套接字读取超时
加载失败(错误：0)

另一次尝试提供：

root@K2L-EVM：~/tests# mpmcl load dsp0 dsp.out

无法向/var/run/mpm/mpm_demon 发送数据(错误：连接被拒绝)

加载失败(错误：0)
root@K2L-EVM：~μ A/测试#

再一次：我只想将我的大多数 DSP 代码和数据加载到 DDR3中、以便 Linux 在 ARM 中继续运行。 这方面绝对没有什么特别之处、对吧？ 仍然这么做似乎是惊人的复杂！

我还想对时间关键型代码使用一些 L2 SRAM。 因为我已将 L2配置为禁用、允许我自由地使用0x0080 0000处的 L2区域。

到目前为止、我们已经完成了：

1.在 u-boot 中、环境变量"mem_reserve"(或它的调用方式、现在不记得)已设置为1536 MB。 我已经了解了这一点、即 Linux 不会在0xa000 0000 - 0xFFFF FFFF 处接触到存储器。 是这样吗？

我已经创建了一个定制平台、以便 CCS 将.out 文件编译到0xa000 0000区域中。 这根据.map 文件运行。

3.我已阅读培训材料，了解如何设置 MPAX 寄存器，以便将32位地址映射到36位物理存储器中的段中。 我想我理解这一点、我已经在这些寄存器上设置了我自己的值、但这对崩溃没有影响。

4.我已尝试在设备树中设置“CMA_POOL”。 到目前为止、所有试验都已在引导中使 Linux 崩溃。

5.我已经检查了 Linux 的运行位置：

"Cat /proc/iomem 报告了这一点

内核代码位于

0x8 0000 8000 - 0x8 008A a073

和内核数据

0x8 008f 2000 - 0x8 0097 cfc3

因此、区域0xa000 0000 (物理地址为0x8 2000 0000、对吧？) 对于 DSP 应该完全免费。

所有这一切已经花了几个星期。 我认为这种情况太大了、因为我的项目截止时间即将到来、我现在已经失去了想法。

我只希望有人可以简单地告诉我：

1.如果需要更改默认值，应将什么内容放入 MPAX 中。 我假设默认值是可以的、因为我已经在 CCS 中将地址设置为0xa000 0000、而 Linux 没有使用该区域、对吧？

2.如果需要，如何编辑设备树。

如果这些设置已经正常、那么我将"在错误的树中进行巴金"、错误必须在其他地方。

此致、

Ari

您好、Ari、

很高兴听到您现在可以使用它。

我不清楚您在新存储器映射背后的意图。 您的新 DSP DDR 存储器映射是否在0xe000 0000 - 0xe1ffff 处使用代码/数据？

总之、让我尝试回答您的具体问题：

1.当应用程序在 Linux 端分配内存时，它们是否会从 CMEM 或系统 RAM 中获取内存"？ 或者、"cmemk.ko"内核模块的 CMEM 区域是否仅使用？

>> CMEM 区域仅保留用于 cmemk.ko。

2.在 Linux 端运行应用程序时，内核数据+代码会增长，还是应用程序使用系统 RAM？ 我是说我需要注意内核不会超过"通用 CMA 池"吗？

>>为常见 CMA 指定的内容保留给 CMA 分配。 无需担心使用该内存的其他内核分配。

3. Linux 引导消息将"公共 MPM 区域"(32 MB)命名为"DMA 内存池"。 它与 DMA 有什么关系？ ARM 端的 Linux 是否执行某些 DMA 传输、如果我只想在 DSP 端使用 DMA、是否需要具有此区域？

>> DMA 名称可能会误导开发者。 它仅用于保留该区域。 不涉及 DMA。

4、什么是 CMA 池？ 我试图从网上找到解释，但我发现我可以使用 CMEM 或 CMA，因为 CMA 只是一种添加，CMEM 仍然可以做所有的事情。 我是否需要 CMA？

>> CMEM 可从 CMA 池及其自己的内存中进行分配。 但可能还有其他应用程序也可以从 CMA 池中分配。

希望这能解答您的问题。

此致、

Sam

Sam、您好！

感谢您澄清我的所有问题1-4。 现在他们对我来说已经足够清楚了。

要回答有关我的新存储器映射的问题、Linux 会立即报告：

根目录@K2L-EVM：~# cat /proc/iomem

(笑声)

8000000000-dffffffffff：系统 RAM (引导别名)

80000000000－85ffffffff：系统 RAM

 800008000-8008aa073：内核代码

 8008f2000-80097cfc3：内核数据

862000000-87ffffffff：CMEM

我根本不打算在0xe000 0000 - 0xe1ffff 处使用"公共 MPM 区域"、因为我不知道它是什么、它太小(32MB)、几乎不能用于我的情况下的任何内容。

在原始存储器映射中、CMEM 模块中的一个被放置在(32位地址空间) 0xA200 0000 - 0xBFFF FFFF 中、从而严重分割了从0xA000 0000开始的其他可用区域。 我无法理解为什么它是作为默认设置进行的。 这一点似乎没有意义！

但是、通过这种新设置、我可以将 DSP 应用程序加载到0xA000 0000 - 0xDFFF FFFF 区域并运行、使其成为1 GB 的连续存储器。

对我来说、这是非常好的、但这是否有问题？ 例如、我是否应该放大"Common MPM Area"以填充"System RAM"以使其正确？

至少我现在(看起来)的应用程序可以完美地加载和运行。

BRS、Ari

是的。 如果内存区域对齐。 不应有任何问题。

Sam