#flash #nor #boot #memory #rt500 #mx #flex-spi

mimxrt500-bootstub

用于在从FlexSPI NOR闪存启动时使cortex-m-rt与NXP i.MX RT500系列芯片协同工作的粘合代码

3个版本 (破坏性)

0.3.0 2023年9月11日
0.2.0 2023年9月11日
0.1.0 2023年9月11日

#645 in 操作系统


用于 2 crates

MIT 许可证

20KB
280

一些辅助宏,用于生成NOR闪存头部("闪存控制块"),初始向量表,以及可以写入到连接到i.MX RT500系列芯片上的FlexSPI0的NOR闪存开头的微小粘合代码,以处理其在跳转到其他内存地址(通常是同一闪存的较后页面或块)的更正常嵌入式Rust应用程序之前的特殊要求——通常是一个较后页面或块,但不是必需的。

这一系列芯片没有内置的闪存,因此而是有一个引导ROM,它探测各种外围设备以尝试找到包含引导映像的外部内存。一个选项是与FlexSPI0连接的NOR闪存,但这需要在闪存的第一页中的某些特定于芯片的头部信息,这些信息与初始向量表交织在一起,因此与由cortex-m-rt crate生成的典型映像布局不兼容。

为了以正常方式使用cortex-m-rt,此crate可以帮助生成一个小型的stub映像,将其写入内存的第一页,与主应用程序分开,然后主应用程序期望在某个其他内存地址找到基于cortex-m-rt的应用程序,并开始执行它。

这意味着至少浪费一页闪存内存,并使用一个仅由引导stub使用的冗余额外向量表,但这通常是为了满足嵌入式Rust生态系统对基于Cortex-M平台的期望而付出的微小代价。

Bootstub样式

为了满足不同应用需求,此库提供了两种不同的引导stub生成宏变体。每个应用程序必须恰好调用这些宏之一。

  • bootstub_builtin 是最直接的选择,它将引导stub直接嵌入到应用程序中,并通过由 cortex-m-rt 链接器脚本生成的向量表将控制权传递给应用程序代码。

    这种方法提供了最“正常”的开发体验,但代价是稍微膨胀了您的应用程序映像,因为它直接将引导stub嵌入其中。

  • bootstub_standalone 是一个更专业的选项,它允许构建一个只包含引导加载器的可执行文件,期望在固定的内存位置找到真实的应用程序向量表。

    理论上,这种方法只允许闪存引导加载器映像一次,然后作为单独的操作将具有其向量表的标准应用程序代码在指定的地址进行闪存。引导加载器和应用程序相互独立,可以分别更新。

闪存控制块

RT500 引导 ROM 还需要 NOR 闪存包含一个 闪存控制块,这是一个数据结构,它声明闪存内存被用作引导介质,并帮助引导 ROM 有效地配置 FlexSPI0 外设以从中读取。

如果您的闪存不包含闪存控制块,则引导 ROM 将不会将 NOR 闪存视为候选引导介质。

使用 [fcb] 声明闪存控制块,然后使用您的链接脚本将其链接到适当的位置。

无运行时依赖