PCA9539 RESET 问题取决于 I²C 连接状态 你好 我正在使用 PCA9539 I/O 扩展器，遇到了意外的 RESET 问题，这似乎取决于 I2C 连接状态。 问题如下： 我通过 I²C 通信将 PCA9539 的所有输出端口配置为高电平。 输出引脚按预期保持高电平。 但是，当我移除 SDA/SCL 探头（用于监控 I2C 总线）时，PCA9539 似乎 RESET 了——输出引脚恢复到默认状态。 在此过程中，VCC 保持稳定，持续供电，RESET 引脚通过上拉电阻器保持高电平。 MCU 没有故意发出 RESET 信号或电源重启 其他说明： 在相同的测试条件下，PCA9538 没有出现这个问题。 存在 I2C 上拉电阻。 电源稳定，可与电容解耦。 RESET 引脚在事件期间未显示异常活动。 我怀疑，断开探测器连接时出现故障或启动/停止状态不完整可能会导致 PCA9539 的内部 I2C 状态机进入故障状态，从而导致类似RESET的行为。但是，我没有找到任何文件可以确认 PCA9539 是否可以在不明确 RESET 或重新通电的情况下清除其输出寄存器。 据我所知，就 I2C I/O 扩展器而言，只要有电源供应，无论是否连接了 I2C 探头，它都应保持其配置。您能确认这种理解是否正确吗？ 问题 在任何情况下，PCA9539 可以在没有 RESET 引脚断言或电源循环的情况下 RESET 其输出寄存器或 I2C 逻辑？ 拆除探头期间 SDA/SCL 出现的故障是否会导致设备进入故障状态并丢失其配置的输出？ 既然 PCA9539 和 PCA9538 的功能相似，为什么 PCA9539 会出现这种行为，而 PCA9538 却不会？ 不管 I²C 总线连接如何，只要有电源，I2C I/O 扩展器都应保持其配置，这是否正确？ 如果您对此行为有任何见解或官方文件，我们将不胜感激。 谢谢！

使用 usbdm 对 68HC912B32 编程 我正在尝试对一块装有这种芯片的旧板进行编程，但是对这个微控制器系列来说是全新的，所以不胜感激。 我下载并安装了 USBDM_4_12_1_340_Win.msi Windows 软件，并运行了"USBDM Memory Dump" 应用程序，转储了 68HC912B32 芯片上的闪存（地址范围 0x8000-0xFFFF）。 我还查看了"HCS12 Programmer" 或"Flash programmer" 应用程序，但其下拉菜单列表中没有 MC912B32 芯片。我还用 " Detect Chip " 按钮尝试了 " 设备选择 " 但它无法检测到我的芯片。 我不需要完整的开发环境/集成开发环境，只需要能够转储闪存、更换损坏的微控制器并用转储的程序对新微控制器进行编程。 这个 4 岁的https://community.nxp.com/t5/OSBDM-and-TBDML/program-the-HC12-B-Family-of-MCU/td-p/1324102这个问题很有趣，但并没有提供解决方案。 我的首选操作系统是 Linux 而不是 Windows，因此我非常乐意尝试基于 Linux 的解决方案。 对如何安装一个有效的编程环境有什么想法吗？ 非常感谢 汤姆-克兰 Re: Programming a 68HC912B32 with usbdm 嗨，@pgo、 感谢您的跟进。我取得了一些进展。 Code Warrior 5.2 不支持 68HC912B32 的解决方案是安装 Code Warrior 5.1。这里建议https://community.nxp.com/t5/CodeWarrior-for-MCU/CodeWarrior-Development-Studio-for-HCS12-X-Microcontrollers/m-p/603056。 在 5.1 版中（见所附屏幕截图 Code-warrior2-run-as-administrator-MC68HC912B32+USBDM.jpg），MC68HC912B32 芯片已出现并可以选择。 但是，"连接 "下拉菜单中没有列出 USBDM 或 TBDML 选项。 在重新安装 Code Warrior 5.1 后，我重新安装了 USBDM 及其驱动程序，并将 USBDM 插入电脑。 为了检查 USBDM 未出现在 "代码勇士连接 "菜单中是否是因为 USBDM 不支持 68HC912B32，我尝试选择了 USBDM 支持的其他芯片。 我选择了 MC9S12A128B。 现在 “连接” 菜单增加了 3 个条目：" TBDML ", " HCS 串行监测 " & " USBDM "。请参阅所附屏幕截图 Code-warrior2-MC68HC9S12A128B+USBDM.jpg。 除了尝试修改 USBDM Tcl 代码以支持 68HC912B32 外，是否还有任何其他软件/硬件应用程序或其他选项可与 USBDM pod 一起使用以对该芯片进行编程？ 如果没有，是否有其他支持 S/W 的硬件/软件选项可以让我对 68HC912B32 的闪存进行编程？ 我的板只有用于调试/编程的 6 针 BDM 插槽 —— 所以必须假设制造商最初就是这样编程的，除非它是在焊接之前断路完成的，这似乎不太可能... 谢谢！ 汤姆 Re: Programming a 68HC912B32 with usbdm 嗨，汤姆 很抱歉，我已经无法访问 Codewarrior（或 Windows！），因此无法亲自检查。 当我在恩智浦网站（https://www.nxp.com/products/68HC912B32）上搜索 68HC912B32 时，最终会找到您下载的 Codewarrior 版本，因此这似乎是正确的版本。 我不知道为什么 B32 没有出现。 对不起！ Re: Programming a 68HC912B32 with usbdm 嗨，Pgo、 感谢您的跟进。 我已经部分拆解了之前转储的图像，所以应该可以拼凑出一个 .asm文件放入代码勇士项目中。 我找不到 Codewarrior 第 6 版的下载地址，但还是从https://www.nxp.com/design/design-center/software/development-software/codewarrior-development-tools/codewarrior-legacy/codewarrior-development-studio-for-hcs12x-microcontrollers-classic-ide-v5-2:CW-HCS12X下载了。 链接。 它被列为版本 5.2，重要的是，在 " 支持的设备 " 的 " Expand All " 复选框下列出了 68HC912B32。 安装 + 运行应用程序并检查版本号，显示的是 5.9 而不是 5.2。请参见所附截屏图片。 正在调用 " 启动对话框..." 和 " 创建新项目 " 提供了一个可选择芯片系列的弹出窗口。请参阅所附的截屏图片。 它只列出了 HCS12 & HCS12X 系列。 将这些节目扩展到家庭成员。请参阅所附的截屏图片。不出所料，其中没有 HCS912B32。 是我做错了什么，还是漏掉了什么显而易见的东西？ 非常感谢 汤姆-克兰 Re: Programming a 68HC912B32 with usbdm 嗨，汤姆 很抱歉，USBDM 编程器不太可能适用于对您的芯片进行编程。 正如其他主题所指出的，这需要开发 TCL 脚本来完成基本工作（芯片启动、大量擦除等），并开发目标代码来完成块编程。 这是一项艰巨的工作，而且不能保证这种方法一定有效，因为 USBDM 采用的方法可能与早期的芯片不兼容。 可以使用位于 https://github.com/podonoghue/usbdm-eclipse-makefiles-build 的代表为 Linux 版本 USBDM。 我认为最好的办法是检查 Codewarrior V6（我认为）是否支持该芯片的 TBDML（USBDM 与之兼容）。 我不确定这是否允许独立编程，而不是从源代码进行调试开发。 仅适用于窗口。 再见

使用 HSE 导入 RSA 中间证书的问题 您好， 我们目前在使用 HSE API 导入和验证 RSA 中间证书时遇到一个问题。 在进行必要的修改以支持 RSA 证书后，我们尝试导入中间 RSA 证书，并使用相应的根公钥对其进行验证。然而，尽管尝试了证书结构中 tbsOffset、tbsLen 和 signOffset 值的各种组合，HSE 始终返回响应代码：hse_srv_rsp_verify_failed 我们已经验证了证书和使用的密钥数据，根公钥的配置似乎是正确的。在不同的偏移配置和证书中，问题依然存在。 能否请您帮助我们找出可能出错的地方，或指导我们如何正确理解 RSA 证书结构中的偏移量（尤其是 rsaModulusOffset、rsaExponentOffset、tbsOffset、tbsLen 和 signOffset）？此外，HSE 内部是否有任何具体要求或检查可能导致核查失败？ 我们采用的方法与 hse_certificate.c 中演示的 ECC 证书导入方法（通过 HSE_ImportECCCert）相同。文件，该文件在 HSE FW 版本 HSE_DEMOAPP_S32G3XX_0_2_64_0 中共享。为了供您参考，我们附上了此文件和我们的请求。 如有需要，我们很乐意提供更多详细信息，如证书内容、根公钥和服务描述符配置。 期待您的支持。 Re: Issue with RSA Intermediate Certificate Import using HSE 你好，@Anup97 谢谢您的帖子。 我已经提到它也被张贴在私人文件夹中，让我直接在那里回复你，因为共享文件更方便。 感谢您的理解。 BR 切宁

使用EB配置FS23驱动时报错 您好，我在配置FS2303驱动时，EB出现如图一的错误提示。但是我在图二的地方已经添加了相关通知函数。同时图三提示的错误也不知道怎样产生的。我使用的是 Autosar4.4   版本2.0的S32K3 mcal驱动和Autosar4.7 版本1.0的FS23 MCAL驱动。我想请问一下上述问题是两个版本不兼容导致的问题吗？ Re: 使用EB配置FS23驱动时报错 好的，谢谢您的回复 Re: 使用EB配置FS23驱动时报错 嗨@夏超 从release note里面来看，你所使用的版本确实是不兼容的。 FS23 SBC AUTOSAR R21-11 版本 1.0.0 FS23 SBC Autosar 4.4 版本 0.8.0

TEA2017 27-30V 550W Design, PFC Mosfet rapidly getting hot with DCM/QR/CCM Mode. Howdy. I'm working with a client project, 27-30V, 550W designed using TEA2017 PFC and LLC. Now originally we were using Fixed Freq 55khz for PFC and the mosfets temps were hotter than usual but still controllable via heatsinks, but now we are trying to make our PFC more efficient. Hence utilizing DCM/QR/CCM mode. Unfortunately in our design in DCM/QR/CCM mode the mosfets rapidly goes up to the failure Temps.  things we have tried but didn't work: 1: Using transistors for gate drivers to drive the pfc gate hard 2: Confirming Our switching is happening after rigning period and when the DrainPFC was falling. 3. Disabling LLC and connect load directly to Vboost to test/tune PFC (result: tea didn't switch pfc the Vboost stayed at 327V (SNSBoost at 2V)) We haven't changed much with our design or TEA settings, as we are trying to test DCM/QR/CCM. Any help/clue int he right direction will be very helpful. I have posted the PFC part of the schematic, and CONFIG_D is what we use. Re: TEA2017 27-30V 550W Design, PFC Mosfet rapidly getting hot with DCM/QR/CCM Mode. HI  1: You should confirm which component getting hot the inductor or others,then provide the heat dissipation solution. 2: You can also configure the circuit as attached excel calculate sheet then update your schematic.

"S32G2 定制硬件上的同步中止" 处理器，esr 0x96000210 - 访问 LPDDR4 时崩溃 亲爱的社区成员 我们在基于 S32G274 的硬件上遇到了启动问题，引导加载程序因数据中止异常而失败。 设置详情： 启动方法：QSP I 图像带集成 ramdisk 的定制 FIP 映像 闪存方法：S32DS 闪存工具和 Lauterbach（两种方法都会出现问题） 电路板支持包。 版本：43.0 启动加载程序： U-Boot 2022.04+gc01b3bf7b1+p0 SoC：S32G274A 我们能够配置 DDR 并能够启动直到 uboot 提示为止。但是在那之后访问DDR时崩溃， ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 请查找以下详细信息以供参考。 => md 80000000 1000 " Synchronous Abort" handler, esr 0x96000210 elr：00000000ff91cb68 lr : 00000000ff91cab8 (reloc) elr：00000000ff91cb68 LR : 00000000ff91cab8 x0 : 0000000000000009 x1 : 00000000ffbc66e8 x2 : 00000000fffffe x3 : 000000000020 x4 : 000000000000 x5 : 00000000ffbc66e0 x6 ：000000000030 x7 : 00000000ffbc6630 x8 : 000000000010 x9 : 0000000000000002 x10: 00000000ffffffd8 x11: 000000000010 x12: 000000000001 x13: 000000000001 x14：000000000030 x15: 000000000021 x16: 00000000ff8af778 x17: 000000000000 x18: 00000000ffbcfd80 x19: 0000000000000004 x20: 0000000000000004 x21: 0000000000000004 x22：0000000080000000 X23: 00000000ffbc66e9 X24: 000000000000 X25: 00000000ffbc6698 X26: 00000000ff9398a7 X27: 0000000000000008 X28: 0000000000000004 X29: 00000000ffbc6630 代码：2a0403f3 17ffffcb 7100129f 54000181 (b94002c3) RESET CPU... 正在重置... 注意：RESET 状态：上电复位 注意：BL2：v2.10.7（版本）：bsp43.0-2.10.7-dirty 注意：BL2：版本：2024 年 11 月 26 日 08:17:37 注意：BL2：正在启动 BL31 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- ----------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ U-启动 2022.04+gc01b3bf7b1+p0(Nov 21 2024 - 14:00:36 +0000) SoC：NXP S32G274A rev.2.1 CPU：Arm Cortex-A53 r0p4 @ 最大 1000 MHz 型号：S32G2-平台 动态随机存取存储器(DRAM)：4 GiB 内部 dm_init_and_scan............ pfeng_mdio mdio@2：EMAC MDIO ID 超出范围 88Q5152 RESET 核心：291 个设备，24 个 uclasses，devicetree：板 MMC：FSL_SDHC：0 从 SPIFlash 加载环境... SF：检测到页面大小为 256 字节的 mt35xu01gbba，擦除大小为 4 KiB，总计 128 MiB *** 警告 - CRC 错误，使用默认环境 s32cc_serdes_phy serdes @40480000：对 SerDes 子系统使用模式 0 pci_s32cc pcie @40400000：DBI 未启用 pci_s32cc pcie @40400000：无法设置 PCI 设备和供应商 ID pcie_s32cc pcie @40400000：DBI R/W 未启用 s32cc_serdes_phy serdes @40480000：无法锁定 PCIe phy s 32cc pcie cc_serdes_phy serdes @40480000：PHY：无法开机 @40480000: -110。 pci_s32cc pcie @40400000：无法开启 PHY 'serdes_lane0' pc i_s32cc pcie @40400000：无法设置 PCIe 主机设置 输入：串行 @401c8000 输 出：串行 @401c8000 错误：串行 @401c8000 主 板版本：RDB2 网络： 找到 PFE 版本 0x50300 (S32G2) pfeng pfeng-base：上传类固件 pfeng pfeng-base：EMAC0 区块已初始化 pfeng pfeng-base：EMAC1 区块已初始化 pfeng pfeng-base：EMAC2 区块已初始化 pfen g pfeng-base：启用 CLASS 区块 pfen g pfeng-base：PFE 平台已启动 成功（掩码：7） pfeng_netif pfe0：无法获取 “emac0_xpcs” PHY eth1：pfe0pfeng_netif pfe1：无法获取 “emac1_xpcs” PHY，eth2：pfe 1，eth3：pfe2 按任意键停止自动启动：0 切换到分区 #0，好的 mmc0（第 0 部分）是当前设备 ** 没有分区表-mmc 0 ** 找不到分区 mmc 0:2 无法设置区块设备 mcr=cc000f03 ip cr=3400000f flashcr=3030100 buf0cr=3f000000 buf1cr=3f000000 buf2cr=3f000000 buf3cr=80000 bufgencr=e00000 buf0ind=0 buf1ind=0 buf1ind=0 buf1ind=0 buf1ind=0 buf1cr=0 buf1ind=0 buf1cr=0 buf1ind=0 buf1 cr=0 buf1ind=0 buf2ind=0 awrcr=0 dllcra=d 0080c2 par itycr=0 sf ar=2c03 sfacr=0 spr=33 rbsr=0 rbct=1f000000 awrsr=0 dllsr=0 dllsr=0 dllsr=0 dllsr=0 dllsr=0 dllsr=f4c0000 dlcr=ff40ff40 dlsr_fa=0 tbdr=0 tbct=0 sr=0 380002 fr=1000009 rser=0 sptrclr=0 dlpr=433455aa = > 运行 flashboot 从闪存启动... 在偏移量 0x00000000 处读取 17629184 字节 " 错误 " 处理器，esr 0xbf000002 elr：00000000f8f5f6c lr：00000000f8f5e68 (reloc) elr：00000000f8f5f6c lr：00000000000000 x1：000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:00000000000ba0 x3:0000000000003f x4:0000000000000002 x5:000000001fe00411 x6:0000000000000000 x7:00000000000011 x8:000000000000000011 x8:0000000000000008 x10:00000000000002 x11:000000001fe00000 x12 : 00000000000001 x13:0000000000003f x 14:00000000000000 x15:00000000000021 x 16:000000000000001 x17:0000000000000000 x18:000000000000000000 x 18:0000000000bcfd80 x19:0000000000000000000 x21:00000000002b0000 x22:0000000000002b0000 x22:0000000000002b0000 x22:0000000000002b0000 x22:00000000002b0000 x22:0000000000002b0000 x22:0000000000002b0000 x22: x23:00000000007d2dc2 x24:00000000000007 x25:00000000000000 x26:00000000000001 x27:00000000000001 x27:00000000000001 x28:00000000010d0000 x29:00000000ffbc6130 代码：d1000694 380016c0 17fffbd f8606aa1 (f8206ac1) RESET CPU... 正在删除使用次数 1 的 MTD 设备 #5（内核）删除分区时 出错 " 内核 " (-16) 正在 RESET... 注意：RESET 状态：破坏性 RESET（运行） 通知：BL2：v2.10.7（版本）：bsp43.0-2.10.7-dirty 注意：BL2：版本：2024 年 11 月 26 日 08:17:37 注意：BL2：正在启动 BL31 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 我们希望得到任何指导或建议来帮助解决这个问题。 敬上， Vishal G Re: "Synchronous Abort" handler, esr 0x96000210 on S32G2 Custom HW - Crash while access to 你好，@vishalg 感谢您的回复。 日志显示"Internal error: synchronous external abort" ，这表明在访问某些地址时发生了异常，可能与访问未映射内存或权限不一致有关。 不确定您是否修改了 GIC 部分的默认 dts？您是否检查了 gic_iterate_rdists 中使用的内存？ BR 切宁 Re: "Synchronous Abort" handler, esr 0x96000210 on S32G2 Custom HW - Crash while access to Hi Chenyin, 感谢您的快速回复。 我能够通过使用 S32 Design Studio 执行 DDR 验证测试并使用重新生成的配置正确配置 DDR 来解决这个问题。 现在我能够成功地启动 uboot 进入内核，我在启动时观察到内核崩溃，这是由 " 内部错误触发的：在运行 Linux 6.6.52-rt43 的自定义 S32G274A 平台上初始化 GICv3 中断控制器时发生的内部错误：同步外部中止 "。 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 注意：RESET状态：上电复位 注意：BL2：v2.10.7(版本)：bsp43.0-2.10.7-dirty 注意：BL2：版本：2024 年 11 月 26 日 08:17:37 注意：BL2：正在启动 BL31 U-启动 2022.04+gc01b3bf7b1+p0(Nov 21 2024 - 14:00:36 +0000) SoC：NXP S32G274A rev.2.1 CPU: Arm Cortex-A53 r0p4 @ 最大 1000 MHz 型号: S32G2-平台 动态随机存取存储器(DRAM): 3.5 GiB 内部 dm_init_and_scan............ pfeng_mdio mdio@2: EMAC MDIO ID 超出范围 88Q5152 RESET 核心: 291 个设备, 24 个 uclasses, devicetree: 板 MMC: FSL_SDHC: 0 从 SPIFlash 加载环境... SF: 检测到页面大小为 256 字节的 mt35xu01gbba, 擦除大小为 4 KiB, 总计 128 MiB *** 警告 - CRC 错误, 使用默认环境 s32cc_serdes_phy serdes @40480000：对 SerDes 子系统使用模式 0 pci_s32cc pcie @40400000：DBI 未启用 pci_s32cc pcie @40400000：无法设置 PCI 设备和供应商 ID pcie_s32cc pcie @40400000：DBI R/W 未启用 s32cc_serdes_phy serdes @40480000：无法锁定 PCIe phy s 32cc pcie cc_serdes_phy serdes @40480000：PHY：无法开机 @40480000: -110。 pci_s32cc pcie @40400000：无法开启 PHY 'serdes_lane0' pc i_s32cc pcie @40400000：无法设置 PCIe 主机设置 输入：串行 @401c8000 输 出：串行 @401c8000 错误：串行 @401c8000 主 板版本：RDB2 网络： 找到 PFE 版本 0x50300 (S32G2) pfeng pfeng-base：上传类固件 pfeng pfeng-base：EMAC0 区块已初始化 pfeng pfeng-base：EMAC1 区块已初始化 pfeng pfeng-base：EMAC2 区块已初始化 pfen g pfeng-base：启用 CLASS 区块 pfen g pfeng-base：PFE 平台已启动 成功（掩码：7） pfeng_netif pfe0：无法获取 “emac0_xpcs” PHY eth1：pfe0pfeng_netif pfe1：无法获取 “emac1_xpcs” PHY，eth2：pfe 1，eth3：pfe2 按任意键停止自动启动：0 切换到分区 #0，好的 mmc0（第 0 部分）是当前设备 ** 没有分区表-mmc 0 ** 找不到分区 mmc 0:2 无法设置区块设备 mcr=cc000f03 ip cr=3400000f flashcr=3030100 buf0cr=3f000000 buf1cr=3f000000 buf2cr=3f000000 buf3cr=80000 bufgencr=e00000 buf0ind=0 buf1ind=0 buf1ind=0 buf1ind=0 buf1ind=0 buf1cr=0 buf1ind=0 buf1cr=0 buf1ind=0 buf1 cr=0 buf1ind=0 buf2ind=0 awrcr=0 dllcra=d 0080c2 par itycr=0 sf ar=2c03 sfacr=0 spr=33 rbsr=0 rbct=1f000000 awrsr=0 dllsr=0 dllsr=15c0000 dlcr=ff40ff40 dlsr=0 tbdr=0 tbct=0 sr=0 sr=0 sr=0 sr=0 sr=0 sr=0 sr=0 0002 fr=1000009 rser=0 sptrclr=0 dlpr=433455aa = > 运行 flash boot 从闪存启动... 在偏移量 0x00000000 处读取 17629184 字节在偏移量 0x00000000 处 读取 196608 字节在偏移量 0x00000000 处 读取 32571392 字节 ## Loading init Ramdisk from Legacy Image at 90000000 ... Image Name: fsl-image-base-s32g2-platfo Image Type: AArch64 Linux RAMDisk Image (uncompressed) Data Size: 29917545 Bytes = 28.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## 扁平化设备树 blob 在 0x83000000 处使用 fdt blob 启动使用设备树位于 00000083000000，结尾 000000830120ae 正在启动内核... 无法选择模式：-70 device_remove：设备 '[email protected]'无法删除，但是孩子们不见了 [0.000000] 在物理 CPU 上启动 Linux 0x0000000000 [0x410fd034] [0.000000] Linux 版本 6.6.52-rt43-g1a29a32be610-dirty (oe-user@oe-host) (aarch64-fsl-linux-gcc (GCC) 11.4.0、GNU ld (GNU Binutils) 2.38.20220708) #1 SMP PREEMPT_RT Thu Nov 21 09:35:09 UTC 2024 [ 0.000000] Machine model: s32g274 Platform [ 0.000000] earlycon: linflex0 at MMIO 0x00000000401c8000 (options '') [ 0.000000] printk: legacy bootconsole [linflex0] enabled [ 0.000000] OF: reserved mem：0x0000000034000000..0x000000003407ffff (512 KiB) nomap non-reusable pfebufs@34000000 [ 0.0000000000] OF: reserved mem：0x0000000034080000..0x000000003409ffff (128 KiB) nomap non-reusable pfebufs@34080000 [ 0.000000] Reserved memory: created DMA memory pool at 0x0000000083200000, size 3 MiB [ 0.000000] OF: reserved mem: initialized node pfebufs@83200000, compatible id shared-dma-pool [ 0.000000] OF: reserved mem：0x0000000083200000..0x00000000835dffff (3968 KiB) nomap non-reusable pfebufs@83200000 [ 0.0000000000] OF: reserved mem：0x00000000835e0000..0x00000000835fffff (128 KiB) map non-reusable pfebufs@835e0000 [ 0.000000] OF: reserved mem：0x0000000084000000..0x0000000084ffff (16384 KiB) nomap non-reusable shm@84000000 [ 0.0000000000] OF: reserved mem：0x00000000c0000000..0x00000000c03fffff (4096 KiB) nomap non-reusable shm@c0000000 [ 0.0000000000] OF: reserved mem：0x00000000c0400000..0x00000000c07fffff (4096 KiB) nomap non-reusable shm@c0400000 [ 0.000000] OF: reserved mem：0x00000000d0000000..0x00000000d000007f (0 KiB) nomap non-reusable shm@d0000000 [ 0.0000000000] OF: reserved mem： 0x00000000d0000080..0x00000000d00000ff (0 KiB) nomap non-reusable shm@d0000080 [ 0.000000] OF: reserved mem：0x00000000ff600000..0x00000000ff7fffff (2048 KiB) nomap non-reusable atf@ff600000 [ 0.000000] 区域范围： [ 0.000000] DMA [mem 0x0000000080000000-0x00000000ffffffff] [ 0.000000] DMA32 空 [ 0.000000] 正常 [mem 0x0000000100000000-0x00000008dffffffffffff] [ 0.000000] 每个节点的可移动区域起点 [ 0.000000] 早期内存节点范围 [ 0.000000] 节点 0: [mem 0x0000000080000000-0x00000000831fffff] [ 0.000000] 节点 0: [mem 0x0000000083200000-0x00000000835dffff] [ 0.000000] 节点 0： [mem 0x00000000835e0000-0x0000000083ffffff] [ 0.000000] 节点 0： [mem 0x0000000084000000-0x0000000084ffffff] [ 0.000000] 节点 0： [mem 0x0000000085000000-0x00000000bffffffff] [ 0.000000] 节点 0： [mem 0x00000000c0000000-0x00000000c07ffffff] [ 0.000000] 节点 0： [mem 0x00000000c0800000-0x00000000cfffffff] [ 0.000000] 节点 0： [mem 0x00000000d0001000-0x00000000ff5fffff] [ 0.000000] 节点 0： [mem 0x00000000ff600000-0x00000000ff7fffff] [ 0.000000] node 0: [mem 0x00000000ff800000-0x00000000ffffffff] [ 0.000000] node 0: [mem 0x0000000880000000-0x00000008dffffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000008dffffffff] [ 0.000000] On node 0, zone DMA: 1 pages in unavailable ranges [ 0.000000] cma：在 0x00000000ef600000 保留 256 MiB on node -1 [ 0.000000] psci: probing for conduit method from DT. [ 0.000000] psci：固件中检测到 PSCIv1.1。 [ 0.000000] psci：使用标准 PSCI v0.2 功能 ID [ 0.000000] psci：不支持 MIGRATE_INFO_TYPE。 [0.000000] psci：SMC 通话约定 v1.4 [0.000000] percpu：嵌入式 20 页/CPU s42112 r8192 d31616 u81920 [0.000000] pcpu-alloc：s42112 r8192 r8192 d31616 u8192 d31616 u8192 d31616 u81920 alloc=20*4096 [0.000000] pcpu-alloc：[0] 0 [0] 1 [0] 1 [0] 2 [0] 3 [0.000000] 在 CPU0 上检测到 VIPT i-Cache [0.000000] CPU 功能：已检测：GIC 系统寄存器 CPU 接口 [0.000000] CPU 功能：已检测：ARM erratum 845719 [0.000000] CPU 功能：已检测：恩智浦勘误表 ERR050481（VA 的 TLBI 处理不正确） [0.000000] CPU 功能：已检测：ARM 勘误表 1165522、1319367、1530923 或 1530924 [0.000000] 备选方案：应用启动替代方案 [0.000000] 内核命令行：console=ttylf0,115200 root=/dev/ram rw earlycon [0.000000] Dentry 缓存哈希表条目：524288（顺序：10，4194304 字节，线性）[0.000000]] inode-Cache 哈希表条目：262144（顺序：9，2097152 字节，线性） [0.000000] 内建 1 个区域列表，移动分组开启。 总页数：903167 [ 0.000000] Mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] software IO TLB: area num 4. [ 0.000000] software IO TLB: mapped [mem 0x00000000eb600000-0x00000000ef600000] (64MB) [ 0.000000] Memory：3194416K/3670012K 可用 (9856K 内核代码, 686K rwdata, 3012K rodata, 1856K init, 245K bss, 213452K reserved, 262144K cma-reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] RCU：可抢占式分层 RCU 实现。 [ 0.000000] RCU：已启用 RCU 事件跟踪。 [ 0.000000] RCU：RCU 限制 CPU 从 NR_CPUS=8 到 nr_cpu_ids=4。 [ 0.000000] RCU：RCU 优先级提升：优先级 1 延迟 500 毫秒。 [ 0.000000] rcu：RCU_SOFTIRQ 处理移至 rcuc kthreads。 [ 0.000000] 没有加速宽限期（rcu_normal_after_boot）。 [ 0.000000] 启用任务 RCU 的蹦床变体。 [ 0.000000] 启用任务 RCU 的跟踪变量。 [ 0.000000] RCU：RCU 计算出的调度程序启动延迟值为 100 jiffies。 [ 0.000000] rcu：Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [ 0.000000] NR_IRQS：64, nr_irqs: 64, preallocated irqs: 0 [ 0.000000] GICv3: GIC：使用分割 EOI/Deactivate 模式 [ 0.000000] GICv3：实现 544 个 SPI [ 0.000000] GICv3：实现 0 个扩展 SPI [ 0.000000] GICv3：MBI 范围 [167:182] [ 0.000000] GICv3：使用 MBI 帧 0x0000000050800000 [ 0.000000] 根 IRQ 处理程序：gic_handle_irq [ 0.000000] 内部错误：同步外部中止：0000000096000010 [#1] PREEMPT_RT SMP [ 0.000000] 链接到的模块： [ 0.000000] CPU：0 PID: 0 Comm: swapper/0 Not tainted 6.6.52-rt43-g1a29a32be610-dirty#1 [ 0.000000] Hardware name: s32g274 Platform (DT) [ 0.000000] pstate：600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : gic_iterate_rdists+0x4c/0x114 [ 0.000000] lr : gic_init_bases+0x198/0x664 [ 0.000000] sp : ffffffc080e83b80 [ 0.000000] x29: ffffffc080e83b80 x28: 0000000080ca6074 x27: 000000000000 [ 0.000000] x26: 000000000000 x25: ffffffc080e8c208 x24: 000000000018 [ 0.000000] x23： 000000000000ffe8 x22： 000000000000 x21： ffffffc08040ed84 [ 0.000000] x20： ffffffc0809f9b60 x19： ffffffc081000000 x18： 0000000000000030 [ 0.000000] x17: 6a20303031207369 x16: 2079616c65642074 x15: ffffffffffff1660 [ 0.000000] x14: 000000000000 x13: 7172695f656c646e x12: 61685f636967203a [ 0.000000] x11 : ffffffffff0000 x10 : 000000000000000a x9 : ffffffc080e9aa78 [ 0.000000] x8 : 00000000fffff7ff x7 : ffffffc080ec6a78 x6 : 00000000004d [ 0.000000] x5 : ffffff885f8479c8 x4 : 000000000000 x3 : 000000000000 [ 0.000000] x2 : 000000000000 x1 : ffffff88000030e0 x0 : ffffffc08100ffe8 [ 0.000000] Call trace: [ 0.000000] gic_iterate_rdists+0x4c/0x114 [ 0.000000] gic_init_bases+0x198/0x664 [ 0.000000] gic_of_init+0x2a8/0x308 [ 0.000000] of_irq_init+0x318/0x3a8 [ 0.000000] irqchip_init+0x18/0x24 [ 0.000000] init_IRQ+0xac/0xc0 [ 0.000000] start_kernel+0x24c/0x5f0 [ 0.］ __primary_switched+0xb4/0xbc [ 0.000000] 代码：d29ffd17 9b387eda f87a6833 8b170260 (b9400000) [ 0.000000] ---[ 结束跟踪 0000000000000000 ]--- [ 0.000000] 内核恐慌 - 未同步：Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 有什么建议可以解决这个问题？ 问候， Vishal Re: "Synchronous Abort" handler, esr 0x96000210 on S32G2 Custom HW - Crash while access to 你好，@vishalg 谢谢您的帖子。 通常，此类问题是由于访问了保护或未映射的内存（如保留内存）造成的，请问您是否修改了默认 BSP43 的内存映射？添加更多保留地址范围？ 您测试过更多地址吗？还有其他地址范围可以用于加载图像吗？ BR 切宁

uboot 跳转到内核会影响 llce_lin 的输出 你好，恩智浦 我们使用引导加载程序启动 M 核心 + A 内核，M 内核配置了 llce_lin 输出； s32g u-boot 跳转到内核，llce_lin 输出损坏，查询具体代码后找到； u-boot 代码：bootm.c-> announce_and_cleanup ()->cleanup_before_linux (void)-> board_cleanup_before_linux ();-> scmi_reset_agent ()； 我们发现， 由于调用 scmi_reset_agent 函数导致，M 内核配置 lce_lin 停止发送；由于 scmi（系统控制和管理接口）系统控制和管理接口 (SCMI) 是 启动 中的较低级别函数，内核，控制时钟、电源、io、RESET等，其中涉及 s32g 的底层控制逻辑；如何修改或配置为 解决导致 llce_lin 停止的 A-core 初始化问题？ 致以最诚挚的问候 Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 注释掉相应的行只是一种测试，并不是建议的解决问题的方法，因为这可能会影响到多个部分，从而导致像你发现的那样的问题。 我认为还需要进一步分析和测试，为了方便讨论和资源共享，请让我帮助创建一个支持案例来继续提供支持，我会直接通过邮件回复您。 很抱歉给您带来不便。 BR 切宁 Re: uboot jump to kernel affects llce_lin output 嗨，chenyin 我现在有一些关于 S32G 时钟的问题，基本上和图片中的问题类似； 1. tf-a 初始化时钟后 tf-a 不会退出吗？ 2. u-启动 和内核如何初始化或使用时钟，需要与 tf-a 通信？ 3. 你能详细解释一下在 tf-a、u-启动 和内核中是如何使用 clk 的吗？ https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Bootloader-Customzition/tac-p/1771379/emcs_t/S2h8ZW1haWx8bWVudGlvbl9zdWJzY3JpcHRpb258TFBXQUozUkFGRzZFRjl8MTc3MTM3OXxBVF9NRU5USU9OU3xoSw BR. Re: uboot jump to kernel affects llce_lin output 嗨，chenyin 感谢您的回复， 我测试了评论过的 scmi_reset_agent 函数，并确认在 u-启动-> 内核跳转期间 llce_lin 输出正常。 但是，我发现内核启动后有异常，比如无法访问eth0 ping，因为我不确定是否还有其他问题，所以我没有按照这条线索进行调查； 你建议我做这样的调查吗？ BR. Re: uboot jump to kernel affects llce_lin output 从U-Boot到Linux内核的过渡确实会影响外围设备的输出，包括与LLCE-LIN（低延迟通信引擎——本地互连网络）相关的外围设备的输出，尤其是在恩智浦S32G等复杂的嵌入式系统中。 这主要是由于 U-Boot 和 猴子型 Linux 内核管理和初始化硬件资源 的方式不同 。 我们使用引导加载程序启动 M 核心 + A 内核，M 内核配置了 llce_lin 输出；s32g u-boot 跳转到内核，llce_lin 输出损坏，查询... 但是，它们的用途不同，管理方式也大不相同。-> U-boot 设备树用于配置和初始化启动过程中所需的硬件元器件，而 Linux 内核则使用设备树来描述内核启动后的硬件配置 Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 据我了解，U-boot 不会设置时钟，tfa 会在启动期间设置时钟。 对于当前的问题，您是否介意在测试时注释掉源代码中的 scmi_reset_agent，以检查您的测试是否仍然存在问题？ BR 切宁 Re: uboot jump to kernel affects llce_lin output 嗨，nxp 我继续在 u-boot 中追踪代码后发现了以下内容： 调用链：scmi_reset_agent (void)-> devm_scmi_process_msg (dev，& scmi_msg)-> scmi_smccc_process_msg (struct udevice *dev, struct scmi_msg *msg)-> arm_smccc_smc (chan-> func_id, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, &res);-> SMCCC smc 对程序集进行了最后的调用，我不知道相关的细节，那么这部分代码是做什么的？它对 M 核心的运行有何影响，如何才能跳过代码执行的这一部分。 BR. Re: uboot jump to kernel affects llce_lin output 你好，chenyin 请提出一个问题，我们现在按如下方式启动流程 bootloader (M7)-> tf-a (A53)-> u-boot (A53)-> 内核 (A53) 我们已经在引导加载程序中配置了 uart 时钟，tf-a 中没有配置 uart 时钟，也没有在 u-boot 中进行任何修改； u-启动 中会重新配置 uart 模块和时钟吗？ BR. Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 我建议首先尝试检查 TFA 中的 UART 时钟及其来源。 BR 切宁 Re: uboot jump to kernel affects llce_lin output 你好，切尼 我知道现在就是这样运行的。 你还有其他发现吗？ BR. Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 既然你的 tf-a、u-boot 中只保存 ddr、xbar_2x 时钟，你的意思是说 UART 和外围设备 PLL3 的时钟也被禁用并在启动加载程序中设置，而不是在 TF-A 中设置？（在 TFA/uBoot 中，TFA/uBoot 只能从启动加载程序继承时钟设置来驱动 UART？） BR 切宁 Re: uboot jump to kernel affects llce_lin output 你好，陈怡 u-启动 中的 clk 转储如下所示： => clk dump Rate Usecnt Name ------------------------------------------ 40000000 0 |-- fxosc@40050000 51000000 0 |-- firc 32000 0 |-- sirc 20000000 0 |--ftm0_ext 20000000 0 |-- ftm1_ext 125000000 0 |-- gmac0_ext_rx 125000000 0 |-- gmac0_ext_tx 50000000 0 |-- gmac0_rmii_ref 200000000 0 |-- gmac0_ext_ts 100000000 0 |-- serdes_100_ext 125000000 0 |-- serdes_125_ext 125000000 0 |-- serdes0_lane0_ext_cdr 125000000 0 |-- serdes0_lane0_ext_tx 125000000 0 |--serdes0_lane1_ext_cdr 125000000 0 |-- serdes0_lane1_ext_tx 125000000 0 |-- serdes1_lane0_ext_cdr 125000000 0 |-- serdes1_lane0_ext_tx 125000000 0 |-- serdes1_lane1_ext_cdr 125000000 0 |-- serdes1_lane1_ext_tx 1 0 |-- pfe_mac0_rmii 1 0 |-- pfe_mac1_rmii 1 0 |-- pfe_mac2_rmii 1000000000 0 |-- a53 400000000 1 |-- serdes_axi 51000000 1 |-- serdes_aux 133333333 1 |-- serdes_apb 100000000 1 |-- serdes_ref 80000000 0 |-- ftm0_sys 0 0 |-- ftm0_ext 80000000 0 |-- ftm1_sys 0 0 |-- ftm1_ext 133333333 0 |-- flexcan_reg 133333333 0 |-- flexcan_sys 40000000 0 |-- flexcan_can 200000000 0 |-- flexcan_ts 62500000 0 |-- linflex_xbar 125000000 1 |--linflex_lin 0 0 |-- gmac0_ts 125000000 0 |-- gmac0_rx_sgmii 125000000 0 |-- gmac0_tx_sgmii 125000000 1 |-- gmac0_rx_rgmii 125000000 1 |-- gmac0_tx_rgmii 0 0 |-- gmac0_rx_rmii 0 0 |-- gmac0_tx_rmii 0 0 |-- gmac0_rx_mii 0 0 |-- gmac0_tx_mii 400000000 1 |-- gmac0_axi 0 0 |-- spi_reg 0 0 |-- spi_module 133333333 0 |-- qspi_reg 133333333 0 |-- qspi_ahb 266666666 0 |-- qspi_flash2x 133333333 0 |--qspi_flash1x 400000000 0 |-- usdhc_ahb 133333333 0 |-- usdhc_module 400000000 1 |-- usdhc_core 32000 0 |-- usdhc_mod32k 133333333 0 |-- ddr_reg 800000000 0 |-- ddr_pll_ref 800000000 0 |-- ddr_axi 400000000 0 |-- sram_axi 133333333 0 |-- sram_reg 133333333 0 |-- i2c_reg 133333333 0 |-- i2c_module 66666666 0 |--siul2_reg 51000000 0 |-- siul2_filter 133333333 0 |-- crc_reg 133333333 0 |-- crc_module 100000000 0 |-- eim0_reg 100000000 0 |-- eim0_module 66666666 0 |-- eim123_reg 66666666 0 |-- eim123_module 66666666 0 |-- eim_reg 66666666 0 |-- eim_module 66666666 0 |-- fccu_module 51000000 0 |-- fccu_safe 66666666 0 |-- rtc_reg 32000 0 |-- rtc_sirc 51000000 0 |-- rtc_firc 133333333 0 |-- swt_module 51000000 0 |-- swt_counter 133333333 0 |-- stm_module 133333333 0 |-- stm_reg 133333333 0 |-- pit_module 133333333 0 |-- pit_reg 400000000 0 |-- edma_module 400000000 0 |-- edma_ahb 80000000 1 |-- sar_adc_bus 666666660 |-- cmu_module 66666666 0 |-- cmu_reg 133333333 0 |-- tmu_module 133333333 0 |-- tmu_reg 133333333 0 |-- flexray_reg 0 0 |-- flexray_pe 66666666 0 |--wkpu_module 66666666 0 |-- wkpu_reg 66666666 0 |-- src_module 66666666 0 |-- src_reg 66666666 0 |-- src_top_module 66666666 0 |-- src_top_reg 133333333 0 |-- ctu_module 80000000 0 |-- ctu_ctu 200000000 0 |-- dbg_sys4 400000000 0 |-- dbg_sys2 400000000 0 |-- m7 133333333 0 |-- dmamux_module 133333333 0 |-- dmamux_reg 500000000 0 | -- gic_module 133333333 0 | -- mscm_module 133333333 0 | -- mscm_reg 133333333 0 | -- sema42_module 133333333 0 |-- sema42_reg 66666666 0 |-- xrdc_module 66666666 0 |-- xrdc_reg 0 0 |-- clkout0 0 0 |-- clkout1 100000000 0 |-- usb_mem 32000 0 |-- usb_low 0 0 |--pfe0_rx_sgmii 0 0 ||-- pfe0_tx_sgmii 0 0 |-- pfe0_rx_rgmii 0 0 |-- pfe0_tx_rgmii 0 0 |-- pfe0_rx_rmii 0 0 |-- pfe0_tx_rmii 0 0 |-- pfe0_rx_mii 0 0 |--pfe0_tx_mii 0 0 ||-- pfe1_rx_sgmii 0 0 |-- pfe1_tx_sgmii 0 0 |-- pfe1_rx_rgmii 0 0 |-- pfe1_tx_rgmii 0 0 |-- pfe1_rx_rmii 0 0 |-- pfe1_tx_rmii 0 0 |--pfe1_rx_mii 0 0 |-- pfe1_tx_mii 0 0 |-- pfe2_rx_sgmii 0 0 |-- pfe2_tx_sgmii 0 0 |-- pfe2_rx_rgmii 0 0 |-- pfe2_tx_rgmii 0 0 |-- pfe2_rx_rmii 0 0 |-- pfe2_tx_rmii 0 0 |-- pfe2_rx_mii 0 0 |-- pfe2_tx_mii 300000000 0 |-- pfe_axi 300000000 0 |-- pfe_apb 600000000 0 |-- pfe_pe 0 0 |-- pfe_ts 40000000 0 |-- llce_can_pe 200000000 0 |-- llce_sys 80000000 0 `-- llce_per 1000000000 0 |-- a53 400000000 1 |-- serdes_axi 51000000 1 |-- serdes_aux 133333333 1 |-- serdes_apb 100000000 1 |-- serdes_ref 80000000 0 |-- ftm0_sys 0 0 |-- ftm0_ext 80000000 0 |-- ftm1_sys 0 0 |-- ftm1_ext 133333333 0 |--flexcan_reg 133333333 0 |-- flexcan_sys 40000000 0 |-- flexcan_can 200000000 0 |-- flexcan_ts 62500000 0 |-- linflex_xbar 125000000 1 |-- linflex_lin 0 0 |--gmac0_ts 125000000 0 |-- gmac0_rx_sgmii 125000000 0 |-- gmac0_tx_sgmii 125000000 1 |-- gmac0_rx_rgmii 125000000 1 |-- gmac0_tx_rgmii 0 0 |--gmac0_rx_rmii 0 0 |-- gmac0_tx_rmii 0 0 |-- gmac0_rx_mii 0 0 |-- gmac0_tx_mii 400000000 1 |-- gmac0_axi 0 0 |-- spi_reg 0 0 |-- spi_module 133333333 0 |--qspi_reg 133333333 0 |-- qspi_ahb 266666666 0 |-- qspi_flash2x 133333333 0 |-- qspi_flash1x 400000000 0 |-- usdhc_ahb 133333333 0 |-- usdhc_module 400000000 1 |-- usdhc_core 32000 0 |-- usdhc_mod32k 133333333 0 |-- ddr_reg 800000000 0 |-- ddr_pll_ref 800000000 0 |-- ddr_axi 400000000 0 |-- sram_axi 133333333 0 |-- sram_reg 133333333 0 |-- i2c_reg 133333333 0 |-- i2c_module 66666666 0 |-- siul2_reg 51000000 0 |-- siul2_filter 13333333333 0 |--crc_reg 133333333 0 |-- crc_module 100000000 0 |-- eim0_reg 100000000 0 |-- eim0_module 66666666 0 |-- eim123_reg 66666666 0 |-- eim123_module 66666666 0 |--eim_reg 66666666 0 |-- eim_module 66666666 0 |-- fccu_module 51000000 0 |-- fccu_safe 66666666 0 |-- rtc_reg 32000 0 |-- rtc_sirc 51000000 0 |--rtc_firc 133333333 0 |-- swt_module 51000000 0 |-- swt_counter 133333333 0 |-- stm_module 133333333 0 |-- stm_reg 13333333333 0 |-- pit_module 13333333333 0 |--pit_reg 400000000 0 |-- edma_module 400000000 0 |-- edma_ahb 80000000 1 |-- sar_adc_bus 66666666 0 |-- cmu_module 66666666 0 |-- cmu_reg 133333333 0 |-- tmu_module 133333333 0 |-- tmu_reg 133333333 0 |-- flexray_reg 0 0 |-- flexray_pe 66666666 0 |-- wkpu_module 66666666 0 |-- wkpu_reg 66666666 0 |--src_module 66666666 0 |-- src_reg 66666666 0 |-- src_top_module 66666666 0 |-- src_top_reg 133333333 0 |-- ctu_module 80000000 0 |-- ctu_ctu 200000000 0 |-- dbg_sys4 400000000 0 |-- dbg_sys2 400000000 0 |-- m7 133333333 0 |-- dmamux_module 133333333 0 |-- dmamux_reg 500000000 0 |-- gic_module 133333333 0 |-- mscm_module 133333333 0 |-- mscm_reg 133333333 0 |-- sema42_module 133333333 0 |-- sema42_reg 66666666 0 |--xrdc_module 66666666 0 |-- xrdc_reg 0 0 |-- clkout0 0 0 |-- clkout1 100000000 0 |-- usb_mem 32000 0 |-- usb_low 0 0 |-- pfe0_rx_sgmii 0 0 |-- pfe0_tx_sgmii 0 0 |-- pfe0_rx_rgmii 0 0 |-- pfe0_tx_rgmii 0 0 |-- pfe0_rx_rmii 0 0 |-- pfe0_tx_rmii 0 0 |-- pfe0_rx_mii 0 0 |-- pfe0_tx_mii 0 0 |-- pfe1_rx_sgmii 0 0 |-- pfe1_tx_sgmii 0 0 |--pfe1_rx_rgmii 0 0 ||-- pfe1_tx_rgmii 0 0 ||-- pfe1_rx_rmii 0 0 |-- pfe1_tx_rmii 0 0 |-- pfe1_rx_mii 0 0 |-- pfe1_tx_mii 0 0 |-- pfe2_rx_sgmii 0 0 ||-- pfe2_tx_sgmii 0 0 ||-- pfe2_rx_rgmii 0 0 |-- pfe2_tx_rgmii 0 0 |-- pfe2_rx_rmii 0 0 |-- pfe2_tx_rmii 0 0 |-- pfe2_rx_mii 0 0 |-- pfe2_tx_mii 300000000 0 |-- pfe_axi 300000000 0 |-- pfe_apb 600000000 0 |-- pfe_pe 0 0 |-- pfe_ts 40000000 0 |-- llce_can_pe 200000000 0 |-- llce_sys 80000000 0 |-- llce_per Re: uboot jump to kernel affects llce_lin output 嗨，chenyin 1. Lin 时钟在引导加载程序中配置； 2. 我们使用 bsp42，在 tf-a、u-boot 中只保存 ddr、xbar_2x 时钟，所有其他配置都处于关闭状态，具体取决于启动加载程序的配置； BR. Re: uboot jump to kernel affects llce_lin output 你好，@马松 谢谢您的帖子。 1.我想知道 LIN 时钟是在引导加载程序中配置的，还是在 M7 内核上运行的 LIN 应用程序中配置的？ 2。您的测试设置中使用的是哪个版本的电路板支持包？对时钟设置有任何修改吗？你介意分享你的 u-启动 中的时钟转储吗？ BR 切宁

LS1043 GPIO support in Linux SDK This document introduces how to configure RCW to support GPIO on LS1043 platform, how to configure Linux Kernel to load Linux GPIO driver to access GPIO from SYSFS and using loopback method to do verification on the target board. RCW configuration to support GPIO Configure GPIO driver in Linux Kernel Verify GPIO on the target board QorIQ LS1 Devices Re: LS1043 GPIO support in Linux SDK For all those who - like me - were searching for a list to map the individual pins to the GPIO number.. This is the answer I got from NXP Technical Support (thank you, Fedor!): modified table (refer to the QorIQ LS1043A Reference Manual, Table 2-3. CCSR Block Base Address Map): GPIOs 384-415, /soc/gpio@2330000: GPIO4[0-31] GPIOs 416-447, /soc/gpio@2320000: GPIO3[0-31] GPIOs 448-479, /soc/gpio@2310000: GPIO2[0-31] GPIOs 480-511, /soc/gpio@2300000: GPIO1[0-31] even if not all 32 signals are implemented for each GPIOn set, the math is identical - i.e., for GPIO4_03 it is: 384+3=387

Video: Install S32R45 Development Package (view in My Videos)

SCFW: Enable PMIC external watchdog for iMX8QXP MEK Attachched is the reference patch to enable the PMIC external watchdog in SCFW, it is based on SCFW porting kit v1.1.2 from NXP website: https://www.nxp.com/webapp/Download?colCode=L4.14.78_1.0.0_SCFWKIT&appType=license&location=null Please apply the patches to "imx-scfw-porting-kit-1.1.2/src/scfw_export_mx8qx_b0" On iMX8QXP MEK board, the patches will enable the PF8100 watchdog by macro "#define ENABLE_PMIC_EXTERNAL_WDOG", and it will refresh the watchdog timer by I2C interface. The default timeout value is 0xD for 8192ms (#define PMIC_EXTERNAL_WDOG_TIMEOUT  0xD), and SCFW will refresh it with 1000ms period (board_pmic_wdog_refresh_period_ms = 1000U). When the iMX8 system goto low power mode, it will pull SCU_PMIC_STANDBY to notify the PMIC, then PMIC will switch to suspend mode too, during PMIC suspend mode, this watchdog timer is off too. It will restart after PMIC resume to normal mode. Without PMIC OTP burning for WDOG, the current setting of patch will trigger hard reset after PMIC WDOG is timeout. 0001-scfw-add-board-board-tick.patch This patch is used to added polling ticket in board.c, after SCFW running, it will call board_tick() with 10ms period. In future SCFW release, this patch is not needed to apply, it is in default code, only when SCFW porting kit version is 1.1.2 and early version, you need apply this patch. 0002-scfw-enable-pmic-external-wdog.patch This is the reference patch to enable the PF8100 watchdog timer and refresh code. iMX8QXP MEK is used as the example. Note: In default SCFW, it had already used internel watchdog to make sure SCFW is always running, if SCFW is built as no debug version (M=0 D=0), all SCFW halt will cause SOC reset. And if hardware had connected the SCU_WDOG_OUT pin from iMX8QXP to PMIC's WDI pin, then during SOC reset, the PMIC will also do hard reset to make a POR reboot for the whole system. i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus

NET-N1879 5Gの推進:次世代のアクセス技術 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 5G規格が定義される中、高スループット、低遅延、および多数のユーザーが、5Gサービスを推進するための主要な要件の1つです。NXPがこれらの要素をブレンドして、5Gの課題に対処するための最適なハードウェアアーキテクチャを設計している方法をご覧ください。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 5G規格が定義される中、高スループット、低遅延、および多数のユーザーが、5Gサービスを推進するための主要な要件の1つです。NXPがこれらの要素をブレンドして、5Gの課題に対処するための最適なハードウェアアーキテクチャを設計している方法をご覧ください。 スマートネットワーク

如何在imx6Q板上支持字幕 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 当前 imx6 bsp，不仅 ltib 而且 yocto 也无法支持字幕。 现在我们有两种解决方案来支持 Yocto 上的字幕， 1）一种是提取字幕，然后通过UI将字幕绘制在视频上，imxplayer支持这种方式。 此解决方案使用 imxplayer 的 QT，因此如果您构建 yocto，则应选择 QT 作为目标。基本上，aiurdemux 通过 appsink 将文本发送到 QT，然后 QT 在 UI 层上绘制文本。 构建yocot时，请使用以下命令： “bitbake fsl-image-qt5” 将字体库复制到/usr/lib/fonts ，然后在播放 imxplayer 时选择您需要的字体。 2）另一种是通过gstreamer将字幕混合到视频缓冲区，然后与视频一起输出 在 gstreamer1.0-plugins-base 中启用 gst pango lib 更改 playbin 标志以禁用原生视频标志 basetextoverlay 应用补丁http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/ext/pango/gstbasetextoverlay.c?id=267a8c24af4f02ba6f3075bd589d3c5d1dc826e9 使用以下命令行 gst-启动-1.0playbin 标志=0x17 uri=file://$VIDEO_FILE suburi=file://$SUBTITLE_FILE i.MX6 四核

DwF MCUおよびオートモーティブソリューション - Tianan - 2015-03-19 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 自動車およびコネクテッドカー 車載用マイクロコントローラの概要 : KinetisおよびS12 MagniVミックスド・シグナル・マイクロコントローラを含む BCCおよび高圧センサを搭載した車載用アナログおよびセンサの概要 インサイトとイノベーション Kinetisマイクロコントローラの概要 - Kinetisの性能上の利点とアプリケーション 設計、ソフトウェア、サービス フリースケールMQX™ RTOSの概要 ARM®プロセッサ キネティスCortex®-Mマイクロコントローラー センサ ソフトウェアとツール

系统控制器固件 101 - 入门 使用评估套件时，你会获得一个包含在 BSP 中的系统控制器固件 (SCFW) 二进制文件。此 SCFW 二进制文件是为特定开发板量身定制的，你可能需要修改一些板级依赖项以适配你的特定硬件。 本文件旨在提供有关SCFW移植流程的概述，详细信息请参阅《系统控制器移植指南》（sc_fw_port.pdf）。 系统设置 SCFW 是在 Linux 主机上构建的。设置系统的步骤如下： 从 ARM 官网下载 GNU ARM 嵌入式工具链：6-2017-q2-update（2017 年 6 月 28 日版本）： 选择一个目录解压该文件，例如： mkdir ~/gcc_toolchain cp ~/Downloads/gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 ~/gcc_toolchain/ cd ~/gcc_toolchain/ tar xvjf gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 将 TOOLS 环境变量设置为包含工具链的目录，在上面的示例中为 “~/gcc_toolchain”，也可以修改 .bash_profile 来导出此环境变量： export TOOLS=~/gcc_toolchain/ 构建过程还需要 srec_cat，它通常包含在 srecord 包中，在 Ubuntu 上可以执行： sudo apt-get update sudo apt-get install srecord 现在你可以切换到移植工具包目录（例如 scfw_export_mx8qm）并构建 SCFW。 系统控制器固件移植工具包 SCFW移植套件包含源文件和目标文件，这些文件将允许您修改SCFW以使其与您的开发板兼容。 你可以从 i.MX 软件和开发网页获取最新的系统控制器固件移植工具包： 获取移植工具包后，解压它： tar xvzf imx-scfw-porting-kit-1.1.tar.gz‍ 您将看到以下的文件结构： 移植工具包包含在 packages 目录下，README 文件中包含提取移植工具包的说明，主要步骤如下： cd packages/ chmod a+x imx-scfw-porting-kit-1.1.bin ./imx-scfw-porting-kit-1.1.bin‍‍‍ 您将被提示接受最终用户许可协议： 接受协议后，移植工具包将被提取到一个新文件夹中，文件夹结构如下： 所有关于 SCFW 的文档都在 doc/pdf 目录下，也有 html 格式可供选择，建议阅读 sc_fw_port.pdf。 不同 SoC 变体（QM A0、QM B0 和 QXP B0）的移植工具包在 src 目录下，以 tar.gz 格式打包，其他所有文件都是用于不同软件包（如 Linux、QNX、FreeRTOS、U-boot、ARM 可信固件等）的 SCFW 库。 如果你要处理多个 SoC 变体（同时处理 QXP 和 QM），建议将所有移植工具包提取到一个目录中，这样你就可以从该目录为任何变体进行构建，执行以下命令： cd imx-scfw-porting-kit-1.1/ cd src/ find scfw_export_mx8*.gz -exec tar --strip-components 1 --one-top-level=scfw_export_mx8 -xzvf {} \;‍‍‍ 将创建一个 scfw_export_mx8 文件夹，从这里你可以为任何受支持的变体构建 SCFW。或者，你也可以只提取你感兴趣的变体的包并使用它。 cd scfw_export_mx8/‍ 所有构建文件夹都包含 SCFW 的构建结果，而 platform 目录则存储 SCFW 的源代码。 所有特定于开发板配置的代码都在 “platform/board/mx8 _ ” 目录下，其中 derivative 是 i.MX8 芯片系列（如 QXP 或 QM），board name 是 SCFW 包所针对的开发板名称。 将 SCFW 移植到你的开发板的第一步是为你的 i.MX8 衍生产品和开发板创建一个文件夹，你可以选取一个现有的开发板示例并重命名该文件夹，这将为你提供一个入门项目，例如： cp -r platform/board/mx8qm_val/ platform/board/mx8qm_myBoard/‍‍‍‍‍‍‍‍‍‍ 在此示例中，该开发板将被称为 “myBoard”，它适用于 i.MX8QM B0 设备。要为该开发板构建 SCFW，只需执行： make qm R=B0 B=myBoard‍‍‍‍‍‍‍‍‍‍‍‍ 如果目标是 i.MX8QXP，只需选取一个基于该设备的开发板，并将命令改为 “make qx”。 更多信息（如构建选项和详细的启动信息）可以在《SCFW 移植指南》(sc_fw_port.pdf)中找到，该文档的第 2 章是对移植过程的清晰介绍。 概述和有用信息 PMIC 配置概述和 board.c 的常见修改 需要修改的主要文件（如果不是唯一的话）是 “board.c” 文件，它位于 “platform/board/mx8X_board/” 目录下。board.c 文件包含大多数与开发板相关的信息，如 SCU UART 端口、PMIC 初始化程序、PMIC 温度报警设置，你还可以修改它来配置 LDO 电压并与 PMIC 进行总体通信。board.c 文件中的所有函数都由 SCU 本身执行，这使你能够访问用于与 PMIC 通信的 I2C 接口。 由外部电源（例如 PMIC LDO）供电的 SoC 资源（如 AP 内核和 GPU）通过 board_set_power_mode 进行开关，资源到特定 PMIC 电源的映射在 board_get_pmic_info 中进行，例如，在我们的 i.MX8QM 验证板上，使用 A53 子系统由 PF100 PMIC 卡上第三个 PMIC（PMIC_2_ADDR 地址从 PMIC_0 开始）的 SW2 供电，由 PF8100 PMIC 卡上第一个 PMIC (PMIC_0_ADDR) 的 SW5 供电。 case SC_SUBSYS_A53: pmic_init(); if (pmic_card == PF100) { pmic_id[0] = PMIC_2_ADDR; pmic_reg[0] = SW2; *num_regs = 1; } else {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW5; *num_regs = 1; } break; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 由外部电源（AP 内核、GPU 等）供电的 SoC 资源的电压由 board.c 文件中的 board_set_voltage 管理。资源到电源的映射如上面的示例所示，在 board_get_pmic_info 中进行。 有八个 “板载资源” (SC_R_BOARD_R0，... SC_R_BOARD_R7)b 可用，这些资源允许你定义 SCU 可以管理的开发板上的组件，例如，开发板上由某个 PMIC LDO 供电的传感器可以映射到一个板载资源，并且可以修改 board.c 文件来开关该传感器以及修改其电压。 修改板载资源的电压可以通过修改 board_trans_resource_power 处的电压来完成（见下文），或者如果需要在运行时更改电压，可以修改 board_set_control 函数，以便在对该资源进行杂项调用（详见《杂项服务 101》）时更改电压。例如，要更改 SC_R_BOARD_R7 上的电压，你可以在 board_set_control 中使用以下情况： case SC_R_BOARD_R7: if (ctrl == SC_C_VOLTAGE) { /* Example only PMIC_X_ADDR and PMIC_SUPPLY need to match an actual device */ pmic_interface.pmic_set_voltage(PMIC_X_ADDR, PMIC_SUPPLY, val, step); } else return SC_ERR_PARM; break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 每当应用程序调用以下函数时，SCU 将执行上面的代码： sc_misc_set_control( ipc, SC_R_BOARD_R7, SC_C_VOLTAGE, voltage_val);‍‍‍‍‍‍‍‍ 板载资源的开关在 board.c 文件的 board_trans_resource_power 中进行。例如，在 NXP 的验证板上，板上的 PTN5150 通过板载资源 0 进行管理，其开关管理如下： case BRD_R_BOARD_R0 : /* PTN5150 (use SC_R_BOARD_R0) */ if (pmic_ver.device_id == PF100_DEV_ID) { if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_2_ADDR, VGEN6, 3300, SW_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_ON); } else { pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_OFF); } } else {/* PF8100_dual Card */ if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_1_ADDR, PF8100_LDO1, 3300, REG_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_EN_STBY_EN); } else { pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_OFF_STBY_OFF); } } break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 每当从应用程序端调用以下函数时，SCU 将执行上面的代码： sc_pm_set_resource_power_mode(ipc, SC_R_BOARD_R0, SC_PM_PW_MODE_ON/OFF);‍‍‍‍‍‍‍‍ board_config_sc 用于标记 SCU 需要的资源，例如用于与 PMIC 通信的 I2C 模块和焊盘，board.c 函数工作所需的任何资源都应在此函数中标记为不可移动，例如，要保留 SCU I2C 模块，需添加以下行： rm_set_resource_movable(pt_sc, SC_R_SC_I2C, SC_R_SC_I2C, false);‍‍‍‍‍‍‍‍‍ 以下焊盘属于 SCU，应用程序无法访问它们： - SC_P_SCU_PMIC_MEMC_ON - SC_P_SCU_WDOG_OUT - SC_P_PMIC_EARLY_WARNING - SC_P_PMIC_INT_B - SC_P_SCU_BOOT_MODE0 到 SC_P_SCU_BOOT_MODE5 board_system_config 是早期资源管理发生的地方，该函数仅在图像中设置了 alt_config 标志时被调用，并且它可以创建分区并为其分配资源。更多详细信息可在资源管理服务 101 中找到。 board_get_pcie_clk_src 定义了 PCIe 使用的时钟，它可以是 BOARD_PCIE_PLL_EXTERNAL 或 BOARD_PCIE_PLL_INTERNAL。 board_print 对于调试你的更改非常有用，其语法如下： board_print(3, "Debug printout %d\n", val);‍‍‍‍‍‍‍ 其中第一个参数是调试级别，从那里开始它的工作方式与标准 printf 相同。只有当 SCU 是在相应的调试级别下构建时，输出才会在 SCU 调试输出上可见，在上面的示例中，需要按以下方式构建 SCFW 才能看到输出： make qm B=myBoard‍‍‍‍ DL=3 or higher (debug level goes from 0 to 5)‍‍‍‍‍‍‍ 用法示例 以下工具展示了如何发出系统控制器固件请求，并提供了一种通过 QNX 和 Linux 上的命令行界面发出此类请求的方法 适用于 Linux 和 QNX 的系统控制器固件命令行工具 系统控制器固件 101 i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus

LS1043ARDB - How to update DPAA1 FMan microcode (ucode) image on SD card Follow these steps to update the DPAA1 FMan ucode image on the SD card.  Obtaining DPAA1 FMan ucode image Clone the qoriq-fm-ucode repository. $ git clone https://github.com/NXP/qoriq-fm-ucode.git $ cd qoriq-fm-ucode $ git checkout LSDK- . For example, $ git checkout LSDK-19.06 The prebuilt FMan ucode images, fsl_fman_ucode_ls1043_r1.1_ .bin , are at qoriq-fm-ucode/. In the binary file, ls1043_r1.1 refers to the LS1043A silicon revision 1.1. See qoriq-fm-ucode/readme for a description of the ucode version numbers. SD card start block number for DPAA1 FMan ucode image Image  SD card start block number DPAA1 FMan ucode image 0x04800 = 18432 Refer Flash layout for new boot flow with TF-A for complete listing of the SD card start block numbers for all LSDK firmware images. Programming DPAA1 FMan ucode image to SD card Option 1: Load image on SD card plugged into Linux host via dd command Plug the SD card into the Linux host. Run the following command on the Linux host: $ sudo dd if=fsl_fman_ucode_ls1043_r1.1_ .bin  of=/dev/sdX bs=512 seek=18432 conv=fsync Use the command cat /proc/partitions to see a list of devices and their sizes to make sure that the correct device names have been chosen. The SDHC storage drive in the Linux PC is detected as /dev/sdX, where X is a letter such as a, b, c. Make sure to choose the correct device name, because data on this device will be replaced. If your Linux host machine supports read/write SDHC card directly without an extra SDHC card reader device, the device name of SDHC card is typically mmcblk0.                                                   Remove the SD card from the Linux host machine. Plug the SD card into LS1043ARDB and boot the board to Ubuntu using the SD card. You can boot the board using the SD card either by: setting the switches: SW3[1:8] = 10110011, SW4 [1:8] =00100000 , SW5 [1:8] = 00100010, or boot switching to SD card => cpld reset sd In boot log, you’ll see: Board: LS1043ARDB, boot from SD You can check the following code line in the boot log to confirm that the DPAA1 FMan ucode image on the SD card is updated. Fman1: Uploading microcode version 106.4.18 If U-Boot does not find LSDK on the SD card, it will boot TinyDistro from lsdk_linux_arm64_tiny.itb stored on the SD card. Option 2: Load image on SD card plugged into board from the TFTP server Boot LS1043ARDB from NOR flash. Ensure that the switches are set to boot the board from NOR bank 0. For booting from NOR bank 0, switch settings are as follows: SW3[1:8] = 10110011 SW4[1:8] = 00010010 SW5[1:8] = 10100010 Boot from NOR bank 0: => cpld reset For LS1043ARDB, in boot log, you'll see: Board: LS1043ARDB, boot from vBank 0 Set up Ethernet connection When board boots up, U-Boot prints a list of enabled Ethernet interfaces. FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3 [PRIME], FM1@DTSEC4, FM1@DTSEC5 Set server IP address to the IP address of the host machine on which you have configured the TFTP server.  => setenv serverip Set ethact and ethprime as the Ethernet interface connected to the TFTP server. See LS1043ARDB Ethernet and FMC port mapping for the mapping of Ethernet port names appearing on the chassis front panel with the port names in U-Boot and Linux.                        => setenv ethprime For example: => setenv ethprime FM1@DTSEC4 => setenv ethact For example: => setenv ethact FM1@DTSEC4 Set IP address of the board. You can set a static IP address or, if the board can connect to a dhcp server, you can use the dhcp command.  Static IP address assignment: => setenv ipaddr => setenv netmask Dynamic IP address assignment: => dhcp Save the settings. => saveenv Check the connection between the board and the TFTP server. => ping $serverip Using FM1@DTSEC4 device host 192.168.1.1 is alive Load FMan ucode image from the TFTP server Flash the FMan ucode image: => tftp 0xa0000000 fsl_fman_ucode_ls1043_r1.1_ .bin Program the FMan ucode image to SD card: => mmc write 0xa0000000 0x04800  Address  0x04800 is the SD card block number for the FMan ucode image.  ReferFlash layout for new boot flow with TF-A for the complete flash memory layout. Here, blk_cnt refers to number of blocks in SD card that need to be written as per the file size. For example, when you load FMan ucode from the TFTP server, if the bytes transferred is 37560 (92b8 hex), then blk_cnt is calculated as "37560/512 = 73 (49 hex)" + "few sectors for rounding up so that last block is not missed". So, if you round up by 5 (5 hex) sectors, for this example, mmc write command will be: => mmc write 0xa0000000 0x04800 4E You can boot the board using the SD card either by: setting the switches: SW3[1:8] = 10110011, SW4 [1:8] =00100000 , SW5 [1:8] = 00100010, or boot switching to SD card => cpld reset sd In boot log, you’ll see: Board: LS1043ARDB, boot from SD You can check the following code line in the boot log to confirm that the DPAA1 FMan ucode image on the SD card is updated. Fman1: Uploading microcode version 106.4.18 If U-Boot does not find LSDK on the SD card, it will boot TinyDistro from lsdk_linux_arm64_tiny.itb stored on the SD card. QorIQ LS1 Devices Re: LS1043ARDB - How to update DPAA1 FMan microcode (ucode) image on SD card I think it will be good to have also a section where you show how we write the sd card from u-boot in case we do not have a card reader on the host

i.MX6DQ 寄存器编程辅助工具 重要提示：如果您有任何疑问或想要报告有关 DDR 工具或支持文档的任何问题，请在i.MX 社区中创建支持工单。请注意，任何私人消息或直接邮件不会被监控，也不会收到回复。 这些是与MX6DQ SoC中MMDC DDR3和LPDDR2初始化相关的寄存器的详细编程辅助工具。最后一张表格格式化寄存器设置以便与ARM RealView ICE一起使用。它还可以与DDR压力测试的Windows可执行文件一起使用。此编程辅助工具用于NXP内部的电路板。 i.MX6 双核 i.MX6 四核

用于 PHY 寄存器操作的以太网工具 大多数以太网 PHY 支持多功能，并提供更灵活的配置能力，通过配置其寄存器可对时序进行微调或启用功能。以太网 PHY 寄存器工具提供了一种通过 MDC/MDIO 接口简单读写 PHY 寄存器的方法。这有助于开发或问题调试。  工业控制

NXP LPSPI 配置 S32K344 EVB 大家好， 我目前正在使用 NXP RTD 4.0.0 在 S32K344 EVK 上进行 LPSPI 通信。 我已经完成了 LPSPI 所需的配置，现在正在尝试在 EVK 上开发 SPI 回环通信。 但是，我目前遇到的问题是数据正在传输，但我在接收缓冲区中没有收到预期的数据。 附件内容供您参考： 项目源代码 相关配置详情 请您查看一下附件中的项目和配置，并帮我找出问题所在吗？ 具体来说，我希望您能协助核实以下事项： LPSPI 主/从配置 LPSPI引脚配置和信号路由 TX/RX 缓冲区配置 LPSPI 发送和接收的 API 使用 S32K344 EVK 上环回通信所需的任何其他配置 如果还需要我提供任何其他信息或日志，请告知。 谢谢！ 拉基 Re: NXP LPSPI Configuration S32K344 EVB 你好@rakYps21 我检查了您的代码和配置，没有发现任何问题。我还将该项目烧录到FRDM-A-S32K344开发板上，如下面的截图所示，主端和从端的接收缓冲区都包含了两次传输的预期数据。 我知道你使用的是S32K3x4EVB板。请问您具体使用的是哪种EVB版本？ 另外，如果可以的话，能否分享一下您电路板上MCU的照片？我想检查一下设备的标记和掩膜设置。 BR，VaneB Re: NXP LPSPI Configuration S32K344 EVB 嗨@VaneB ， 感谢您的确认和测试。 我目前使用的是FRDM Automotive S32K344MINI-EVB 板HDQFP172 MCU。 我还分享了一张安装在电路板上的MCU的图片供您参考。 请核实确认。 如果您需要我提供任何其他信息，请告诉我。 此致， 拉基 Re: NXP LPSPI Configuration S32K344 EVB 你好@rakYps21 感谢分享图片。 看来我们使用的配置非常相似。为确保两种设置一致，请您仔细检查一下您设置中的 SPI 信号是否按如下所示连接，并与 FRDM-A-S32K344 Rev. A 原理图中指定的引脚分配相匹配？ Re: NXP LPSPI Configuration S32K344 EVB 嗨@VaneB ， 我已经仔细检查了我的设置中的 SPI 信号连接和引脚分配，它们均按照 FRDM-A-S32K344 中的规定进行配置。 所有配置都与您提到的完全一致。 期待您的回复和进一步指导。 此致， 拉基 Re: NXP LPSPI Configuration S32K344 EVB @VaneB另外，能否请您分享一下您的设备配置和物理连接的图片以供参考？ 期待您的回复和进一步指导。 BR， 拉基 Re: NXP LPSPI Configuration S32K344 EVB 你好@rakYps21 照片中的连接不太容易区分，因此我在下面的 FRDM-A-S32K344 图片上用不同的颜色标记了它们，以便更清晰：棕色代表 CLK ，红色代表 PCS ，橙色代表 MOSI ，黄色代表 MISO 。 我还附上了捕获到的信号，以便您验证 SPI 通信是否按预期工作。 Re: NXP LPSPI Configuration S32K344 EVB @VaneB非常感谢您的支持。 现在一切正常。 LPSPI是否支持FRDM-A-S32K344 EVB的内部环回功能？ Re: NXP LPSPI Configuration S32K344 EVB 我目前正在研究如何将外部 NFC 读卡器IC 与NXP S32K344板连接起来。 我现在想与外部 NFC 阅读器建立通信，而不是使用 SPI 回环模式。 为此，我知道我需要配置以下硬件接口： 1. 3.3V电源和公共接地 2. NFC_IRQ 中断信号 3. SPI MOSI、MISO、CLK (SCK) 和 CS 信号 此外，我还需要您在实现库所需的平台特定功能方面提供指导。 尤其包括以下几点： #define platformDelay(t) vTaskDelay(pdMS_TO_TICKS(t)) #define platformGetSysTick() xTaskGetTickCount() #define platformSpiTxRx(txBuf, rxBuf, len) 请问您能否帮忙澄清以下问题？ 1. 将外部 NFC 阅读器与 NXP S32K344 连接时，推荐的硬件连接和 GPIO 配置是什么？ 2. 在NXP平台上应该如何配置和处理NFC_IRQ信号？ 3. 应如何实现 platformGetSysTick() 和 platformDelay() 以确保与 RFAL 库兼容？ 4. 如何使用 NXP LPSPI 驱动程序实现 platformSpiTxRx() 来从 NFC 阅读器发送和接收数据？ 5. 与外部 NFC 阅读器建立通信是否需要任何额外的平台特定配置或初始化步骤？ 非常感谢您的指导。 感谢您的支持。 问候， 拉基

S32G274A 实现SHA256+RSA2048算法 Hello NXP Support Team, I am currently evaluating HSE on the S32G274A platform and would appreciate some guidance regarding the recommended implementation path. Current environment: * Device: S32G274A * Core: Cortex-M7 * IDE: S32 Design Studio 3.6 * HSE package: HSE_DEMOAPP_S32G2XX_0_1_0_16 * HSE firmware: HSE_FW_S32G2XX_0_1_0_16 Current progress: * I am following AN14070 ("How to Run HSE Demo Application on Cortex-M7 Core of S32G2"). * The HSE demo project can be imported and compiled successfully. * However, when opening the IVT View, S32DS reports an exception and the IVT view cannot be created: com.nxp.swtools.ivt.views.IVTView (I can provide the complete error log if needed.) Project objective: Currently, our bootloader implements software-based secure boot: 1. Calculate SHA-256 of the application image. 2. Verify RSA-2048 signature using a public key stored in flash. 3. Boot the application only if verification succeeds. We would like to migrate this implementation to HSE-based services on Cortex-M7. Questions: 1. Is AN14070 still the recommended starting point for HSE evaluation on S32G274A with S32DS 3.6? 2. Is the IVT View mandatory for evaluating HSE services such as: * SHA-256 * AES * RSA signature verification Or is it only required for generating the blob image and installing HSE firmware? 3. Once HSE firmware is installed, is there any reference example demonstrating: * SHA-256 calculation through HSE * RSA-2048 signature verification through HSE * Public key import into HSE key catalog 4. Are there any application notes, training materials, or demo projects that demonstrate migrating a software-based secure boot implementation to HSE services on Cortex-M7? 5. For a bootloader that currently performs SHA-256 + RSA2048 verification before jumping to the application, what is the recommended migration path using HSE? Any guidance, reference projects, or recommended documentation would be greatly appreciated. Best regards, Re: S32G274A 实现SHA256+RSA2048算法 我按照步骤操作到3. The IVTView, shown in the following figure, displays the blocks DCD, HSE, Application bootloader, Boot configuration and Automatic Align that are relevant for the generation of the blob image   我的S32 Design Studio for S32 Platform 3.6.0打不开IVT VIEW 报错：Could not create the view: com.nxp.swtools.ivt.views.IVTView   java.lang.Exception at org.eclipse.ui.internal.ViewReference.createErrorPart(ViewReference.java:115) at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:101) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPart(CompatibilityPart.java:304) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:342) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:976) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:938) at org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:138) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:385) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:311) Re: S32G274A 实现SHA256+RSA2048算法 Hi，tom9 Thank you for contacting us. The AN14070 remains a valid starting point for Cortex‑M7 evaluation, but it is recommended to use it together with the HSE Demo App package and HSE FW reference documentation. You can share detail error information with me in your testing. Regarding the application of secure boot on the S32G, you can try to refer to the following content: S32G_Secure_boot chinese/english version. At present, there are no specific documents directly meet your requirements. I will at the internal channels to help you in checking. I will reply to you if I have the results. BR Joey Re: S32G274A 实现SHA256+RSA2048算法 Hi,tom9 Thank you for your reply. The issue should be related the S32DS version. Refer to the HSE_DEMOAPP_S32G2XX_0_1_0_16_ReadMe.pdf, please try to use this recommended version. BR Joey Re: S32G274A 实现SHA256+RSA2048算法 I've finished creating the blob and burned it, but I can't see any print information on the serial port, and Trace32 can't load it either. Where should I start troubleshooting? Please take a look as soon as possible. Re: S32G274A 实现SHA256+RSA2048算法 Hi, tom9 1. Based on AN14070, the blob is created and flashed. It then boots via QSPI to load the HSE firmware and start the M7_0. After QSPI boot, you can try using Trace32 to connect to the M7_0 and check the SRAM contents to see if the app has been loaded to the correct address. 2. Load the HSE demo .elf file only after the application starts normally. Then proceed to the next step in the process, moving to SRAM. BR Joey Re: S32G274A 实现SHA256+RSA2048算法 Your answers never meet my expectations. I can now print information normally, as shown below: HSE FW Version: 0.1.0_1.0.9 HSE FW Image: Pink HSE FW up and running! Status: HSE_STATUS_RNG_INIT_OK HSE_STATUS_INIT_OK HSE_STATUS_CUST_SUPER_USER The program got stuck here and couldn't proceed. After commenting out `DEBUG_LOOP(gZero);`, it was found that it was stuck in `HSE_Config();`. /* Backup primary image */ ASSERT(FLASH_OP_OK == Flash_WriteData_FromFlash(IVT.pSysImage_bck, The code `ITV.pSysImage, MAX_SYS_IMG_SIZE)` gets stuck here. Subsequent code such as `HSE_Aes_Example` also fails to execute. Re: S32G274A 实现SHA256+RSA2048算法 Hi, tom9 Our support system has received your questions. Your request involves many issues, and our internal experts are already providing support and responses. BR Joey

s32k322 启动问题 HI 我们 我们遇到了 一个 异常 在 开发 与 的 S32K322 微控制器进行开发时 使用 热电阻 版本 6.0.0.为了 消除 来自 上层 应用程序 代码的 干扰 ， 我们 创建 了一个 空白 的 S32K322 项目， 对其进行了 编译 ， 并 成功地 将其 刷 新 到 目标 板 上 。但是， 我们 观察 到 ， 当 在 启动 代码 中 执行 禁用 WDG0 （看门狗 0 ） 的 汇 编代码时， 芯片 会 立即 触发信号 HardF a ult 异常。经 调查、 我们 发现 我们发现 内存 内存 地址 范围 0x404800 至 0x414000 是 全部 充满了 全部被 0xFFFFFFFF.有意思的是 当 当 装配 代码 的 停用 WDG0 的汇编代码 删除、 数据 数据 中的 内存中的 内存 区域 返回 恢复正常。 正常。我们 我们将 非常感谢 感谢 任何 协助 提供 提供 a 解决方案 或 进一步 故障排除 建议 顺祝商祺！ 李永祥 Re: s32k322 boot issue 你好，我是@danielmartynek、 MCU 上未安装 HSE_FW，Project_Settings/Startup_Code/startup_cm7.s 中的 Reset_Handler 是 MCU 的入口。这个问题在我们所有的 s32k322 MCU 上都存在。 顺祝商祺！ 李永祥 Re: s32k322 boot issue 你好，我是@李永祥、 MCU 上是否安装了 HSE_FW？ 你还有更多可以重现问题的 MCU/板吗？ 谢谢 Re: s32k322 boot issue 你好@丹尼尔-马蒂内克 补充说明：一旦我们删除了禁用 WDG0 的代码，MCU 就能正常启动。但是，连接调试器仍然经常会触发硬故障——我们怀疑监视程序可能超时，但我们不能 100% 确定。希望这有助于分析。 顺祝商祺！ 李永祥 Re: s32k322 boot issue 你好，@丹尼尔-马蒂内克 感谢您的回复，以下是 S32DS 使用 RTD6.0.0 生成的空白项目。 顺祝商祺！ 李永祥 Re: s32k322 boot issue 你好，我是@李永祥、 你能否将空白项目和二进制一起分享以便我对其进行测试？ 谢谢！ BR，丹尼尔 Re: s32k322 boot issue 填充 0x 404800 到 0x 414000 范围的 0x FFFFFFF 也会导致 init_data_ bss 加载错误，len 将被识别为 0x ffffffff，MCU 启动将失败。 Re: s32k322 boot issue 感谢您的答复！看门狗由 Project_Settings/Startup_Code/startup_cm7.s 中的启动代码关闭，而不是由我的逻辑关闭。当 MCU 执行 "ldr r0, =0x40270000 "时，MCU 将陷入硬故障。 Re: s32k322 boot issue 看门狗可能会保护被误删的内存区域。启用看门狗可使 MCU 处于保护之下 Re: s32k322 boot issue 你好@YongxiangLi， 你所观察到的出乎意料。 我这边无法复现这种现象，这正是预期的结果。 默认情况下，SWT_0 WDOG 处于禁用状态（CR [WEN] = 0），除非启用了 HSE_FW 并且在启动配置字中配置了 APP_SWT_INIT。 SWT_0 模块默认也已启用时钟，因此访问它应该不会引起任何问题。 PRTN1_COFB0_CLKEN[28] PRTN1_COFB0_STAT[28] 在执行该例程之前，请检查所有相关的 ME_ME 和 SWT 寄存器。 此外，请阅读以下 ID 寄存器文档，以排除任何相关问题： SIUL2 MCU ID 寄存器 #1 (MIDR1) SIUL2 MCU ID 寄存器 #2 (MIDR2) BR，丹尼尔