K3 平台开发问题反馈（AMP 双内核项目）
2026-09-04。数据出处：《K3 IPC 延迟归因与优化总结报告》（2026-08-23，本分区）、 载板原理图 k3-com260_kit_v02、COM260 Kit 真板实测。
背景：本项目基于 COM260 Kit 载板（V2.0）构建异构 AMP 系统：AP 侧运行 Linux 兼容内核，RP 侧（rcpu1，RT24）运行自研 Rust 异步 RTOS，两核经共享 SRAM 窗口与 mailbox 中断协作。跨核 RPC 往返延迟实测 p50 约 256 µs（门铃唤醒路径，256 字节 消息）。以下问题希望能获得确认或建议。
问题一：40pin 扩展口仅引出一路 R_UART，且该路 3.3V 侧无上拉
现状（经原理图 k3-com260_kit_v02 与 esos 官方 com260_ifx 板级 dtsi 核对）：
- 40pin 上仅 R_UART0 一路可用（pin29/pin32，来自 1.8V 域 pad GPIO_122/123 的 MUX_MODE4，经 BTRD04A02 四通道双向电平转换器引出）。RP 侧时钟控制器可见 UART0–5 共六路的末端时钟控制，其余各路未见引出（R_UART4 可经 M.2 A 槽引出， 但与多槽 PCIe 信号共线）。多串口需求试过两条路都不通：GPIO 软串口的位时序 定拍要过跨域桥（每拍约 13.4 µs，超过 115200 的位宽 8.68 µs）；借用 AP 域 UART 寄存器发送可行（TX 轮询），但这些 UART 的中断只进 AP 侧 APLIC，RT24 收不到，RX 用不了。
- 该网络的上拉位于 pad 内部 1.8V 侧，经双向电平转换器后在 3.3V 侧呈弱驱动/ 高阻，且 3.3V 侧无独立上拉电阻：网络悬空时电平浮空或为低。UART 空闲电平 须为高，因此 RX 仅在对端 TX 处于推挽驱动状态时才能正常工作。实测表现： 高阻逻辑分析仪采不到波形；部分 USB 转串口适配器（TX 发送间隙三态）连接后 乱码、无法通信。外接 10 kΩ 上拉至 VDD_3V3_SYS 可恢复确定的空闲高电平 （该处置待复测确认）。
- 附带发现一：该网络与 M.2 KEY-E 槽的 SDIO DATA0–3 共用，槽内插卡会与串口 通信冲突。
- 附带发现二：AP 引导过程中会把 RT24 正在使用的 pad 重新配置（实测 pad83 已配成 UART5_TXD，后被改回 i2c3 复用；当时该 i2c 控制器在 AP 设备树中是 disabled，内核也没有 i2c 驱动）。RT 固件只能在每次发送前读回寄存器、发现 被改就写回。
询问：
- 除 R_UART0 外，是否还有其他 R_UART 可经 pinmux 引出至 40pin？烦请提供 40pin 各引脚的完整复用表（信号名与 mux 档位）。本次调试中原理图标列与 实际 mux 值存在偏移（R_UART0 实为 MUX_MODE4 而非 MUX_MODE3），建议同步 修订原理图标注。
- 后续载板版本是否考虑在 3.3V 侧为该网络增加上拉电阻？能否提供 pad 内部 上拉经电平转换器后的官方预期电气参数。
- 能否提供 RCPU 侧权威的中断编号表和寄存器说明（AON 定时器、GPIO 等）？ 手册中断源表的信号名与中断号有 1 起始/0 起始的歧义；R_GPIO 的方向寄存器 是只读状态镜像、置输出要写 GSDR——这些手册里都没写，只能对照第三方源码。
- AP 引导链（BootROM/SPL/U-Boot/内核）中哪些阶段会写 pinmux 寄存器？对 设备树中 disabled 的外设所关联的 pad，能否不施加配置？
- RT24 是否有途径接收 AP 域外设（如 UART）的中断？
问题二：核间通信仅有共享 SRAM + mailbox 一条通路，RP 端 fence 为固定约 2.2 µs 开销
现状：
- 两核间可用的通信机制仅共享 SRAM 窗口（承载消息）加 mailbox 寄存器写 （中断通知）。
- RT24 端跨核数据可见性依赖 fence 指令，实测为固定开销，与访问地址、冷热 状态无关：纯 fence、Acquire 原子读（ld + fence r,rw）、Release 原子写 （fence rw,w + sd）均约 2.2 µs。不使用 fence 的普通读会被前端合并缓冲固定 在旧值上（200 次普通读 0 次读到对端新写入），因此跨核读无法省略 fence。
- 原子指令（AMO）经 Atomics Wrapper 序列化执行，同样约 2.2 µs 一次。共享窗 上没有可用的硬件原子操作，跨核同步只能建立在普通读写加 fence 之上。
- 代价：经去冗余优化后，单条消息 RP 侧热路径仍需约 9–10 次 fence，合计约 20 µs；单次中断通知（fence + mailbox 写）约 3.4 µs。另外，Svpbmt 的 PTE 编码在硅上不生效，共享窗只能由固件将 PMA 属性改为非缓存后访问（否则缓存 一致性不可维护），AP 侧逐字非缓存访问又带来约 19 µs/消息的额外开销 （切换前后 p50 236.9 → 256.2 µs）。
- 计时器方面：mtime 跨时钟域冷读实测 24.5 µs（热读 106 ns，间隔 20 µs 即 触发同步器重锁）。
询问：
- RT24 上 fence/原子操作的约 2.2 µs 固定延迟是否为已知微架构行为？是否有 官方时序参数、配置项，或后续硅片/固件改进计划？
- 是否存在受支持的方式让 RT24 的普通读直接看到对端写入（例如共享窗按设备 属性访问时合并缓冲是否旁路；Svpbmt/PMA 在 RP 侧的支持状态与配置接口）， 从而减少 fence 次数？
- 共享窗上是否有受支持的硬件原子操作，或后续有计划支持？
- mtime 冷读的重锁行为和跨域寄存器访问延迟，是否有官方参数文档？
- 是否有比"共享 SRAM + mailbox 寄存器写"更快或更合适的核间通信硬件（如 专用 doorbell/mailbox 寄存器、RP 可触发的 AP 核间中断通道、硬件队列）， 或官方推荐的低延迟跨核同步模式？