Cha*_*shi 2 c qemu stm32 embedded-linux cortex-m
我正在尝试使用 CPU cortex m4 模拟 STM32 机器的时钟控制。STM32参考手册中规定,向内核提供的时钟是由HCLK提供的。
RCC 为 Cortex 系统定时器 (SysTick) 的外部时钟提供除以 8 的 AHB 时钟 (HCLK)。SysTick 可以使用此时钟或 Cortex 时钟 (HCLK) 工作,可在 SysTick 控制和状态寄存器中进行配置。
现在 Cortex m4 已经由 QEMU 模拟,我正在使用相同的 STM32 模拟。我的困惑是我应该提供我为STM32开发的“HCLK”时钟频率以将时钟脉冲发送到cortex m4还是cortex -m4本身设法拥有自己的时钟,HCLK时钟频率为168MHz?或者时钟频率不同?
如果我必须将此频率传递给皮层 m4,我该怎么做?
QEMU 的仿真通常不会尝试仿真以兆赫兹速率发送脉冲的实际时钟线(这将是非常低效的)。相反,当来宾对计时器设备进行编程时,计时器设备的模型会设置一个内部 QEMU 计时器,以便在适当的持续时间后触发(然后该处理程序会引发中断线或执行模拟硬件行为所需的任何操作)。持续时间是根据客户机写入设备寄存器的值以及时钟频率的值来计算的。
QEMU 没有任何基础设施来处理诸如可编程时钟分频器或在 SoC 周围路由时钟信号的“时钟树”之类的东西(可以添加一个,但还没有人抽出时间来做)。相反,定时器设备通常要么使用硬编码频率编写,要么编写为具有 QOM 属性,允许由创建它们的板或 SoC 模型代码设置频率。
特别是对于 Cortex-M 模型中的 SysTick 设备,当前实现将对它使用的 QEMU 定时器进行编程,其持续时间对应于以下频率:
(system_clock_scale 全局值应设置为 NANOSECONDS_PER_SECOND / clk_frq_in_hz。)
1MHz 只是一个愚蠢的硬编码值,还没有人费心去改进,因为我们还没有遇到关心的客户代码。全局 system_clock_scale 很笨重,但可以工作。
这些都不会影响模拟 QEMU CPU 的速度(即在给定时间段内执行多少条指令)。默认情况下,QEMU CPU 将“尽可能快”地运行。您可以使用 -icount 选项来指定您希望 CPU 以相对于实时的特定速率运行,这隐式地设置了“CPU 频率”,但这只会粗略地设置平均值 - 一些指令会以一种不太可预测的方式比其他人跑得快得多。一般来说,QEMU 的理念是“尽可能快地运行来宾代码”,并且我们不会尝试任何接近周期精确或其他严格计时的模拟。
截至 2020 年的更新:QEMU 现在拥有一些用于建模时钟树的 API 和基础设施,这些 API 和基础设施记录在源树中的 docs/devel/clocks.rst 中。这基本上是上述概念的形式化版本,使一个设备更容易告诉另一个设备“我的时钟速率现在是 20MHz”,而无需使用“system_clock_scale”全局变量或临时 QOM 属性等黑客手段。