1. 问题出现一套看似互斥的机制为何还是踩了坑先交代一下背景。我最近在一块基于STM32MP257的板子上调试异构多核启动流程系统里同时跑着 Linux跑在高性能的Cortex-A35上和一个裸机程序跑在实时核Cortex-M33上。整个项目里 RTC 是两边都要用的关键外设A 侧要读系统时间、校准时钟M 侧要定时唤醒、记录事件时间戳。按正常分工RTC 的初始化应该由其中一个核完成然后另一侧在需要时直接读取。为了防止两侧同时初始化导致 RTC 寄存器状态不一致我在启动流程里引入了 ST 提供的资源管理器Resource Manager简称RESMGR并且在 M33 侧持有RESMGR_RTC_INIT_RSC这把资源锁等于告诉 A35“RTC 正在被 M33 初始化你先别动。”结果问题来了。M33 侧持锁期间A35 上的 Linux 驱动仍然能正常读取和写入 RTC 时间甚至我在 A35 上用date -s改时间M33 那边读到的 RTC 值也跟着变了。也就是说这个 lock 根本没起到“阻止另一方修改 RTC”的隔离效果。这不是预期行为。我把整套机制翻了一遍才搞明白 RESMGR 锁在这里的真实语义和限制。如果你也在 STM32MP2 系列这颗 SoC 上做异构多核开发或者正准备在 A35/M33 之间共享外设我建议你把下面这些东西看完能少走很多弯路。本文适合正在做 STM32MP2 平台 BSP 和异构多核应用开发的工程师也适合对处理器资源隔离机制感兴趣的嵌入式开发者。我会从 SoC 架构讲起把资源锁的底层逻辑、调试过程、正确用法一次讲清楚。2. 整体设计与思路拆解异构多核系统的资源管理到底在管什么2.1 STM32MP257 的双核架构与协作模式STM32MP257是意法半导体 MP2 系列里很有代表性的一颗异构应用处理器。它集成了双核 Cortex-A35 和一个 Cortex-M33。A35 侧跑高性能应用通常是人机界面、网络协议栈、文件系统而 M33 侧适合跑实时控制任务比如电机控制、数据采集、快速响应中断。这两类核心的工作方式完全不同A35 跑 Linux讲究调度公平、虚拟内存、进程隔离M33 跑裸机或 RTOS讲究确定性和低延迟。两个核心共享同一颗芯片上的外设资源这就引出嵌入式异构系统里最核心的问题——外设所有权和访问权限的分配。RTC 就是典型例子。A35 需要 RTC 维护系统时间M33 也需要 RTC 做低功耗定时唤醒。如果两边各管各的就会出现初始化竞争、寄存器半更新状态、时间戳不一致等一系列问题。于是芯片厂商设计了资源管理器这套机制希望用软件协议的方式协调各方对外设的访问。2.2 资源管理器RESMGR的设计初衷ST 的资源管理器本质上是一个软件协议层运行在带安全权限的上下文中通常属于 OP-TEE 或安全启动环境的一部分。它给每个共享外设定义了一组“资源”并规定了谁可以使用、谁需要等待、谁有权初始化。RESMGR_RTC_INIT_RSC是 RTC 模块对应的“初始化资源”标识。当一个核要初始化 RTC 时它先去获取这把锁初始化完成后再释放。其他核如果也想初始化必须等锁释放。这套机制的主要目的是防止多核同时操作 RTC 的初始化序列避免时序交错导致 RTC 内部状态寄存器错乱。但这里有一个关键细节很多人第一次接触时会忽略RESMGR 锁默认是“协作式”的不是“强制式”的。它更像是一个“约定信号”而不是硬件级别的“访问门禁”。注意RESMGR 锁的基本语义是“防止多个内核同时执行初始化流程”而不是“锁上之后其他内核完全无法碰这个外设”。这两者之间有本质区别用错场景就会出现我在开头说的情况。这就像办公室共用的打印机如果有人在打印机上贴了一张纸条说“我正在初始化请勿使用”同事自觉时是不会动的。但如果有人在走廊另一头没看到纸条直接按了打印按钮打印机照样会响应。RESMGR 锁就是那张纸条不是带电的门禁锁。2.3 为什么锁不住寄存器访问权限与资源锁是两套体系搞明白 RESMGR 的限制之后答案就清晰了A35 能更新 RTC 时间不是 bug而是锁的覆盖范围本来就不包括“阻止直接寄存器访问”。RTC 寄存器的硬件访问控制在 STM32MP257 上由另一套机制管理——RCC 配合 TrustZone 及相关的外设隔离单元类似 ETZPC决定哪个内核可以对 RTC 的寄存器做读写。如果这些硬件隔离单元配置为允许 A35 访问 RTC那 A35 侧 Linux 驱动通过 MMIO 直接操作 RTC 寄存器就完全合法RESMGR 锁无法拦截这种访问。所以问题在设计的定位上就错了把 RESMGR 锁当成硬件级别互斥锁来用期望它阻止所有访问这是不合理的期望。RESMGR 锁的正确用法是协调“初始化流程”的时序而不是做持续的外设访问隔离。提示用生活类比理解的话RCC/ETZPC 是“门禁”决定谁能进入房间RESMGR 是“房间内的工作台预约单”决定谁正在用工作台。你拦住了别人预约工作台但对方如果自己卧室里还有一张工作台或者有直接操作房间设备的权限照样能干活。要让 A35 完全摸不到 RTC需要去配置“门禁”不是“预约单”。3. 核心细节解析与实操要点RESMGR_RTC_INIT_RSC 的完整获取流程3.1 获取与释放锁的标准步骤在 STM32MP2 平台上使用 RESMGR 锁的标准流程并不复杂但有几个细节会影响锁的效力。我先把常规步骤列出来在安全侧启动阶段确保资源管理器框架已被正确初始化。在使用 RTC 的核上调用资源管理器 API 获取RESMGR_RTC_INIT_RSC。检查返回值确认锁获取成功后再开始 RTC 的初始化序列。初始化完成之后释放锁。如果加锁超时或返回错误做好重试和错误处理。在 M33 侧裸机环境下伪代码大致长这样/* 获取 RTC 初始化资源锁 */ resmgr_ret_t ret resmgr_acquire_resource(RESMGR_RTC_INIT_RSC); if (ret ! RESMGR_OK) { /* 锁获取失败说明另一侧正在初始化 RTC */ error_handler(); return; } /* 执行 RTC 初始化序列 */ rtc_init_sequence(); /* 初始化完成释放锁 */ resmgr_release_resource(RESMGR_RTC_INIT_RSC);在 A35 侧 Linux 环境中由于 RESMGR 的安全操作通常封装在 OP-TEE 驱动里一般是通过 EDT外设设备树配置或安全监控调用处理器中的 SCMI 接口完成。内核态中会封装成类似这样的调用int ret optee_resmgr_acquire(RESMGR_RTC_INIT_RSC); if (ret 0) { pr_err(Failed to acquire RTC init resource\n); return ret; } /* 初始化 RTC */ rtc_init_linux(); optee_resmgr_release(RESMGR_RTC_INIT_RSC);注意这里我简化了中间层的封装但逻辑链路是完整的。3.2 坑点一锁的“持有时间”与“访问窗口”不一致我在调试中发现的第一个问题是RESMGR 锁只覆盖初始化阶段但很多人包括我最初会下意识认为它覆盖 RTC 的整个使用周期。实际上在 ST 的参考实现中RESMGR_RTC_INIT_RSC的含义就是“RTC 初始化资源”它不叫RESMGR_RTC_ACCESS_RSC或RESMGR_RTC_OWNER_RSC。这也就是说锁的本职工作只解决“谁先初始化 RTC”这个竞争点。一旦初始化完成锁释放后两侧理论上都认为 RTC 处于可用状态后续的读写访问并不受这把锁约束。于是我建议在项目设计阶段就把外设资源的“所有权划分”理清楚不要指望一把锁解决所有问题。在 RTC 这个例子里更合理的做法是约定初始化只由启动更早的 M33 完成或者反过来由 A35 完成。初始化完成后将 RTC 标记为“共享可读、受控可写”。如果需要避免两侧互相覆盖时间还需要在应用层做额外的读写仲裁。3.3 坑点二RTOS 和 Linux 侧对时钟源选择的差异另一个容易踩的坑是时钟源配置不一致。STM32MP257 的 RTC 可以有多个时钟源内部低速 RC、外部 32.768kHz 晶振等A35 侧的 Linux 驱动和 M33 侧裸机代码对 RTC 时钟源的配置偏好可能不同。如果把 RESMGR 锁当成一次性的“初始化互斥”来用那没问题——谁拿到锁谁配置时钟源另一方只用不配。但如果像我们一开始那样误以为有了锁就能阻止对方操作结果双方在各自侧都可能尝试重新配置时钟源就会导致时钟计数不稳定、时间跳跃等诡异现象。我实际遇到过一次M33 侧完成初始化后释放锁A35 的驱动判断 RTC “未初始化”于是重新配置了时钟源。这个行为本身不违反 RESMGR 的规则因为锁已释放但直接导致后续时间漂移。后来我通过在设备树里显式声明 RTC 已被 M33 初始化并禁止 A35 驱动重复初始化 RTC才修复问题。3.4 实操心得锁的有效性要分“初始化阶段”和“运行阶段”验证在验证锁是否生效时建议不要只测试一两个用例就收工。我自己的测试清单包括验证 M33 持锁期间A35 侧调用初始化流程是否会阻塞或返回失败预期是等待或失败。验证 M33 释放锁之后A35 侧是否能正常获取锁并执行自己的初始化流程。验证 A35 在 M33 持锁期间如果只是“读”RTC 时间是否被允许预期会被允许因为锁不拦截普通访问。验证 A35 如果强行“写”RTC 时间硬件层面是否允许取决于 ETZPC/RCC 配置。第 4 点正是本文标题场景的核心如果硬件隔离单元放行了 A35 写 RTC那 A35 就能更新 RTC 时间哪怕 M33 还锁着初始化资源。4. 实操过程与核心环节实现从日志定位到最终修复4.1 现场复现如何确认 A35 在持锁期间改了时间先把我在现场怎么确认这个问题的过程写出来方便你自己复现和判断。我的硬件环境是 STM32MP257 评估板A35 侧跑的是基于 SDK 的定制 LinuxM33 侧跑的是一个简单的裸机程序每秒从 RTC 读一次当前时间并通过串口打印。操作步骤是这样的在 M33 侧启动后立刻获取RESMGR_RTC_INIT_RSC并持续持有同时打开串口日志。在 A35 侧进入 Linux 后用date -s 2025-06-08 12:00:00修改系统时间。观察 M33 串口日志看读到的 RTC 时间是否发生变化。我执行date -s之后M33 侧打印的时间立刻跳到了修改值。这个现象直白地说明A35 能够直接操作 RTC 硬件而 M33 持有的初始化资源锁并未拦截这次写入。4.2 分析过程从日志到源码的三步定位法定位这个问题的过程可以总结为三步这套方法对排查异构多核外设访问冲突问题通用性很高第一步查看硬件访问权限配置。我优先查看了 RCC 和 ETZPC 相关寄存器的配置确认 A35 是否被允许访问 RTC。如果这里配成只有 M33 能访问那 A35 根本没办法写 RTC也就不会出现标题里的现象。第二步确认 RESMGR 锁的实际覆盖范围。我仔细阅读了芯片参考手册中关于 RESMGR 的章节以及 SDK 里对应的资源管理器源码确认锁的获取和释放只影响“初始化”流程。源码里并没有在任何地方检查锁状态后再去拦截 RTC 的读写寄存器操作。第三步验证 A35 Linux 驱动里的初始化路径。我查看了内核里 RTC 驱动的 probe 流程发现驱动会在 probe 时执行一次初始化判断。由于 RESMGR 锁没有覆盖这个流程驱动会认为 RTC 处于可配置状态从而在 M33 持锁期间继续执行寄存器写入。注意如果你的 A35 侧驱动在每次set_time操作前后还会尝试获取锁那行为会不一样。我在检查中发现配套 SDK 里的 RTC 驱动并没有在set_time路径上获取RESMGR_RTC_INIT_RSC这也是为什么date -s可以穿透锁的原因。4.3 修复策略对比三种方案我为什么选了协调式访问确认问题之后我评估了三种修复方案你可以根据自己的应用场景选择第一种方案调整硬件隔离配置禁止 A35 访问 RTCRTC 完全归 M33 管理A35 通过核间通信如 RPMsg向 M33 请求读写时间。这种方案的隔离性最强但代价是 A35 侧每个 RTC 操作都会引入 IPC 开销而且 Linux 驱动里很多路径是直接访问 RTC 寄存器的改动较大。第二种方案把 RESMGR 锁的语义扩展到“整个 RTC 生命周期”即 M33 在初始化之后一直持有锁不释放A35 驱动在访问 RTC 前也去尝试获取锁拿不到就返回失败。但前面分析过这不符合锁的原始设计语义而且可能引入死锁或性能问题。不推荐。第三种方案在应用层做协调。M33 和 A35 约定 RTC 只能由一方修改另一方只读取。初始化完成后A35 侧驱动完全不做 RTC 写入M33 侧也只在极少数情况下如校时命令修改时间。这样不依赖锁机制去拦截硬件访问逻辑清晰改动量小。我最终采用的是第三种方案的变体在设备树里通过别名和状态标志让 A35 的 Linux 驱动认为 RTC 已经被安全侧初始化进入“只读”模式。同时M33 侧保留完整的 RTC 读写能力并在应用层实现一个简单的校时服务供 A35 通过 IPC 请求对时。4.4 修改后的关键代码骨架在 M33 侧RTC 时间修改服务的大致结构如下void rtc_ipc_handler(struct rtc_command *cmd, struct rtc_response *resp) { switch (cmd-type) { case RTC_CMD_GET_TIME: resp-tv_sec rtc_get_seconds(); resp-status RTC_OK; break; case RTC_CMD_SET_TIME: /* 仅 M33 侧允许直接写硬件 RTC */ rtc_set_seconds(cmd-tv_sec); resp-status RTC_OK; break; default: resp-status RTC_ERR_UNSUPPORTED; break; } }在 A35 侧通过 RPMsg 通道发请求给 M33static int request_rtc_set_time(unsigned long sec) { struct rtc_command cmd; struct rtc_response resp; int ret; cmd.type RTC_CMD_SET_TIME; cmd.tv_sec sec; ret rpmsg_send_and_wait(cmd, sizeof(cmd), resp, sizeof(resp)); if (ret 0) return ret; return resp.status; }这套设计确保 A35 不会直接访问 RTC 硬件寄存器从根上避免标题里提到的“A35 绕过锁更新 RTC”问题。5. 常见问题与排查技巧实录异构多核 RTC 管理的避坑清单5.1 问题速查表我整理了一张速查表把这次调试中遇到以及可能遇到的典型问题按现象、原因、对策列了出来你自己排查时可以对照使用。现象可能原因排查思路对策A35 在 M33 持锁时仍能写 RTC 时间RESMGR 锁不拦截普通寄存器访问ETZPC 允许 A35 访问 RTC检查 ETZPC/RCC 寄存器配置检查 RESMGR 锁的覆盖范围从应用层统一仲裁或改用硬件隔离RTC 时间在启动后发生漂移或跳变两侧重复初始化 RTC时钟源配置不一致对比两侧初始化日志检查时钟源寄存器明确单一初始化方初始化后禁止重复 initM33 侧读取的时间与 A35 侧不一致两侧用不同基准RTC 被某一侧重置分别打印时间戳检查哪一侧发起了写操作确保只有一方写 RTC另一方只读或走 IPCA35 驱动 probe 失败驱动认为 RTC 已被占用或权限不足查看 dmesg确认设备树状态在设备树中声明 RTC 初始化状态获取 RESMGR 锁超时另一侧长期持有锁且未释放检查锁持有者的日志确认释放路径完善错误处理增加看门狗或超时恢复5.2 独家避坑技巧在设备树里声明 RTC 的“初始化归属”我在调试中发现A35 Linux 驱动很大程度依赖于设备树里的初始化状态标记。如果你想让 A35 驱动跳过 RTC 的初始化流程只保留读取能力可以在设备树节点里加入一个自定义属性然后在驱动 probe 时做判断。rtc { st,rtc-initialized-by m33; status okay; };内核驱动里对应的处理逻辑static int rtc_probe(struct platform_device *pdev) { struct device_node *np pdev-dev.of_node; if (of_property_match_string(np, st,rtc-initialized-by, m33) 0) { /* RTC 已由 M33 初始化本侧只读 */ dev_info(pdev-dev, RTC init by M33, read-only mode\n); /* 跳过 init 寄存器序列 */ } ... }这套方法的好处是把“谁初始化”的约定明确写到了设备树里驱动行为可预期后期维护也方便。5.3 再提一个隐藏陷阱RTC 电池与备份电源电压检测调试 RTC 时还有一个隐藏陷阱容易跳进去RTC 电池或备份电源的状态会影响 RTC 寄存器的读写行为。当前市面上一部分 RTC 方案支持可充电电池RTC 模块内部会有充电控制和电压检测逻辑。如果电池电压过低或处于未充电状态RTC 的部分寄存区会被置为保护态写入操作可能不生效或者触发异常。在 STM32MP257 上RTC 通常在 VBAT 域供电即使主电源掉电只要 VBAT 有电RTC 仍可维持计时。如果你在调试中发现某一侧写 RTC 没有生效先别怀疑锁机制先用串口或调试器读一下备份域的状态寄存器确认电源状态是否正常。注意RTC 的“实时性”依赖稳定的 32.768kHz 时钟源和备份电源。多核对时问题已经够复杂了不要再叠加一个电池电压不稳的问题。调试前先确认 VBAT 供电正常RTC 走时稳定再谈多核访问仲裁。5.4 建议的调试工具与手段最后说说调试工具这些在排查这类问题时非常实用JTAG/SWD Trace32 或者劳特巴赫调试器可以同时挂载到 A35 和 M33 两个核心上实时查看 RTC 寄存器值和 RESMGR 锁状态。这个是最直观的不用对着日志猜。Linux 侧 dmesg devmem2 或 busybox devmem可以快速读 RTC 寄存器确认 A35 侧的访问是否真实发生。M33 侧裸机串口日志打印每次读取的 RTC 时间配合 A35 侧的操作时间做对比。逻辑分析仪如果 RTC 的外部时钟源是可观测的用逻辑分析仪抓 32.768kHz 波形能发现时钟源被重新配置的异常。用 devmem2 检查 RTC 寄存器的方式我贴一下方便你直接照抄# 查看 RTC 控制寄存器确认配置状态 devmem2 0x5C002000 # 查看 RTC 当前秒计数寄存器 devmem2 0x5C002010注意STM32MP257 的 RTC 寄存器基地址需要查具体芯片参考手册确认我这里用的是示意地址实际调试以手册为准。6. 写在最后这一课让我重新理解了资源锁的边界这次调完问题我最大的感受是在异构多核系统里任何软件锁都不能替代硬件隔离也不能外推其语义。RESMGR 的RESMGR_RTC_INIT_RSC锁在它自己的设计范围内是有效的但你不能要求它去管本来不属于它管的事。搞清楚每个机制的确切边界比什么都重要。另外一点多核外设访问仲裁一定要从项目一开始就设计好不要等两边都写起来了再去打补丁。至少要把“谁初始化”“谁有权写”“谁只读”“如何通信”这几件事定清楚。如果你的应用是 A35 和 M33 都频繁操作 RTC我建议优先考虑 IPC 方案让 M33 或 A35 作为唯一的时间写入口不要在两侧都放开写权限。最后分享一个小技巧如果你不确定某个 RESMGR 锁到底覆盖哪些操作最快的办法是翻 SDK 里对应的资源管理器源码搜索这个资源标识符在哪些地方被检查过。如果代码里根本没有在set_time路径上检查锁状态那就说明这把锁管不了你关心的事。实测下来这比反复读手册猜语义要高效得多。