主题中讨论的其他器件: AM2634
鉴于 AM2631不支持 XIP (就地执行)、是否公平地假设完整的 SBL 和应用(从闪存到 QSPI)被传输到内部 RAM、因此内部 RAM 的数量是 两者的硬性限制(考虑到代码和数据)?
我们正在评估是否需要通过 GPMC 连接外部 RAM。 类似的传统系统将大约1MB 用于引导加载程序+ 2MB 应用程序、总共3MB 闪存和2MB RAM。
此致、
哈维尔
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
鉴于 AM2631不支持 XIP (就地执行)、是否公平地假设完整的 SBL 和应用(从闪存到 QSPI)被传输到内部 RAM、因此内部 RAM 的数量是 两者的硬性限制(考虑到代码和数据)?
我们正在评估是否需要通过 GPMC 连接外部 RAM。 类似的传统系统将大约1MB 用于引导加载程序+ 2MB 应用程序、总共3MB 闪存和2MB RAM。
此致、
哈维尔
是的、应用受到内部 RAM 大小的限制、即2MB SRAM 和 256KB TCM 存储器。
SBL 或引导加载程序在引导期间只需要 RAM。 在应用程序执行开始后、您可以"收回存储器"。 您可以计划开发一个具有"无负载"段的应用链接器、如 堆栈 和 BSS 与 SBL 执行相同的存储器中、将 由应用程序 在 SBL 复位后使用。
此致、
Aakash
感谢您的回复 Aakash、
由于旧系统有自己的引导加载程序允许通过串行端口重新刷新应用程序、因此对于新系统、我们希望使用 SBL+重新刷新功能和应用程序、因此无法回收内存。
是否仅可通过 GPMC 增加内存?
此致、
哈维尔
我认为、您应该浏览勘误表- https://www.ti.com/lit/er/sprz488d/sprz488d.pdf
如果不受此勘误表的影响、则应考虑 将 GPMC 用于此器件。
我希望这对您有所帮助。
此致、
Aakash
尊敬的 Aakash:
我来看看 SDK 09.01.00中的 GPMC PSRAM 代码、其中 GPMC 的读取访问在函数 PSRAM_gpmcRead 中显示为16位:
volatile uint16_t *pSrc = (volatile uint16_t *)(offset+baseAddress);
volatile uint16_t *pDst = (volatile uint16_t *)buf;
我没有用于测试此代码的外部 RAM 存储器、但它是否正常工作、或者应该更改为32位访问模式?
此致、
哈维尔
Javier、您好!
在这里、请允许我联系专家。
此致、
Aakash
Javier、您好!
AM2634不支持 XIP。 代码不能从外部 PSRAM (也不能从闪存类存储器)中执行。
您好、QJ:
读取(PSRAM_gpmcRead)时、是否应将 SDK 09.01.00 GPMC PSRAM 示例的以下行更改为 uint32_t? 这是由于勘误表 i2313所致、
volatile uint16_t *pSrc = (volatile uint16_t *)(offset+baseAddress);
volatile uint16_t *pDst = (volatile uint16_t *)buf;
此致、
哈维尔
勘误表适用于从 NAND 闪存中读取的低于32位。 这不会影响 PSRAM 中的低于32位读取。
可以使用 uint32_t。