Zephyr RTOS在NXP i.MX 95平台的移植与驱动开发实战指南

1. 项目概述与i.MX 95平台解析

如果你正在寻找一个能够驾驭高性能、异构多核处理器的实时操作系统（RTOS），并且厌倦了在不同硬件平台间移植代码的繁琐，那么Zephyr RTOS与NXP i.MX 95的组合，绝对值得你投入时间深入研究。我最近在i.MX 95 EVK开发板上完整走了一遍Zephyr的移植、构建、部署和驱动开发流程，整个过程既有踩坑的艰辛，也有跑通第一个“Hello World”时的畅快。i.MX 95这颗芯片定位非常清晰，就是为安全、高效、智能的边缘计算而生，它集成了强大的Cortex-A55核心、NPU、GPU以及丰富的安全特性，目标直指汽车电子、工业物联网、医疗设备这些对实时性和可靠性要求严苛的领域。

而Zephyr RTOS，作为Linux基金会旗下的开源项目，其最大的魅力在于它的“一次编写，随处运行”潜力。它通过一套精巧的设备树（DTS）和Kconfig配置系统，将硬件描述、驱动选择、功能裁剪完全解耦。这意味着，为i.MX 95编写的驱动和应用，经过适配后，理论上可以相对平滑地迁移到其他同样支持Zephyr的Arm Cortex-A系列平台上。这种可移植性，对于需要跨平台产品线的团队来说，价值巨大。本文的目的，就是把我在这块板子上从零开始，让Zephyr跑起来，并点亮几个关键外设的实战经验，掰开揉碎了分享给你。无论你是刚接触Zephyr的新手，还是想将现有项目迁移到i.MX 95的资深工程师，相信这些从官方文档到实操落地的细节，都能给你带来直接的帮助。

2. 开发环境搭建与源码获取

动手之前，一个稳定、高效的开发环境是基石。Zephyr的开发主要依赖west这个多仓库管理工具，以及相应的工具链。我的工作环境是Ubuntu 22.04 LTS，以下步骤在全新系统中已验证通过。

2.1 基础依赖安装

首先，我们需要安装一系列基础编译工具和Python依赖。Zephyr的构建系统对Python版本有一定要求，建议使用Python 3.8及以上。

sudo apt update sudo apt install --no-install-recommends git cmake ninja-build gperf \ ccache dfu-util device-tree-compiler wget \ python3-dev python3-pip python3-setuptools python3-tk python3-wheel xz-utils file \ make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1

接下来，安装west工具。我强烈建议使用pip安装在用户目录下，避免与系统包管理器冲突。

pip3 install --user -U west echo 'export PATH=~/.local/bin:"$PATH"' >> ~/.bashrc source ~/.bashrc

安装完成后，可以通过west --version来验证是否安装成功。

2.2 获取Zephyr源码与SDK

Zephyr的源码通过west进行初始化和管理。我们选择一个工作目录，例如~/zephyrproject，然后进行初始化。

cd ~ west init zephyrproject cd zephyrproject west update

这个过程会克隆Zephyr的主仓库以及所有在west.yml中定义的模块（包括SoC支持、硬件抽象层HAL等）。对于i.MX 95，其SoC支持代码位于soc/nxp/imx/imx9/目录下，板级支持包（BSP）则在boards/nxp/imx95_evk/。west update完成后，这些代码就已经在你的本地了。

紧接着，安装Zephyr SDK。SDK中包含了为多种架构（包括Arm Cortex-A）预编译的工具链，这是编译Zephyr应用所必需的。

cd ~ wget https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v0.16.5/zephyr-sdk-0.16.5_linux-x86_64.tar.xz wget -O - https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v0.16.5/sha256.sum | shasum --check --ignore-missing tar xvf zephyr-sdk-0.16.5_linux-x86_64.tar.xz cd zephyr-sdk-0.16.5 ./setup.sh

在运行setup.sh时，它会询问是否将工具链路径添加到用户环境变量中，选择“是”。它会修改~/.zephyrrc文件，后续构建时CMake会自动找到正确的工具链。

2.3 环境变量配置

为了让后续的构建命令更简洁，我们设置两个常用的环境变量。ZEPHYR_BASE指向Zephyr源码根目录，而将工具链路径加入PATH可以确保命令行直接调用。

echo 'export ZEPHYR_BASE=~/zephyrproject/zephyr' >> ~/.bashrc echo 'export PATH=~/zephyr-sdk-0.16.5/arm-zephyr-eabi/bin:"$PATH"' >> ~/.bashrc source ~/.bashrc

至此，你的开发环境就已经准备就绪了。你可以通过west build -h和arm-zephyr-eabi-gcc --version来双重验证环境配置是否正确。一个常见的坑是多个工具链路径冲突，如果遇到编译错误，首先检查PATH环境变量中哪个工具链被优先使用。

3. i.MX 95 EVK硬件连接与软件准备

硬件平台是NXP官方的i.MX 95 EVK评估板。要让板子“说话”，第一步是建立串口通信。板载的调试接口（J31）是一个USB转多路串口的FTDI芯片，连接到电脑后，通常会枚举出4个串口设备。

3.1 串口终端配置

在Linux系统下，插入USB调试线后，使用dmesg | tail或ls /dev/ttyUSB*命令可以查看新增的设备。通常，用于U-Boot和Linux主控台的是第三个串口（例如/dev/ttyUSB2）。这里有个关键细节：这个顺序可能会因为系统已有USB串口设备而变化，所以务必通过dmesg日志确认具体的设备号，而不是想当然地使用ttyUSB2。

我习惯使用minicom作为终端工具，配置如下：

sudo minicom -s

进入配置界面后，选择“Serial port setup”。将串口设备（Serial Device）设置为/dev/ttyUSB2（请根据实际情况修改），波特率（Bps/Par/Bits）设置为115200 8N1（即115200波特，8位数据位，1位停止位，无校验），硬件流控（Hardware Flow Control）和软件流控（Software Flow Control）都设置为“No”。保存为默认配置（Save setup as dfl）后退出。这样，每次打开minicom（sudo minicom）就会自动连接。

注意：在后续操作U-Boot或加载Zephyr时，请确保这个终端窗口保持打开和连接状态，它是我们与开发板交互的唯一窗口。

3.2 准备启动介质（SD卡）

为了运行Zephyr，我们需要一个先导环境。最方便的方法是使用NXP官方提供的“Real-time Edge”软件包预编译的SD卡镜像。这个镜像包含了U-Boot、Linux设备树以及一个最小的根文件系统，更重要的是，它内置了通过U-Boot命令启动和停止Cortex-A核心上RTOS（如Zephyr）的功能。

1. 下载镜像：访问NXP官网的Real-time Edge软件发布页面，找到对应i.MX 95 EVK的最新版本镜像（例如Real-time_Edge_v3.x_IMX95-19X19-LPDDR5-EVK.zip），下载并解压。我们需要的是里面的.wic文件（如nxp-image-real-time-edge-imx95-19x19-lpddr5-evk.rootfs.wic）。
2. 烧录镜像：将一张至少8GB的SD卡插入读卡器并连接到电脑。首先使用lsblk命令确认SD卡在系统中的设备节点（例如/dev/sdb，请务必确认无误，否则可能格式化错误磁盘）。然后使用dd命令进行烧录：

   sudo dd if=./nxp-image-real-time-edge-imx95-19x19-lpddr5-evk.rootfs.wic of=/dev/sdX bs=1M status=progress && sync

   将/dev/sdX替换为你的SD卡设备节点。bs=1M设置块大小以提高速度，status=progress可以显示烧录进度，最后的sync确保所有数据写入磁盘。
3. 配置启动模式：将烧录好的SD卡插入i.MX 95 EVK板的卡槽。找到板上的启动模式开关SW7，将其[1:4]位拨到“1011”（即1、3、4为ON，2为OFF），这表示从SD卡启动。最后，连接12V电源适配器并上电。

如果一切顺利，你将在minicom终端中看到TF-A（Trusted Firmware-A）和U-Boot的启动日志。当出现u-boot=>提示符时，说明U-Boot已启动并等待命令。此时，我们的软件基础环境就搭建完成了。

4. Zephyr应用构建与镜像生成

有了基础环境，我们就可以开始编译自己的Zephyr应用了。我们从最简单的hello_world开始，验证整个工具链和BSP是否工作正常。

4.1 构建第一个应用

进入Zephyr的工作目录，使用west build命令进行构建。-b参数指定目标板，对于i.MX 95 EVK的Cortex-A55核心，板子名称是imx95_evk/mimx9596/a55。-p always确保每次构建前都清除之前的构建缓存。

cd ~/zephyrproject/zephyr west build -p always -b imx95_evk/mimx9596/a55 samples/hello_world/

构建过程会持续几分钟，期间会下载必要的工具链组件（如果第一次构建），并编译Zephyr内核、BSP以及我们的hello_world示例。如果构建成功，你会在build/zephyr/目录下找到两个关键文件：

• zephyr.elf: 包含调试信息的ELF格式文件。
• zephyr.bin: 纯二进制镜像文件，这就是我们需要加载到开发板内存并执行的文件。

4.2 构建系统深度解析：Kconfig与设备树

构建命令背后，Zephyr的构建系统做了大量工作，核心是Kconfig和设备树（DTS）。

Kconfig：负责软件功能的配置。当你执行west build时，系统会读取boards/nxp/imx95_evk/imx95_evk_mimx9596_a55_defconfig这个板级默认配置，以及应用目录下的prj.conf（如果有）。你可以通过menuconfig进行交互式配置：

west build -t menuconfig

在这里，你可以启用或禁用内核特性、驱动、协议栈等。例如，为了使用LPUART驱动，需要确保CONFIG_SERIAL=y和CONFIG_UART_MCUX_LPUART=y被启用。构建系统会最终生成一个autoconf.h头文件，供源码编译时使用。

设备树（DTS）：负责硬件描述。它以一种与硬件无关的树形结构，描述了SoC上所有外设的寄存器地址、中断号、时钟源、引脚复用等。对于i.MX 95：

• SoC级定义在dts/arm64/nxp/nxp_mimx95_a55.dtsi。
• 板级定义在boards/nxp/imx95_evk/imx95_evk_mimx9596_a55.dts和imx95_evk-pinctrl.dtsi。 构建时，这些.dts和.dtsi文件会被编译成二进制的.dtb文件，并最终链接进Zephyr镜像。设备树是Zephyr驱动模型的基础，驱动通过compatible属性来匹配设备树节点，从而获取硬件资源。

理解这两者，是进行后续驱动开发和定制化移植的关键。一个常见的错误是修改了设备树，但忘记在Kconfig中启用对应的驱动，导致设备无法初始化。

5. 镜像部署与U-Boot启动实战

编译出zephyr.bin后，下一步就是把它弄到板子上跑起来。i.MX 95平台支持异构多核，U-Boot运行在主核（Core0）上，并提供了命令来在其他从核（如Core1）上启动RTOS。

5.1 镜像部署到开发板

我们需要将zephyr.bin文件传输到开发板的内存或存储中。有三种常用方法：

方法一：通过TFTP网络下载（推荐，速度快）这需要你的开发主机和开发板在同一个局域网，并且主机开启了TFTP服务。

1. 在主机上，将zephyr.bin放入TFTP服务器目录（例如/tftpboot）。
2. 在U-Boot命令行中，配置网络（如果尚未配置）：

   u-boot=> setenv ipaddr 192.168.1.100 # 开发板IP u-boot=> setenv serverip 192.168.1.50 # TFTP服务器IP u-boot=> setenv netmask 255.255.255.0

3. 使用tftp命令下载镜像到内存地址0xd0000000（这是一个在Linux内核占用区域之外的安全内存地址）：

   u-boot=> tftp 0xd0000000 zephyr.bin

方法二：通过SD卡加载如果已经按照3.2节准备了SD卡，其第一个分区是FAT格式。你可以将zephyr.bin复制到这个分区。

1. 在Linux主机上，SD卡挂载后，直接复制文件：

   cp zephyr.bin /media/$USER/BOOT/

2. 在U-Boot中，从SD卡加载到内存：

   u-boot=> fatload mmc 1:1 0xd0000000 zephyr.bin

   mmc 1:1表示第一个MMC设备（SD卡）的第一个分区。

方法三：通过串口Ymodem传输（无需网络）当网络和SD卡都不方便时，可以使用串口直接传输，虽然速度较慢。

1. 在U-Boot命令行输入：

   u-boot=> loady 0xd0000000

2. 此时U-Boot进入等待接收状态。在minicom中，按下Ctrl+A，然后按Z调出命令菜单，再按S（Send files），选择传输协议为Ymodem，然后找到并选择本地的zephyr.bin文件，开始传输。

无论哪种方法，目标都是将zephyr.bin加载到内存的指定地址（如0xd0000000）。

5.2 U-Boot启动命令详解

镜像加载到内存后，就可以使用U-Boot命令启动了。i.MX 95的U-Boot支持多核操作。

在从核（Core1）上启动Zephyr这是最常用的场景，让Zephyr作为一个独立的实时任务运行在某个从核上，与主核上的Linux互不干扰。

u-boot=> dcache flush u-boot=> icache flush u-boot=> cpu 1 release 0xd0000000

• dcache flush和icache flush：至关重要。这两个命令用于刷新数据缓存和指令缓存，确保内存中的最新镜像内容被CPU正确读取。如果跳过此步，核心可能会执行到旧的或错误的指令，导致启动失败或运行异常。
• cpu 1 release 0xd0000000：命令cpu用于多核操作。1是核心编号（i.MX 95的Cortex-A55核心编号通常从0开始）。release指令让核心1从内存地址0xd0000000开始执行。执行后，U-Boot命令行会立即返回，核心1开始独立运行Zephyr。

在主核（Core0）上启动Zephyr如果你希望Zephyr独占整个系统（不启动Linux），可以在Core0上启动。但注意，这会使U-Boot退出，无法再使用U-Boot命令行。

u-boot=> dcache flush u-boot=> icache flush u-boot=> go 0xd0000000

go命令会让当前执行流（Core0）跳转到指定地址执行，不会返回。

核心状态管理

• cpu status：查看所有Cortex-A核心的运行状态（running/off）。
• cpu 1 disable：如果核心1正在运行，此命令可以将其关闭（下电）。

执行cpu 1 release后，如果Zephyr镜像和串口配置正确，你应该立即在串口终端中看到Zephyr的启动日志，最后是Hello World! imx95_evk_mimx9596_a55的输出。恭喜你，Zephyr已经在i.MX 95上成功运行了！

6. 关键外设驱动配置与集成指南

让系统跑起来只是第一步，让外设工作起来才是项目落地的关键。i.MX 95的Zephyr BSP已经支持了部分核心外设驱动，其集成方式深刻体现了Zephyr的硬件抽象思想。

6.1 中断控制器：GIC v3

在Armv8-A多核系统中，通用中断控制器（GIC）是所有外设中断的中枢。i.MX 95使用GIC v3。在Zephyr中，其驱动是drivers/interrupt_controller/intc_gicv3.c，通过CONFIG_GIC_V3配置项启用。

设备树配置：在SoC的DTSI文件（nxp_mimx95_a55.dtsi）中，GIC节点已经定义好，包括分发器（Distributor）和重分发器（Redistributor）的寄存器地址。

gic: interrupt-controller@38800000 { compatible = "arm,gic-v3"; reg = <0x38800000 0x10000>, /* GICD */ <0x38880000 0xc0000>; /* GICR */ interrupt-controller; #interrupt-cells = <4>; status = "okay"; };

关键配置项：CONFIG_GIC_SAFE_CONFIG。在异构多核（如Linux + Zephyr）场景下，这个配置必须启用。因为GIC硬件是全局的，如果Linux已经配置了GIC分发器，Zephyr再去重新配置就会导致系统崩溃。启用此选项后，Zephyr驱动在初始化时会检查GICD是否已被配置，如果是则跳过配置步骤，确保与主OS和平共处。

6.2 时钟与引脚控制：SCMI架构

i.MX 95在时钟和引脚复用（IOMUX）管理上引入了一个重要的变化：采用了SCMI（System Control and Management Interface）协议。这是一种基于消息的、操作系统无关的硬件管理框架，通常由一个运行在安全世界（如Trusted Firmware）中的SCMI服务器来管理硬件资源，客户端（如Zephyr）通过邮箱（Mailbox）发送请求。

SCMI时钟驱动： 驱动源码：drivers/clock_control/clock_control_arm_scmi.c，配置项：CONFIG_CLOCK_CONTROL_ARM_SCMI。 设备树中，它作为一个SCMI协议子节点存在：

firmware { scmi { compatible = "arm,scmi"; shmem = <&scmi_shmem0>; // 共享内存区域，用于传递消息 mboxes = <&mu2 0>; // 使用的邮箱单元 mbox-names = "tx"; scmi_clk: protocol@14 { // 时钟协议，ID为0x14 compatible = "arm,scmi-clock"; reg = <0x14>; #clock-cells = <1>; }; }; };

当Zephyr驱动需要获取或设置某个时钟（如IMX_CCM_LPUART1_CLK）时，它会封装一个SCMI消息，通过邮箱发送给服务器，并等待在共享内存中的回复。这对开发者是透明的，你依然像使用传统时钟驱动一样，在设备树中为外设指定时钟源即可。

SCMI引脚控制驱动： 驱动源码：drivers/pinctrl/pinctrl_imx_scmi.c，配置项：CONFIG_PINCTRL_IMX_SCMI。 其设备树节点与时钟类似，也是SCMI的一个子协议：

scmi_iomuxc: protocol@19 { // IOMUX协议，ID为0x19 compatible = "arm,scmi-pinctrl"; reg = <0x19>; pinctrl: pinctrl { compatible = "nxp,imx95-pinctrl", "nxp,imx93-pinctrl"; }; };

引脚复用配置则定义在板级的pinctrl文件中（imx95_evk-pinctrl.dtsi）。以LPUART1为例：

&lpuart1 { status = "okay"; current-speed = <115200>; pinctrl-0 = <&lpuart1_default>; // 引用引脚配置组 pinctrl-names = "default"; }; lpuart1_default: lpuart1_default { group0 { pinmux = <&iomuxc_uart1_rxd_lpuart_rx_lpuart1_rx>, <&iomuxc_uart1_txd_lpuart_tx_lpuart1_tx>; bias-pull-up; slew-rate = "slightly_fast"; drive-strength = "x4"; }; };

pinmux属性引用的两个标识符（如iomuxc_uart1_rxd_lpuart_rx_lpuart1_rx），在HAL层的pinctrl定义文件（mimx9596avzxn-pinctrl.dtsi）中，会被展开为一个包含寄存器地址和复用模式的数组。SCMI驱动会将这些配置信息通过协议发送给服务器，由服务器完成实际的寄存器写入操作。

实操心得：从直接操作CCM和IOMUX寄存器，到通过SCMI协议访问，这对驱动开发者来说是一个范式转变。好处是硬件资源的管理更加统一和安全，但调试时不能直接读取寄存器状态。当串口或I2C不工作时，除了检查设备树节点状态（status = “okay”）和引脚配置，还需要确认SCMI服务器（通常是TF-A）已正确初始化，并且邮箱（MU）通信是正常的。查看Zephyr启动日志中SCMI驱动初始化是否成功，是第一步。

6.3 串口驱动：LPUART

串口是调试和输出的生命线。i.MX 95上的低功耗UART（LPUART）驱动是drivers/serial/uart_mcux_lpuart.c，配置项为CONFIG_UART_MCUX_LPUART。

其设备树节点定义在SoC DTSI中，开发者只需在板级DTS中启用它并指定引脚。上面的6.2节已经展示了完整的LPUART1设备树配置。确保以下几点：

1. status = “okay”;
2. pinctrl-0引用了正确的引脚配置组。
3. 对应的引脚配置组（如lpuart1_default）中，pinmux属性指向的引脚标识符在HAL中正确定义。
4. 在应用的prj.conf中，确保CONFIG_SERIAL=y和CONFIG_UART_MCUX_LPUART=y。

Zephyr启动后，printk或printf的输出默认就会重定向到这个已配置的串口。你可以通过uartshell命令（如果使能了Shell）或编写简单的应用来测试串口收发。

6.4 其他外设驱动概览

除了上述核心驱动，BSP还支持其他常用外设，它们的集成模式类似：

• GPIO：i.MX 95可能使用RGPIO或IGPIO驱动，具体取决于IP版本。在设备树中查找compatible = “nxp,imx-rgpio”或”nxp,imx-gpio”的节点。
• I2C：对于i.MX 95，可能是LPI2C驱动（i2c_mcux_lpi2c.c）。需要正确配置时钟、引脚复用，并在设备树中指定clock-frequency。
• 定时器：用于系统滴答（SysTick）或一般定时操作的GPT或TPM计数器驱动。

为这些外设编写应用时，Zephyr提供了统一的API（如gpio_pin_set、i2c_write），你不需要关心底层是哪个驱动，只需通过device_get_binding(DT_LABEL(DT_NODELABEL(设备别名)))来获取设备实例。这种硬件抽象层（HAL）的设计，极大地提高了代码的可移植性。

7. 调试技巧与常见问题排查实录

移植和开发过程不可能一帆风顺。下面是我在i.MX 95上折腾Zephyr时遇到的一些典型问题及解决方法，希望能帮你少走弯路。

7.1 启动失败与内存地址问题

问题现象：执行cpu 1 release 0xd0000000后，串口无任何输出，或者U-Boot提示错误。

• 排查步骤1：确认镜像加载地址。确保tftp或fatload命令中的加载地址与release或go命令的地址完全一致。使用md命令可以查看内存内容进行校验：u-boot=> md 0xd0000000 10。
• 排查步骤2：检查缓存刷新。务必在跳转前执行dcache flush和icache flush。我遇到过无数次因为忘记刷新缓存，核心执行了旧指令导致莫名其妙崩溃的情况。
• 排查步骤3：确认内存区域可用。地址0xd0000000是一个常用地址，但需确保它不在U-Boot、Linux内核、设备树或RAMdisk的占用范围内。可以查阅U-Boot环境变量bootm_size或Linux内核启动日志来了解内存布局。如果冲突，可以尝试另一个地址，如0xe0000000。
• 排查步骤4：检查Zephyr控制台输出。Zephyr的调试串口可能不是U-Boot使用的那个。确认在Zephyr的板级配置中，CONFIG_UART_CONSOLE指向的是正确的LPUART实例（例如CONFIG_UART_MCUX_LPUART_1）。可以尝试在构建时启用更详细的日志CONFIG_LOG=y和CONFIG_LOG_IMMEDIATE=y。

7.2 外设无法正常工作

问题现象：代码中能获取到设备实例，但GPIO无法控制、I2C通信失败等。

• 排查步骤1：验证设备树。这是最常见的原因。使用west build -t menuconfig后，进入Devicetree选项，可以浏览编译后的设备树。确保目标外设节点的status是“okay”，而不是“disabled”。
• 排查步骤2：检查引脚复用。这是i.MX系列平台的特有关卡。使用west build -t devicetree生成最终的.dtb文件，然后用dtc工具反编译查看：

  dtc -I dtb -O dts build/zephyr/zephyr.dtb > zephyr.dts

  搜索你的外设节点（如&lpi2c1），查看其pinctrl-0属性引用的配置组，并确认该配置组中的pinmux值是否正确指向了物理引脚。一个引脚同时只能有一个功能，需确认没有其他外设（可能在Linux设备树中）冲突占用。
• 排查步骤3：确认时钟。外设总线时钟（如IPG_CLK）和功能时钟必须使能。在i.MX 95的SCMI架构下，时钟请求是通过协议完成的。确保在设备树中，外设节点的clocks属性引用了正确的时钟源（例如<&scmi_clk IMX_CCM_LPI2C1_CLK>）。可以尝试在应用中早期调用clock_control_on来手动打开时钟进行测试。
• 排查步骤4：驱动初始化日志。在prj.conf中提高日志级别CONFIG_LOG_LEVEL_DBG=y，并确保对应驱动（如CONFIG_I2C_LOG_LEVEL_DBG）的调试日志被打开。观察驱动probe函数是否被调用，初始化是否成功。

7.3 多核间资源冲突与同步

问题现象：Zephyr与Linux同时运行时，访问某些共享资源（如GPIO、部分内存区域）导致系统不稳定或崩溃。

• 根本原因：i.MX 95具有资源域控制器（RDC）或类似硬件单元，用于在硬件层面隔离不同核心/OS对资源的访问。如果配置不当，会发生访问违例。
• 解决方案：
  1. 仔细规划资源划分：在系统设计阶段，就明确哪些外设、内存区域分配给Zephyr，哪些给Linux。这通常在系统级的配置文件中定义。
  2. 检查RDC/资源分配配置：在Zephyr的设备树节点中，有时会看到rdc属性（如旧平台），它定义了该外设允许哪些域访问。对于i.MX 95，资源隔离可能由SCMI服务器或更底层的固件管理。你需要参考NXP提供的多核应用笔记，正确配置资源划分表。
  3. 使用核间通信（IPC）：对于必须共享的数据，使用硬件支持的IPC机制，如MU（Message Unit）邮箱、共享内存+信号量等。Zephyr和Linux侧都需要实现对应的驱动和协议。避免直接访问对方控制的外设寄存器。

7.4 性能优化与尺寸裁剪

问题现象：Zephyr镜像过大，或实时性不满足要求。

• 镜像裁剪：Zephyr的模块化特性使得裁剪非常方便。使用west build -t menuconfig，进入Kernel、Device Drivers等子菜单，关闭不需要的功能（如不必要的文件系统、网络协议栈、调试功能）。特别注意CONFIG_SIZE_OPTIMIZATIONS=y可以启用编译器尺寸优化。
• 内存布局调整：在boards/nxp/imx95_evk/imx95_evk_mimx9596_a55.dts中，可以调整Zephyr使用的内存区域（sram0）的起始地址和大小，确保与Linux的内存规划不重叠，且满足应用需求。
• 实时性调优：确保系统时钟滴答（CONFIG_SYS_CLOCK_TICKS_PER_SEC）设置合理（如1000Hz）。对于关键任务，使用优先级高的线程，并考虑使用CONFIG_PREEMPT_ENABLED启用可抢占调度。使用CONFIG_IRQ_OFFLOAD可以将中断处理任务转移到线程中，减少中断延迟。

调试是一个迭代的过程。我的习惯是，遇到问题先抓日志，从Zephyr启动的最早信息看起；然后回归硬件，检查设备树和引脚；最后再审视代码逻辑。耐心和细致的日志是解决嵌入式问题最强大的武器。