U-Boot:ARM:简单的延迟功能,因为先有鸡还是先有蛋的问题
我在修改时遇到了先有鸡还是先有蛋的问题 (修复)意法半导体 SoC 的一些驱动程序
问题,我将在访问某些驱动程序时实现超时 寄存器。不幸的是,我无法使用基本的 mdelay()
或 使用此函数的更高级别函数,因为 在这些 SoC 上,之前没有设置和启用计时器。 此外,ARMv7-M
SysTick
定时器也不会被使用。
我可以写一个简单的延迟循环,它在 来自处理器速度的频率。但我认为,这是 这不是一个好主意。
有什么建议吗,我能做什么?我还是 U-Boot 新手, 所以我不知道是否存在简单的延迟功能。
更新:
我目前无法使用 SysTick 计时器的原因是,它不会在当前配置中链接。这不是什么大问题。但 SysTick
低级源代码的当前实现定义了函数,这些函数将由这些 SoC 系列上的另一个定时器驱动程序定义。因此,当我在 Kconfig
中启用 SysTick
时,我可能会收到这些函数的多个定义的链接器错误。
恕我直言,示例驱动程序存在致命问题(轮询寄存器值时缺少超时):
GitHub:U-Boot:driver/clk/ clk_stm32h7.c
驱动程序当前需要外部工作时钟源 (HSE
)。当前电路不存在任何问题 执行。还有外部的固定(定义)频率 时钟源。
在驱动程序的探测函数 stm32_clk_probe()
中 将被调用configure_clocks()。这是问题所在。
来自 configure_clocks()
的代码片段:
/* Switch on HSE */
setbits_le32(®s->cr, RCC_CR_HSEON);
while (!(readl(®s->cr) & RCC_CR_HSERDY))
;
当没有外部时钟源或电路出现问题时,RCC_CR_HSERDY
永远不会由硬件设置。这些导致无限循环。死循环。
I'm running into an chicken and egg problem when modifying
(fixing) some drivers for STMicroelectronics SoC's
The problem, I will implement a timeout, when accessing some
registers. Unfortunately I cannot use the basic mdelay()
or
higher level functions, which use this function, because
on these SoC's there isn't setup and enabled the timer before.
Also the ARMv7-M
SysTick
timer will not be used.
I could write a simple delay loop which counts down at the But I think, this is
frequency from the processor speed.
not a good idea.
Any suggestion, what I can do? I'm still new in U-Boot,
so I don't know if there a simple delay function exists.
UPDATE:
The reason why I currently cannot use the SysTick
timer is, that it will be not linked in the current configuration. This is not a big problem. But the current implementation of the SysTick
low-level source defines functions, which will be defined by another timer driver on these SoC series. So when I enable the SysTick
in Kconfig
I will be possible that I get a linker error with multiple definition of those functions.
Example driver with IMHO an fatal issue (missing timeout when polling a register value):
GitHub: U-Boot: driver/clk/clk_stm32h7.c
The driver currently requires a external working clock source
(HSE
). No issues in the circuit are accepted by the current
implementation. Also a fixed (defined) frequency of the external
clock source.
In the probe function stm32_clk_probe()
from the driver there
will be configure_clocks()
called. Here are the issues.
A code snippet from configure_clocks()
:
/* Switch on HSE */
setbits_le32(®s->cr, RCC_CR_HSEON);
while (!(readl(®s->cr) & RCC_CR_HSERDY))
;
RCC_CR_HSERDY
will here never set by hardware, when there is no external clock source or an issue in the circuit. These leads in an endless loop. The loop of dead.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论