Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
lx2160a kernel 5.10.35 about spi mode Hi: I found that the default DSPI_TCF_MODE transmission is very slow. I want to speed up the SPI transmission, but I found that it seems that the DSPI_DMA_MODE transmission is not supported. When I change the mode to DSPI_EOQ_MODE, it will cause the kernel to crash. I would like to know what steps I should take to effectively speed up the transmission of data through SPI. My changes are as follows: in spi-fsl-dspi.c static const struct fsl_dspi_devtype_data ls2085a_data = { .trans_mode = DSPI_EOQ_MODE, .max_clock_factor = 8, }; Re: lx2160a kernel 5.10.35 about spi mode Please refer to Linux Kernel source code provide by NXP. https://github.com/nxp-qoriq/linux/blob/lf-5.10.y/drivers/spi/spi-fsl-dspi.c Only the following two modes are supported. enum dspi_trans_mode { DSPI_XSPI_MODE, DSPI_DMA_MODE, };   Please use DSPI_XSPI_MODE mode for lx2160a platform. [LX2160A] = { .trans_mode = DSPI_XSPI_MODE, .max_clock_factor = 8, .fifo_size = 4, },
記事全体を表示
S32G3 引导加载程序用上市 core0 和 Core1 恩智浦的工程师们,你们好 我目前正在调试启动加载程序,以启动 core0 和 core1。core0 可以从 RESET 中释放并可以启动,但是 core1 无法开始运行。 使用 UDE 调试工具,可以成功调出 core1。在我的引导加载程序 EB 配置中,我已经为 core0 和 core1 配置了 RESET 处理程序地址和加载地址。我该如何进一步调试?如何调试引导加载程序? 我也在测试 IPCF_Example_multi_instance_S32G399A 项目,但这个项目的 core0 和 core1 都失败了。 谢谢。 Re: S32G3 Bootloader launch core0 and Core1 你好,@xlfd_1981 对您的不便,我深表歉意。 通常,在本社区板中,我们支持所有软件包的基本用法、恩智浦提供的硬件配置,此外,我们支持在软件包中使用演示/示例代码时直接出现的问题等。 对于特定或定制需求,我们通常建议通过 support.nxp.com 提交支持票据,因为这是一个私人渠道,更便于共享代码/项目。 目前,没有这样的演示可以直接支持你的要求,只有 AN1350 中的代码有点相似,但它也涉及 A53 内核,可以禁用 A53 部分来模拟你的请求,不确定你是否参考了它。 对于您的状态,为了直接帮助您调试问题,我建议您直接通过 support.nxp.com 发起私人票据,然后共享您的启动加载程序和应用程序(M7_0 和 M7_1),我们可以帮助您检查。 BR 切宁 Re: S32G3 Bootloader launch core0 and Core1 恩智浦专家 已经过去很多天了,我的问题仍然没有得到答复。现在让我们把问题简单化:请提供一个可以使用引导加载程序同时启动 core0 和 core1 的演示程序。我需要引导程序项目和应用程序项目。另外,请告诉我生成 blob 文件是否有任何特殊要求。我将使用您的演示来验证 core0 和 core1 能否正常启动。 我现在面临的问题是,core1 的映像可以加载,但 core1 就是无法启动。我不知道问题出在启动代码上,还是根本没有触发 core1。也没有寄存器可用于检查是否启动。请提供演示和建议以帮助我。这一点非常紧迫。非常感谢。 Re: S32G3 Bootloader launch core0 and Core1 你好,@xlfd_1981 感谢您的回复。 我能知道你是怎么创建 IVT 的,你在尝试从 QSPI 启动时加入了 DCD 吗? 我不太清楚您的设计,您是否使用引导加载器(M7_0)加载 core0.bin 和 core1.bin(IPCF)?实例)到相应的核心,还是其他类型的实现? BR 切宁 Re: S32G3 Bootloader launch core0 and Core1 澄阴 我将调试结果更新如下、 可能与启动程序有关。使用 UDE 调试时,ELF 文件被下载到内存中,我们可以看到 Core1 区域有有效数据。然而,在电源循环(系统从运行引导加载程序代码的闪存启动)后,使用 UDE 观察 Core1 内存区域,我们发现数据已被清零。这可能是引导程序造成的吗? 此致 Re: S32G3 Bootloader launch core0 and Core1 澄阴 此外,请查看我的 IPCF 代码、 将被编译为 core0.bin 和 core1.bin Re: S32G3 Bootloader launch core0 and Core1 切宁 我们目前正在RDB3 平台上开发基于您的IPCF 多核演示(v4.10.0)的引导加载程序。我们在Core1的启动过程中遇到了问题,感谢您的帮助。 当前设置: 我们的引导加载程序是根据您的演示项目(UM_BOOTLOADER_Rev_2023.02)开发的,并通过 EB 进行配置。 使用 UDE 调试时: 数据同时存在于 Core0 和 Core1 内存区域中 代码成功跳转到 Core0 的 Reset_Handler 然而,我们注意到 Core1 使用的 SRAM 区域(如 0x34680000)清零 因此,Core1 无法启动 问题 谁触发信号了这个 SRAM 清除? 它是由 UDE 引起的吗? 还是这是 RESET 行为的一部分? 会不会是启动程序中的某些初始化代码造成的? 此外,在函数 Sys_StartSecondaryCores()中,我们设置了 IP_MC_ME->PRTN0_CORE1_ADDR = 0x34780000; 请确认该地址应指向何处: 是否应该是 SRAM 中 Core1 映像的 加载地址 (即 .intc_vector 的位置)? 还是应该是 向量表偏移量 (VTOR)? 我们的链接器脚本显示 .intc_vector 位于 0x34780400,而图像从 0x34680000 开始。 非常感谢你们的支持! 如有需要,我可以提供 .map文件、.ld脚本或截图,以便进一步分析。 顺祝商祺! Re: S32G3 Bootloader launch core0 and Core1 你好,@xlfd_1981 谢谢您的帖子。 您能否提供更多有关测试的信息? 1.它是在 S32G3 定制板上完成的,还是在 NXP 的 RDB3/EVB3 上完成的? 2.引导加载程序来自哪里?是定制的还是恩智浦的?如果是恩智浦的,是哪个版本? 3.文中提到使用了 core0&1,请问它们是 M7_0 和 M7_1 还是其他组合? 通常,引导加载程序运行在 M7_0 上,可以直接使用调试器进行调试,这与其他 M7 应用程序并无不同。 BR 切宁
記事全体を表示
NTAG 424 更改密钥 0 后无法登录 大家好, 我遇到了一个无法解决的奇怪问题。我完成了为网络安全平台配置 #NTAG424 的所有步骤:一切都很好,但还有最后一件事 我不得不更改所有 5 个按键,并从这个"循环" 开始,将 4 改为 0: 使用密钥 0 登录 更改按键 X 我知道更改 K0 与更改 K4-1 是不同的,而响应是 91-00,因此似乎一切正常。 现在的问题是:我可以用所有 Kyes 4-1 登录,但用 K0 登录第 2 部分时会出现 91-AE。 我想可能是加密出错了,所以密钥和我想的不一样,但我检查了很多次代码都没问题。我只是根据数据表和 AN12196 更改了密码计算。 有什么提示吗? 谢谢 Re: NTAG 424 no login possible after key 0 change 您好@MPucci, 在您的帖子中是否已经实现了 ChangeKey 0 和 1-4?我目前正在实施,但遇到了一些问题。我无法成功修改 Key1-4 以响应 911E,而修改 Key0 后,验证响应是 91AE。我想寻求您的帮助,不胜感激。 Re: NTAG 424 no login possible after key 0 change 你好@KaiLi 我在 AN12196 中没有看到 6.16.2。是因为文件版本不同吗? 有什么提示吗? 谢谢! Re: NTAG 424 no login possible after key 0 change 你好@MPucci 根据您的问题描述,建议您尝试 AN12196 第 6.16.2 章中的步骤。例如 1.通过密钥进行身份验证No 0x00 2. 输入新建键 3. 执行 ChangeKey 命令 4. 重复检查使用新密钥验证 NTAG424 的情况。 BR 凯利 Re: NTAG 424 no login possible after key 0 change 更多信息:我知道这样做不对,但在更改密钥之前,我在所有登录中都使用了相同的 RndA。我无法确定问题的根源,但如果我在登录时使用 5 个不同的 RndA,密钥(甚至 K0)不会出现问题,但如果我在登录时使用相同的 RndA,K0 就会损坏。 所以现在问题解决了,但还不知道原因。
記事全体を表示
How to Build & Test OPTEE on iMX91 processor Hi,    I am trying to understand the OPTEE functionality. Requesting support on following:    1. OPTEE documentation/ tutorial w.r.t. iMX91    2. How to Build & Test OPTEE on iMX91 processor with YOCTO.    Currently I have a YOCTO base developed from  -  repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-styhead -m imx-6.12.3-1.0.0_security-reference-design.xml Please find below the list of files generated from it ls tmp/deploy/images/imx91-11x11-lpddr4-evk ├── bl31-imx91.bin ├── bl31-imx91.bin-optee ├── core-image-base.env ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.manifest ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.spdx.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.testdata.json ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.bmap ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.manifest -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.manifest ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.spdx.tar.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.spdx.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.tar.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.testdata.json -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.testdata.json ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.wic.bmap -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.bmap ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.wic.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.zst ├── core-image-base-imx-imx-boot-bootpart.wks ├── core-image-minimal-secure-boot.env ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.manifest ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.spdx.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.testdata.json ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.bmap ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.manifest -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.manifest ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.spdx.tar.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.spdx.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.tar.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.testdata.json -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.testdata.json ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.wic.bmap -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.bmap ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.wic.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.zst ├── core-image-minimal-secure-boot-imx-imx-boot-bootpart.wks ├── files.txt ├── flash.bin ├── flash_os.bin ├── Image -> Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── Image-imx91-11x11-lpddr4-evk.bin -> Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── imx91-11x11-evk--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk.dtb ├── imx91-11x11-evk-aud-hat--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk-aud-hat-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk.dtb ├── imx91-11x11-evk-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk.dtb ├── imx91-11x11-evk-ld--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-ld-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-lpuart--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-lpuart-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-mt9m114--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-mt9m114-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-tianma-wvga-panel--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx91-11x11-evk-tianma-wvga-panel-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx-boot -> imx-boot-tagged ├── imx-boot-imx91-11x11-lpddr4-evk-sd.bin-flash_singleboot ├── imx-boot-tagged ├── imx-boot.tagged ├── imx-boot-tools │ ├── bl31-imx91.bin │ ├── bl31-imx91.bin-optee │ ├── csf_ahab.cfg.sample │ ├── csf_hab4.cfg.sample │ ├── imx_signer │ ├── lpddr4_dmem_1d_v202201.bin │ ├── lpddr4_dmem_2d_v202201.bin │ ├── lpddr4_imem_1d_v202201.bin │ ├── lpddr4_imem_2d_v202201.bin │ ├── mkimage_imx8 │ ├── mx91a0-ahab-container.img │ ├── soc.mak │ ├── spsdk_ahab.cfg.sample │ ├── tee.bin │ ├── u-boot-imx91-11x11-lpddr4-evk.bin-sd │ └── u-boot-spl.bin-imx91-11x11-lpddr4-evk-sd ├── imx-boot-untagged ├── lpddr4_dmem_1d_v202201.bin ├── lpddr4_dmem_2d_v202201.bin ├── lpddr4_imem_1d_v202201.bin ├── lpddr4_imem_2d_v202201.bin ├── modules--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.tgz ├── modules-imx91-11x11-lpddr4-evk.tgz -> modules--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.tgz ├── mx91a0-ahab-container.img ├── optee │ ├── ta │ │ ├── 023f8f1a-292a-432b-8fc4-de8471358067.elf │ │ ├── 023f8f1a-292a-432b-8fc4-de8471358067.stripped.elf │ │ ├── 02a42f43-d8b7-4a57-aa4d-87bd9b5587cb.elf │ │ ├── 02a42f43-d8b7-4a57-aa4d-87bd9b5587cb.stripped.elf │ │ ├── 25497083-a58a-4fc5-8a72-1ad7b69b8562.elf │ │ ├── 25497083-a58a-4fc5-8a72-1ad7b69b8562.stripped.elf │ │ ├── 380231ac-fb99-47ad-a689-9e017eb6e78a.elf │ │ ├── 380231ac-fb99-47ad-a689-9e017eb6e78a.stripped.elf │ │ ├── 528938ce-fc59-11e8-8eb2-f2801f1b9fd1.elf │ │ ├── 528938ce-fc59-11e8-8eb2-f2801f1b9fd1.stripped.elf │ │ ├── 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.elf │ │ ├── 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.stripped.elf │ │ ├── 5c206987-16a3-59cc-ab0f-64b9cfc9e758.elf │ │ ├── 5c206987-16a3-59cc-ab0f-64b9cfc9e758.stripped.elf │ │ ├── 5ce0c432-0ab0-40e5-a056-782ca0e6aba2.elf │ │ ├── 5ce0c432-0ab0-40e5-a056-782ca0e6aba2.stripped.elf │ │ ├── 731e279e-aafb-4575-a771-38caa6f0cca6.elf │ │ ├── 731e279e-aafb-4575-a771-38caa6f0cca6.stripped.elf │ │ ├── 80a4c275-0a47-4905-8285-1486a9771a08.elf │ │ ├── 80a4c275-0a47-4905-8285-1486a9771a08.stripped.elf │ │ ├── 873bcd08-c2c3-11e6-a937-d0bf9c45c61c.elf │ │ ├── 873bcd08-c2c3-11e6-a937-d0bf9c45c61c.stripped.elf │ │ ├── 8aaaf200-2450-11e4-abe20002a5d5c51c.elf │ │ ├── 8aaaf200-2450-11e4-abe20002a5d5c51c.stripped.elf │ │ ├── a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.elf │ │ ├── a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.stripped.elf │ │ ├── a720ccbb-51da-417d-b82e-e5445d474a7a.elf │ │ ├── a720ccbb-51da-417d-b82e-e5445d474a7a.stripped.elf │ │ ├── b3091a65-9751-4784-abf7-0298a7cc35ba.elf │ │ ├── b689f2a7-8adf-477a-9f99-32e90c0ad0a2.elf │ │ ├── b689f2a7-8adf-477a-9f99-32e90c0ad0a2.stripped.elf │ │ ├── c3f6e2c0-3548-11e1-b86c-0800200c9a66.elf │ │ ├── c3f6e2c0-3548-11e1-b86c-0800200c9a66.stripped.elf │ │ ├── cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.elf │ │ ├── cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.stripped.elf │ │ ├── d17f73a0-36ef-11e1-984a-0002a5d5c51b.elf │ │ ├── d17f73a0-36ef-11e1-984a-0002a5d5c51b.stripped.elf │ │ ├── e13010e0-2ae1-11e5-896a-0002a5d5c51b.elf │ │ ├── e13010e0-2ae1-11e5-896a-0002a5d5c51b.stripped.elf │ │ ├── e6a33ed4-562b-463a-bb7e-ff5e15a493c8.elf │ │ ├── e6a33ed4-562b-463a-bb7e-ff5e15a493c8.stripped.elf │ │ ├── f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.elf │ │ ├── f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.stripped.elf │ │ ├── f157cda0-550c-11e5-a6fa-0002a5d5c51b.elf │ │ ├── f157cda0-550c-11e5-a6fa-0002a5d5c51b.stripped.elf │ │ ├── fd02c9da-306c-48c7-a49c-bbd827ae86ee.elf │ │ ├── fd02c9da-306c-48c7-a49c-bbd827ae86ee.stripped.elf │ │ └── ffd2bded-ab7d-4988-95ee-e4962fff7154.elf │ ├── tee.bin │ ├── tee.elf │ ├── tee-header_v2.bin │ ├── tee.mx91evk.bin │ ├── tee-pageable_v2.bin │ ├── tee-pager_v2.bin │ └── tee-raw.bin ├── os_cntr_signed.bin ├── signed-imx-boot-imx91-11x11-lpddr4-evk-sd.bin-flash_singleboot ├── tee.bin -> optee/tee.mx91evk.bin ├── u-boot.bin -> u-boot-sd-2024.04-r0.bin ├── u-boot.bin-sd -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx91-11x11-lpddr4-evk.bin -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx91-11x11-lpddr4-evk.bin-sd -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd -> u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-imx-initial-env-sd -> u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-sd-2024.04-r0.bin ├── u-boot-spl.bin -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-imx91-11x11-lpddr4-evk -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-imx91-11x11-lpddr4-evk-sd -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-sd -> u-boot-spl.bin-sd-2024.04-r0 └── u-boot-spl.bin-sd-2024.04-r0 4 directories, 153 files Thx, Kiran Re: How to Build & Test OPTEE on iMX91 processor Hi @KiranM7! Thank you for contacting NXP Support! OP-TEE is enabled by default in our BSP. While we currently do not have an official guide for running optee-test, you can refer to the official OP-TEE documentation for detailed instructions: optee_test Best regards, Chavira
記事全体を表示
OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi all, I'm trying to integrate the SE050 to be used in a node.js webserver. I successfully compiled the middleware including the OpenSSL provider and also got the ssscli to work. With ssscli I created a keypair, injected it into the SE and created a refpem key. I also adapted the openssl.cnf of the system to match the one in simwtop/demos/linux/common/openssl30_sss_se050.cnf. But any TLS connection to the server fails in the handshake as OpenSSL uses the reference to the key slot as actual private key instead of calling the SE050 provider. I also tried to get it to work with OpenSSL CLI, i.e., openssl s_server. I can get a connection using the nxp: scheme but not using the refpem key file. The following command leads to the error: openssl s_server -accept 12345 -cert server.pem -key server.refpem.key -CAfile root.pem  Error: SSL3 alert read:fatal:decrypt error SSL_accept:error in error ERROR 20203CA4FFFF0000:error:1B80006E:lib(55):ossl_parse_query:trailing characters:../openssl-3.0.13/crypto/property/property_parse.c:454:HERE-->/usr/lib/libsssProvider.so 20203CA4FFFF0000:error:0A00041B:SSL routines:ssl3_read_bytes:tlsv1 alert decrypt error:../openssl-3.0.13/ssl/record/rec_layer_s3.c:1590:SSL alert number 51 shutting down SSL If I use the nxp url scheme, though, I can successfully connect to the server. openssl s_server -accept 12345 -cert server.pem -key nxp:0x6789ABCD -CAfile root.pem However, I can't specify the nxp:0x6789ABCD key reference in the node.js code but have to use the refpem file. Is there anyway to do that? I also tried to make OpenSSL prioritize the SE050 provider over the default one by specifiying a propquery in the config file. But no luck so far. # Relevant parts from openssl.cnf [openssl_init] providers = provider_sect alg_section = evp_properties [provider_sect] default = default_sect nxp_prov = nxp_prov_sec [default_sect] activate = 1 [nxp_prov_sec] identity = nxp_prov module = /usr/local/lib/libsssProvider.so activate = 1 [evp_properties] default_properties = ?provider=nxp_prov Any help would be highly appreciated! SE050 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working I forgot to mention that the Node version I'm using is 20.12.2. Versions later than 20.x may not have this issue, I have no way to verify this at this time. After further investigation, it emerged that the client-side decryption issue was caused by an incorrect provider loading order. That said, it turns out that this version of Node has a problematic handling of random number generation. The problem is related to how Node initializes providers. Specifically, in the initialization of the random generators, which leads to an infinite loop of calls to sss_rand_get_ctx_params. The node.cc file contains a fix (with a comment in the source), but it doesn't work with libsssProvider.so. I'm sharing a series of workarounds in case anyone finds themselves in a similar situation. I'll start by saying that these are all related to the libsssProvider and are primarily intended to NOT change Node or OpenSSL, so other much cleaner solutions are obviously possible. I can't share the code; I hope the information below is clear enough. Available options: 1. In the CMakeLists.txt file, set the SSS_PROV_DISABLE_SE05X_RNG variable. This completely disables the use of SE05X for randoms. It's not ideal, but if you don't have any special needs, it works. 2. In the sssProvider_main.c file, change the algorithms of the srands structure so that the name provided is NOT one of the known ones (and especially NOT the default). This still makes it possible to use the SE05X random module if needed, by setting the random key in the openssl config file. 3. Similar to point 2, but in this case the name is optionally provided with an environment variable (srands obviously can't be constant). This way, only in the case of Node applications you can avoid using the SE05X random generator, leaving it active for other uses instead. The refpems work correctly with these options. Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working I am experiencing the same exact problem of @tksec. If using OpenSSL cli tools everything is fine, I can establish a TLS connection that uses a key in the SE052 module via libsssProvider.so. On Node.js, I verified that libsssProvider is loaded, but handshake always fails, as per error below: SSL3 alert write:fatal:decrypt error SSL_connect:error in error 20109DB6FFFF0000:error:0A00007B:SSL routines:tls_process_cert_verify:bad signature:/usr/src/debug/openssl/3.2.1/ssl/statem/statem_lib.c:584: It seems that referring the key by id as suggested by @Kan_Li  does not actually work: -  If I provide in options.key the path to the refpem file, server starts w/o issues and listens for connections, but handshake fails as reported. - If I provide in options.key the key path as urk (nxp: ) applications crashes - If I provide in options.key the key reference (nxp: ) applications crashes So, can you @Kan_Li  please share a piece of Node.js code that can successfully initialize a server, assuming that, as stated, this should just work fine? Thanks Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @tksec, have you found a suitable way to use the key reference in node.js? I have a similar issue. I am using the se05x-openssl-provider (v01.00.03) with OpenSSL 3.0.14 to generate a key pair, but I am unable to use "Reference Keys in file format" as described in the Readme-File of the Github Repo of the openssl provider. The other two versions (Labels with reference key (Example - nxp:"path to reference key file") and Labels with key id (Example - nxp:0x12345678) just work fine. The Readme says the following: "NOTE: When using this method, the sss provider has to be loaded first. This will ensure that the sss provider can decode the key id information present in the reference key." Unfortunately, I don't know how to do this. Loading the provider by adding it to the openssl.cnf file did not work for me. I still get an decrypt error if I want to use the Reference Key in file format. Thank you in advance. Best regards Thomas Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @tksec , Thanks for the information! What is the use case you are using with refpem file? sign&verify? I may try to reproduce this issue here. Best Regards, Kan Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @Kan_Li , yes, I used the ssscli tool. I'm running MW v4.05.00. I created the original key with OpenSSL on a different system. Loaded it into SE using ssscli set command and created the refpem with ssscli refpem command. The key can successfully be used and parsed when using the openssl commands like s_client, s_server, rsa, etc. It can also be converted to a EVP_PKEY using OSSL_STORE API (what the openssl commands do internally) but it fails to parse using PEM_read_bio_PrivateKey which is used by both the NXP engine (in EmbSe_LoadPrivKey) and node.js. Thanks! Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @tksec , How did you generate the refpem for RSA key? by the tool of ssscli? which version of MW are you using now? Please kindly clarify. Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @Kan_Li  thanks for clarifying that the refpem key is only useable for the openssl engine. The issue with node.js in particular is that they call the PEM_read_bio_PrivateKey function directly on any key string that is provided, which obviously fails when the key string is not a PEM string or file path but a uri. There is no direct support for OpenSSL providers, yet. I reverted back to using the OpenSSL engine instead and got into similar problems. While using an EC key is working perfectly, using an RSA key fails again while parsing the PEM file with error:1E08010C:DECODER routines::unsupported from OpenSSL. I debugged the code and could trace the error back to the function PEM_read_bio_PrivateKey which is called from within EmbSe_LoadPrivKey in the engine's code. Are you aware of such an issue to handle an RSA refpem key in the OpenSSL engine? How can this be solved? For me it looks like the refpem is more invasive for RSA than it is for EC keys which might be an issue? Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @tksec , The refpem key file is only for openssl engine, but since you use openssl 3.xx with provider, please use "nxp:key_id" instead. You may compare "se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient.sh" with "se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient_3_0.sh" to check the difference.  and I am also wondering if you have any security concern regarding this, actually from my option, it is just a string should be accepted by most of the scripts, why not able to specify the nxp:0x6789ABCD key reference in the node.js code? Please kindly clarify. Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
記事全体を表示
iMXRT10xx SDK MCUBoot version Hi, I'm using the iMXRT1021 MCU with MCUXpresso SDK 24.12.00 and MCUBoot as middelware component from SDK. Is there a way to know which MCUBoot version is included with SDK? I searched in code but no version is defined for MCUBoot... Thanks! Re: iMXRT10xx SDK MCUBoot version Hi! Just found in SDK documentation the MCUBoot Release Notes: it should be 2.0.0 MCUboot release notes — MCUXpresso SDK Documentation
記事全体を表示
推荐使用 MX8QM PMIC 我正在规划一个基于 MX8QM 处理器的设计。我们将使用以下接口 A72 2x 内核 PCIe 接口 eMMC 接口 以太网接口 我们不会使用 GPU、VPU 和显示器等。 在 PMIC 选择页面上,https://www.nxp.com/products/power-management/pmics-and-sbcs:POWR_MAN_USER_INTERFACE 推荐的设备是 PF81-PF82,根据产品页面,不推荐使用。 那么推荐的设备是什么? 我们可以使用PCA9450C 吗? 此致 i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Re: MX8QM recommended PMIC 你好 遗憾的是,恩智浦没有 PF81-PF82 的替换零件编号。 我建议您寻找第三方解决方案: 针对恩智浦 i.MX8 QuadMax 处理器的集成电源设计 此外,PCA9450 PMIC 与 i.MX8QM 不兼容,因为与 i.MX8MN/M/P 处理器相比,PCA9450 PMIC 需要更高的电流功耗和不同的上电/断电顺序。 请记住,在 2034 年 5 月之前,PF81-PF82 产品系列是我们的长寿计划的一部分 顺祝商祺!
記事全体を表示
iMXRT10xx SDK MCUBoot バージョン こんにちは、 私は、iMXRT1021 MCU を MCUXpresso SDK 24.12.00 と、SDK からのミドルウェア コンポーネントとして MCUBoot とともに使用しています。 SDKs に含まれている MCUBoot のバージョンを確認する方法はありますか? コードで検索しましたが、MCUBoot のバージョンは定義されていません... よろしくお願いします! Re: iMXRT10xx SDK MCUBoot version こんにちは! SDKドキュメントのMCUBootリリースノートで見つけました: 2.0.0のはずです MCUboot リリースノート — MCUXpresso SDK ドキュメント
記事全体を表示
带 ATF 调整时钟的 S32G Linux 用于扩频 你好 Linux 电路板支持包 团队, 客户询问了有关如何调整带有 ATF 的 Linux 电路板支持包中的时钟扩频设置的指南。 我检查了最新的 S32G 电路板支持包,找不到以下与时钟扩频相关的锁相环频率调制 (PLLFM) 寄存器配置。 我的问题是,我们有计划在 Linux 电路板支持包 中添加这种支持吗? BRs, 天祥 Linux BSP Re: S32G Linux with ATF adjust clock for spread spectrum 理论上,扩频只能在 1516MHz(DS 值略低于 1600MHz)的频率下工作,因为它不能向下扩频,否则就意味着要对 DDR 进行超频,而法雷奥则决定将 DDR 频率提高到 1590MHz(更接近 1600MHz),因为它比 SS 更容易实现。但由于 1590MHz 不在 DS 和校准工具中,因此风险自负。下面是这篇文章: [S32G]将 DDR 频率改为 1590MHz,并使用 20 欧元的 SDR 加密狗测量结果 Re: S32G Linux with ATF adjust clock for spread spectrum 你好,根纳迪 知道了,谢谢你的快速确认。 BRs, 天祥 Re: S32G Linux with ATF adjust clock for spread spectrum 你好@Tianxiang_Huang、 目前还不支持用于 DDR PLL 频率调制的时钟扩频,也不打算在短期内添加。如果这与一个或多个客户相关,则需要详细的变更申请。请注意,鉴于 TF-A 集成了该工具生成的代码,因此任何与 DDR 相关的更改都必须与 DDR 工具同步。 此致, 根纳迪
記事全体を表示
如何在 iMX91 处理器上版本 & 测试 OPTEE 您好, 我想了解 OPTEE 的功能。请求在以下方面提供支持 1.有关 OPTEE 的文件/教程iMX91 2.如何使用 YOCTO 在 iMX91 处理器上版本 & 测试 OPTEE。 目前,我有一个 YOCTO 基础,它是由--......开发的。 仓库 init-u https://github.com/nxp-imx/imx-manifest-b imx-linux-styhead -m imx-6.12.3-1.0.0_security-参考设计.xml 下面是由它生成的文件列表 ls tmp/deploy/images/imx91-11x11-lpddr4-evk ├── bl31-imx91.bin ├── bl31-imx91.bin-optee ├── core-image-base.env ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.manifest ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.spdx.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.testdata.json ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.bmap ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.manifest -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.manifest ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.spdx.tar.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.spdx.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.tar.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.testdata.json -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.testdata.json ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.wic.bmap -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.bmap ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.wic.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.zst ├── core-image-base-imx-imx-boot-bootpart.wks ├── core-image-minimal-secure-boot.env ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.manifest ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.spdx.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.testdata.json ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.bmap ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.manifest -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.manifest ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.spdx.tar.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.spdx.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.tar.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.testdata.json -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.testdata.json ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.wic.bmap -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.bmap ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.wic.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.zst ├── core-image-minimal-secure-boot-imx-imx-boot-bootpart.wks ├── files.txt ├── flash.bin ├── flash_os.bin ├── Image -> Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── Image-imx91-11x11-lpddr4-evk.bin -> Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── imx91-11x11-evk--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk.dtb ├── imx91-11x11-evk-aud-hat--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk-aud-hat-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk.dtb ├── imx91-11x11-evk-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk.dtb ├── imx91-11x11-evk-ld--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-ld-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-lpuart--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-lpuart-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-mt9m114--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-mt9m114-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-tianma-wvga-panel--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx91-11x11-evk-tianma-wvga-panel-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx-boot -> imx-boot-tagged ├── imx-boot-imx91-11x11-lpddr4-evk-sd.bin-flash_singleboot ├── imx-boot-tagged ├── imx-boot.tagged ├── imx-boot-tools │ ├── bl31-imx91.bin │ ├── bl31-imx91.bin-optee │ ├── csf_ahab.cfg.sample │ ├── csf_hab4.cfg.sample │ ├── imx_signer │ ├── lpddr4_dmem_1d_v202201.bin │ ├── lpddr4_dmem_2d_v202201.bin │ ├── lpddr4_imem_1d_v202201.bin │ ├── lpddr4_imem_2d_v202201.bin │ ├── mkimage_imx8 │ ├── mx91a0-ahab-container.img │ ├── soc.mak │ ├── spsdk_ahab.cfg.sample │ ├── tee.bin │ ├── u-boot-imx91-11x11-lpddr4-evk.bin-sd │ └── u-boot-spl.bin-imx91-11x11-lpddr4-evk-sd ├── imx-boot-untagged ├── lpddr4_dmem_1d_v202201.bin ├── lpddr4_dmem_2d_v202201.bin ├── lpddr4_imem_1d_v202201.bin ├── lpddr4_imem_2d_v202201.bin ├── modules--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.tgz ├── modules-imx91-11x11-lpddr4-evk.tgz -> modules--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.tgz ├── mx91a0-ahab-container.img ├── optee │ ├── ta │ │ ├── 023f8f1a-292a-432b-8fc4-de8471358067.elf │ │ ├── 023f8f1a-292a-432b-8fc4-de8471358067.stripped.elf │ │ ├── 02a42f43-d8b7-4a57-aa4d-87bd9b5587cb.elf │ │ ├── 02a42f43-d8b7-4a57-aa4d-87bd9b5587cb.stripped.elf │ │ ├── 25497083-a58a-4fc5-8a72-1ad7b69b8562.elf │ │ ├── 25497083-a58a-4fc5-8a72-1ad7b69b8562.stripped.elf │ │ ├── 380231ac-fb99-47ad-a689-9e017eb6e78a.elf │ │ ├── 380231ac-fb99-47ad-a689-9e017eb6e78a.stripped.elf │ │ ├── 528938ce-fc59-11e8-8eb2-f2801f1b9fd1.elf │ │ ├── 528938ce-fc59-11e8-8eb2-f2801f1b9fd1.stripped.elf │ │ ├── 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.elf │ │ ├── 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.stripped.elf │ │ ├── 5c206987-16a3-59cc-ab0f-64b9cfc9e758.elf │ │ ├── 5c206987-16a3-59cc-ab0f-64b9cfc9e758.stripped.elf │ │ ├── 5ce0c432-0ab0-40e5-a056-782ca0e6aba2.elf │ │ ├── 5ce0c432-0ab0-40e5-a056-782ca0e6aba2.stripped.elf │ │ ├── 731e279e-aafb-4575-a771-38caa6f0cca6.elf │ │ ├── 731e279e-aafb-4575-a771-38caa6f0cca6.stripped.elf │ │ ├── 80a4c275-0a47-4905-8285-1486a9771a08.elf │ │ ├── 80a4c275-0a47-4905-8285-1486a9771a08.stripped.elf │ │ ├── 873bcd08-c2c3-11e6-a937-d0bf9c45c61c.elf │ │ ├── 873bcd08-c2c3-11e6-a937-d0bf9c45c61c.stripped.elf │ │ ├── 8aaaf200-2450-11e4-abe20002a5d5c51c.elf │ │ ├── 8aaaf200-2450-11e4-abe20002a5d5c51c.stripped.elf │ │ ├── a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.elf │ │ ├── a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.stripped.elf │ │ ├── a720ccbb-51da-417d-b82e-e5445d474a7a.elf │ │ ├── a720ccbb-51da-417d-b82e-e5445d474a7a.stripped.elf │ │ ├── b3091a65-9751-4784-abf7-0298a7cc35ba.elf │ │ ├── b689f2a7-8adf-477a-9f99-32e90c0ad0a2.elf │ │ ├── b689f2a7-8adf-477a-9f99-32e90c0ad0a2.stripped.elf │ │ ├── c3f6e2c0-3548-11e1-b86c-0800200c9a66.elf │ │ ├── c3f6e2c0-3548-11e1-b86c-0800200c9a66.stripped.elf │ │ ├── cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.elf │ │ ├── cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.stripped.elf │ │ ├── d17f73a0-36ef-11e1-984a-0002a5d5c51b.elf │ │ ├── d17f73a0-36ef-11e1-984a-0002a5d5c51b.stripped.elf │ │ ├── e13010e0-2ae1-11e5-896a-0002a5d5c51b.elf │ │ ├── e13010e0-2ae1-11e5-896a-0002a5d5c51b.stripped.elf │ │ ├── e6a33ed4-562b-463a-bb7e-ff5e15a493c8.elf │ │ ├── e6a33ed4-562b-463a-bb7e-ff5e15a493c8.stripped.elf │ │ ├── f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.elf │ │ ├── f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.stripped.elf │ │ ├── f157cda0-550c-11e5-a6fa-0002a5d5c51b.elf │ │ ├── f157cda0-550c-11e5-a6fa-0002a5d5c51b.stripped.elf │ │ ├── fd02c9da-306c-48c7-a49c-bbd827ae86ee.elf │ │ ├── fd02c9da-306c-48c7-a49c-bbd827ae86ee.stripped.elf │ │ └── ffd2bded-ab7d-4988-95ee-e4962fff7154.elf │ ├── tee.bin │ ├── tee.elf │ ├── tee-header_v2.bin │ ├── tee.mx91evk.bin │ ├── tee-pageable_v2.bin │ ├── tee-pager_v2.bin │ └── tee-raw.bin ├── os_cntr_signed.bin ├── signed-imx-boot-imx91-11x11-lpddr4-evk-sd.bin-flash_singleboot ├── tee.bin -> optee/tee.mx91evk.bin ├── u-boot.bin -> u-boot-sd-2024.04-r0.bin ├── u-boot.bin-sd -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx91-11x11-lpddr4-evk.bin -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx91-11x11-lpddr4-evk.bin-sd -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd -> u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-imx-initial-env-sd -> u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-sd-2024.04-r0.bin ├── u-boot-spl.bin -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-imx91-11x11-lpddr4-evk -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-imx91-11x11-lpddr4-evk-sd -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-sd -> u-boot-spl.bin-sd-2024.04-r0 └── u-boot-spl.bin-sd-2024.04-r0 4 directories, 153 files 谢谢, 基兰 Re: How to Build & Test OPTEE on iMX91 processor 嗨,@KiranM7! 感谢您联系恩智浦支持中心! 在我们的 BSP 中,OP-TEE 默认处于启用状态。虽然我们目前没有运行 optee-test 的官方指南,但您可以参考官方 OP-TEE 文档以获取详细说明: 选项测试 致以最崇高的敬意, Chavira
記事全体を表示
MX8QM推奨PMIC MX8QM プロセッサをベースにした設計を計画しています。以下のインターフェースを使用します A72 2コア PCIeインターフェース eMMCインターフェース イーサネットインターフェース GPU、VPU、ディスプレイなどは使用しません。 PMIC 選択ページ ( https://www.nxp.com/products/power-management/pmics-and-sbcs:POWR_MAN_USER_INTERFACE ) では、推奨デバイスは PF81-PF82 ですが、製品ページによると推奨されていません。 SO、推奨されるデバイスは何でしょうか? PCA9450Cは使えますでしょうか? よろしくお願いします。 i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Re: MX8QM recommended PMIC こんにちは、 残念ながら、NXP の PF81-PF82 の交換部品番号はありません。 次のようなサードパーティのソリューションを探すことをお勧めします。 NXP i.MX8 QuadMaxプロセッサ向け統合電源デザイン また、PCA9450 PMIC は、i.MX8MN/M/P プロセッサと比較して、電力要件がより高い電流消費と異なる電源オン/電源オフ シーケンスであるため、i.MX8QM と互換性がありません。 PF81-PF82製品ファミリは、2034年5月まで当社の長寿プログラムの一部であることをご留意ください。 よろしくお願いいたします。
記事全体を表示
NTAG 424 no login possible after key 0 change Hi all, i'm facing a strange behaviour that i can't solve. I completed all my steps to configure a #NTAG424 for a security platform: everything is ok BUT one last thing I had to change all the 5 keys and started with this "loop" for 4 to 0: Login with key 0 Change key X I'm aware that changing K0 is different from K4-1 and the response is 91-00 so seems everything is correct. Now the problem: i can login with all the kyes 4-1 but with K0 i get a 91-AE in login part 2. I suppose that the encryption is wrong so the key is different from what i think, but i checked a lot of time the code and is ok. I only changet the cryptogram calculation as per data sheet and AN12196.  Any hint? Thank Re: NTAG 424 no login possible after key 0 change Hello @MPucci , Have you already implemented ChangeKey 0 and 1-4 in your post? I am currently implementing this, but I have encountered some issues. I am unable to successfully modify Key1-4 to respond to 911E, and after modifying Key0, the authentication response is 91AE. I would like to seek some help from you, and I would greatly appreciate it. Re: NTAG 424 no login possible after key 0 change Hello @KaiLi  I didn't see 6.16.2 in AN12196. Is it because the version of the document is different? Any hints? Thank you! Re: NTAG 424 no login possible after key 0 change Hello @MPucci  Thanks for contacting us and based on your issue description, it's recommended that you try the steps of chapter 6.16.2 of AN12196. For example: 1. Authentication by keyNo 0x00 2. input the New key  3. execute ChangeKey command 4. double check using the new key to authenticate NTAG424. BR Kelly Re: NTAG 424 no login possible after key 0 change Some more info: i know is not correct but i use the same RndA in all login before change the keys. I can't identify the root of the issue, but if i use 5 different RndA in login, no problems with keys (even K0), if i use the same RndA in login, K0 is corrupted. So for now the problem is solved, without knowing the cause.
記事全体を表示
ATF 搭載の S32G Linux で拡散スペクトル用にクロックを調整 Linux BSPチームの皆さん、こんにちは。 お客様から、ATF を使用して Linux BSP のクロック拡散スペクトル設定を調整する方法についてのガイダンスを問い合わせがありました。 S32G の最新 BSP を確認しましたが、次のクロック拡散スペクトル関連の PLL 周波数変調 (PLLFM) レジスタ構成が見つかりません。 私の質問は、このサポートを Linux BSP に追加する予定があるかどうかです。 よろしくお願いいたします。 天祥 Linux BSP Re: S32G Linux with ATF adjust clock for spread spectrum 理論上はダウンスプレッドされないため 1516MHz (DS 値は 1600MHz よりわずかに低い) でしか動作しない拡散スペクトルではなく (そうでない場合は DDR をオーバークロックすることになります)、Valeo は SS に比べて実装が簡単なため、DDR 周波数を 1590MHz (1600MHz にかなり近い) に移動することにしました。ただし、1590MHz は DS およびキャリブレーション ツールには含まれていないため、自己責任となります。こちらがその記事です: [S32G] DDR周波数を1590MHzに変更し、20ユーロのSDRドングルで結果を測定します Re: S32G Linux with ATF adjust clock for spread spectrum こんにちは、ゲナディさん。 わかりました。すぐに確認していただきありがとうございます。 よろしくお願いいたします。 天祥 Re: S32G Linux with ATF adjust clock for spread spectrum こんにちは@Tianxiang_Huangさん 現在のところ、DDR PLL 周波数変調のクロック拡散スペクトルはサポートされておらず、近いうちに追加される予定もありません。これが 1 人以上のクライアントに関係するCASEには、詳細な変更リクエストが必要です。TF-A はこのツールによって生成されたコードを統合するため、DDR 関連の変更はすべて DDR ツールと同期する必要があることに注意してください。 よろしくお願いいたします。 ゲナディ
記事全体を表示
NTAG 424 キー0の変更後にログインできない こんにちは、皆さん。 解決できない奇妙な動作に直面しています。セキュリティプラットフォーム用の#NTAG424を構成するためのすべての手順を完了しました。すべて正常ですが、最後に1つあります。 5 つのキーをすべて変更する必要があり、4 から 0 までのこの「ループ」から開始しました。 キー0でログイン キーXを変更 K0 の変更は K4-1 とは異なり、応答は 91-00 です。SO すべてが正しいようです。 ここで問題があります。すべてのキーを 4-1 でログインCANますが、K0 ではログイン パート 2 で 91-AE になります。 暗号化が間違っているため、キーが私の考えと異なると思いますが、コードを何度もチェックしたところ、問題ありませんでした。データシートと AN12196 に従って暗号文の計算のみを変更しました。 何かヒントはありますか? お返事をよろしくお願いします。 Re: NTAG 424 no login possible after key 0 change こんにちは@MPucci 、 投稿に ChangeKey 0 と 1-4 を既に実装しましたか?現在これを実装中ですが、いくつか問題が発生しています。Key1-4 を 911E に応答するように正常に変更することができず、Key0 を変更した後、認証応答は 91AE になります。あなたに助けていただきたく存じます。 Re: NTAG 424 no login possible after key 0 change こんにちは@KaiLi AN12196 に 6.16.2 が見つかりませんでした。文書のバージョンが違うからでしょうか? 何かヒントはありますか? ご回答をお待ちしています。 Re: NTAG 424 no login possible after key 0 change こんにちは@MPucci お問い合わせいただきありがとうございます。問題の説明に基づいて、AN12196 の第 6 章.16.2 の手順を試すことをお勧めします。例えば: 1. キー番号0x00による認証 2. 新しいキーを入力します 3. ChangeKeyコマンドを実行する 4. 新しいキーを使用してNTAG424を認証します。 BR ケリー Re: NTAG 424 no login possible after key 0 change さらに詳しい情報: 正しくないことはわかっていますが、キーを変更する前は、すべてのログインで同じ RndA を使用しています。問題の根本原因を特定することはできませんが、ログイン時に 5 つの異なる RndA を使用するとキーに問題はありません (K0 も)。ログイン時に同じ RndA を使用すると、K0 が破損します。 SO、今のところ、原因は分からないまま、問題は解決しました。
記事全体を表示
MX8QM recommended PMIC I am planning a design based on the MX8QM processor. We will be using the following interfaces  A72 2x cores  PCIe interface  eMMC interface  Ethernet interface We will not use the GPU, VPU, display etc. On the PMIC selection page, https://www.nxp.com/products/power-management/pmics-and-sbcs:POWR_MAN_USER_INTERFACE the device recommended is PF81-PF82 which according to the product page is Not Recommended. So what is the recommended device? Could we use PCA9450C  ? Regards i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Re: MX8QM recommended PMIC Hello, Unfortunately, there are no replacement part numbers for PF81-PF82 from NXP. I suggest you look for third-party solutions as: Integrated Power Supply Design for NXP i.MX8 QuadMax Processor Also, PCA9450 PMIC is not compatible for i.MX8QM since power requirements are higher current power consumption and different power-up/power-off sequences compared to i.MX8MN/M/P processors. Keep in mind that PF81-PF82 product family is part of our Longevity program until May 2034 Best regards.
記事全体を表示
S32G Linux with ATF adjust clock for spread spectrum Hi Linux BSP team, Customer inquired the guidance on how to adjust the clock spread spectrum settings in the Linux BSP with ATF. I checked S32G latest BSP, the following clock spread spectrum related PLL Frequency Modulation(PLLFM)register configuration is not found. My question is that do we have the plan to add this support in Linux BSP? BRs, Tianxiang Linux BSP Re: S32G Linux with ATF adjust clock for spread spectrum Rather than spread spectrum that can in theory only works at 1516MHz (DS value just below 1600MHz) as it is not down-spread, meaning you overclock you DDR otherwise, Valeo has decided to simply move the DDR freq to 1590MHz (far closer to 1600MHz) as it is easier to implement compared to SS. But as 1590MHz, is not in the DS and calibration tool, it is at their own risk. Here is the article: [S32G] change the DDR frequency to 1590MHz and measure the results with a 20€ SDR dongle Re: S32G Linux with ATF adjust clock for spread spectrum Hi Ghennadi, Got it, thanks for the quick confirmation. BRs, Tianxiang Re: S32G Linux with ATF adjust clock for spread spectrum Hi @Tianxiang_Huang , As of today, the clock spread spectrum for DDR PLL Frequency Modulation is not supported, and it is not planned to be added anytime soon. A detailed change request is needed in case this is relevant for one or more clients. Please take into account that any DDR-related change has to be synchronized with DDR tool given that TF-A integrates the code generated by this tool.  Regards, Ghennadi
記事全体を表示
iMXRT10xx SDK MCUBoot 版本 您好, 我正在使用带有 MCUXpresso SDK 24.12.00 的 imxRT1021 MCU 和 McuBoot 作为 SDK 的中间件元器件。 有办法知道 SDK 包含哪个 MCUBoot 版本吗? 我在代码中进行了搜索,但没有为 MCUBoot 定义任何版本... 谢谢您! Re: iMXRT10xx SDK MCUBoot version 你好! 刚刚在 SDK 文档中找到了 McuBoot 版本说明:应该是 2.0.0 MCUboot 版本说明 — MCUXpresso SDK 文档
記事全体を表示
OpenSSL 无法正确处理 refpem 密钥,nxp 方案正常工作 大家好, 我正在尝试集成 SE050 以便在 node.js 网络服务器中使用。我成功编译了包括 OpenSSL 提供商在内的中间件,还让 sscli 正常工作。 我使用 ssscli 创建了一个密钥对,将其注入 SE 并创建了一个 refpem 密钥。我还修改了系统的 openssl.cnf 文件,使其与 simwtop/demos/linux/common/openssl30_sss_se050.cnf 文件中的一致。 但是,与服务器的任何 TLS 连接都会在握手中失败,因为 OpenSSL 使用对密钥槽的参考作为实际私钥,而不是调用 SE050 提供商。 我还尝试让它与 OpenSSL CLI(即 openssl s_server)配合使用。我可以使用 nxp: 方案获得连接,但不能使用 refpem 密钥文件。 以下命令会导致错误: openssl s_server -accept 12345 -cert server.pem -key server.refpem.key -CAfile root.pem 错误: SSL3 alert read:fatal:decrypt error SSL_accept:error in error ERROR 20203CA4FFFF0000:error:1B80006E:lib(55):ossl_parse_query:trailing characters:../openssl-3.0.13/crypto/property/property_parse.c:454:HERE-->/usr/lib/libsssProvider.so 20203CA4FFFF0000:error:0A00041B:SSL routines:ssl3_read_bytes:tlsv1 alert decrypt error:../openssl-3.0.13/ssl/record/rec_layer_s3.c:1590:SSL alert number 51 shutting down SSL 不过,如果我使用 nxp 网址方案,就能成功连接到服务器。 openssl s_server -accept 12345 -cert server.pem -key nxp:0x6789ABCD -CAfile root.pem 但是,我无法在 node.js 代码中指定 nxp: 0x6789ABCD 密钥参考,但必须使用 refpem 文件。有办法做到这一点吗? 我还尝试通过在配置文件中指定一个 propquery,让 OpenSSL 优先使用 SE050 提供程序,而不是默认提供程序。但目前还没有收获。 # Relevant parts from openssl.cnf [openssl_init] providers = provider_sect alg_section = evp_properties [provider_sect] default = default_sect nxp_prov = nxp_prov_sec [default_sect] activate = 1 [nxp_prov_sec] identity = nxp_prov module = /usr/local/lib/libsssProvider.so activate = 1 [evp_properties] default_properties = ?provider=nxp_prov 如能得到任何帮助,将不胜感激! SE050 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 我忘了说,我使用的 Node 版本是 20.12.2。 ,20.x 之后的版本可能没有这个问题,但我目前无法验证。 经过进一步调查,发现客户端解密问题是由于提供程序加载顺序不正确造成的。 不过,这个版本的 Node 在处理随机数生成方面存在问题。 问题与 Node 如何初始化提供程序有关。 node.cc 文件包含一个修复程序(在源代码中带有注释),但它不适用于 libsssProvider.so。 我在此分享一系列变通方法,以防有人遇到类似情况。 首先,我要说的是,这些都与 libsssProvider 有关,主要目的是不更改 Node 或 OpenSSL,因此显然可以采用其他更简洁的解决方案。 我不能分享代码,希望下面的信息足够清楚。 可用选项: 1.在 CMakeLists.txt 文件中,设置 SSS_PROV_DISABLE_SE05X_RNG 变量。 这就完全禁止了 SE05X 的随机使用。 这并不理想,但如果你没有任何特殊需要,它还是可行的。 2.在 sssProvider_main.c 中文件,更改 srands 结构的算法,使提供的名称不是已知名称之一(尤其不是默认名称)。 3. 与第 2 点类似,但在这种情况下,名称可选择由环境变量提供(srands 显然不能是常量)。这样,只有在 Node 应用程序中才能避免使用 SE05X 随机发生器,而将其用于其他用途。 有了这些选项, refpems 可以正常工作。 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 我遇到了与@tksec 完全相同的问题。 如果使用 OpenSSL cli 工具,一切正常,我可以通过 libsssProvider.so 使用 SE052 模块中的密钥建立 TLS 连接。 关于 Node.js、我确认 libsssProvider 已加载,但握手总是失败,错误如下: SSL3 alert write:fatal:decrypt error SSL_connect:error in error 20109DB6FFFF0000:error:0A00007B:SSL routines:tls_process_cert_verify:bad signature:/usr/src/debug/openssl/3.2.1/ssl/statem/statem_lib.c:584: @Kan_Li所建议的通过 id 调用键似乎并不奏效: - 如果我在 options.key 中提供 refpem 文件的路径,服务器就能顺利启动并监听连接,但正如报告所述,握手失败。 - 如果我在 options.key 中提供 urk 密钥路径(nxp: ),应用程序就会崩溃。 -如果我在 options.key 中提供密钥参考 (nxp: ) 应用程序会崩溃 那么,能否请@Kan_Li分享一段可以成功初始化服务器的 Node.js 代码,假设如上所述,这应该可以正常工作? 谢谢! Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 嗨 @tksec, 你找到在 node.js 中使用密钥参考的合适方法了吗? 我也有类似的问题。我正在使用带有 OpenSSL 3.0.14 的 se05x-openssl-provider (v01.00.03) 来生成密钥对,但我无法按照 openssl 提供商 Github 仓库自述文件中的描述使用文件格式为 " 的 " 参考密钥。 其他两个版本(带有参考密钥的标签(示例-恩智浦:" 参考密钥文件路径 ")和带有密钥 ID 的 标签(示例-nxp: 0x12345678)运行良好。 自述文件内容如下:" 注意:使用此方法时,必须先加载 sss 提供程序。这将确保 sss 提供商可以解码引用密钥中存在的密钥 ID 信息 。 " 遗憾的是,我不知道如何做到这一点。通过在 openssl.cnf 文件中添加提供程序来加载提供程序对我来说不起作用。如果我想使用文件格式的参考密钥,我仍然会遇到解密错误。 在此先表示感谢。 致以最诚挚的问候 托马斯 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 你好@tksec、 感谢您提供的信息!您使用 refpem 文件的用例是什么?签署&验证?我可以尝试在这里重现这个问题。 顺祝商祺! 坎 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 你好@Kan_Li、 是的,我使用了 ssscli 工具。我运行的是 MW v4.05.00。我在另一个系统上用 OpenSSL 创建了原始密钥。使用 ssscli set 命令将其加载到 SE 中,并使用 ssscli refpem 命令创建 refpem。在使用 s_client、s_server、rsa 等 openssl 命令时,可以成功使用和解析该密钥。也可以使用 OSSL_STORE API(openssl 命令的内部功能)将其转换为 EVP_PKEY,但使用 PEM_read_bio_PrivateKey 无法解析,而 NXP 引擎(在 EmbSe_LoadPrivKey 中)和 node.js 都使用 PEM_read_bio_PrivateKey。 谢谢您! Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 你好@tksec、 您是如何为 RSA 密钥生成 refpem 的?您现在使用的是哪个版本的 MW?请予以澄清。 祝您愉快, Kan ------------------------------------------------------------------------------- 注: - 如果本帖回答了您的问题,请点击"标记正确" 按钮。谢谢! - 我们会在最后一次发帖后的 7 周内跟踪主题,之后的回复将被忽略 如果您以后有相关问题,请另开新主题,并参考已关闭的主题。 ------------------------------------------------------------------------------- Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 你好@Kan_Li 谢谢你说明 refpem 密钥只能用于 openssl 引擎。特别是 node.js 的问题在于,它们会直接对提供的任何密钥字符串调用 PEM_read_bio_PrivateKey 函数,而当密钥字符串不是 PEM 字符串或文件路径而是 uri 时,该函数显然会失效。目前还没有对 OpenSSL 提供商的直接支持。 我改回使用 OpenSSL 引擎,结果也遇到了类似的问题。使用 EC 密钥时工作正常,而使用 RSA 密钥时,在解析 PEM 文件时再次出现错误:1E08010C:DECODER routines::unsupported from OpenSSL。我调试了代码,可以将错误追溯到 PEM_read_bio_PrivateKey 函数,该函数在引擎代码中的 EmbSe_LoadPrivKey 中调用。 您知道在 OpenSSL 引擎中处理 RSA refpem 密钥的问题吗?如何解决这个问题?在我看来,RSA 的 refpem 比 EC 密钥的侵入性更强,这可能是个问题? Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 你好@tksec、 refpem 密钥文件仅适用于 openssl 引擎,但由于您使用的是带有提供程序的 openssl 3.xx,因此请使用"nxp:key_id" 代替。你可以将"se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient.sh" 与"se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient_3_0.sh" 进行比较,检查两者的区别。 我还想知道你对此是否有任何网络安全问题,实际上从我的选择来看,它只是大多数脚本应该接受的字符串,为什么不能在 node.js 代码中指定 nxp: 0x6789ABCD 密钥参考?请澄清。 祝您愉快, Kan ------------------------------------------------------------------------------- 注: - 如果本帖回答了您的问题,请点击"标记正确" 按钮。谢谢! - 我们会在最后一次发帖后的 7 周内跟踪主题,之后的回复将被忽略 如果您以后有相关问题,请另开新主题,并参考已关闭的主题。 -------------------------------------------------------------------------------
記事全体を表示
iMX91プロセッサ上でOPTEEを構築およびテストする方法 こんにちは、 OPTEE の機能を理解しようとしています。以下のサポートをリクエストします: 1.OPTEEドキュメント/チュートリアルiMX91 2.YOCTO を使用して iMX91 プロセッサ上で OPTEE を構築およびテストする方法。 現在、YOCTOベースを開発しています - repo init -u https://github.com/nxp-imx/imx-manifest-b imx-linux-styhead -m imx-6.12.3-1.0.0_セキュリティリファレンスデザイン.xml 生成されたファイルのリストは以下をご覧ください。 ls tmp/deploy/images/imx91-11x11-lpddr4-evk ├── bl31-imx91.bin ├── bl31-imx91.bin-optee ├── core-image-base.env ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.manifest ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.spdx.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.testdata.json ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.bmap ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.manifest -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.manifest ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.spdx.tar.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.spdx.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.tar.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.testdata.json -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.testdata.json ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.wic.bmap -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.bmap ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.wic.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.zst ├── core-image-base-imx-imx-boot-bootpart.wks ├── core-image-minimal-secure-boot.env ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.manifest ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.spdx.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.testdata.json ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.bmap ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.manifest -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.manifest ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.spdx.tar.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.spdx.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.tar.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.testdata.json -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.testdata.json ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.wic.bmap -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.bmap ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.wic.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.zst ├── core-image-minimal-secure-boot-imx-imx-boot-bootpart.wks ├── files.txt ├── flash.bin ├── flash_os.bin ├── Image -> Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── Image-imx91-11x11-lpddr4-evk.bin -> Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── imx91-11x11-evk--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk.dtb ├── imx91-11x11-evk-aud-hat--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk-aud-hat-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk.dtb ├── imx91-11x11-evk-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk.dtb ├── imx91-11x11-evk-ld--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-ld-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-lpuart--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-lpuart-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-mt9m114--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-mt9m114-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-tianma-wvga-panel--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx91-11x11-evk-tianma-wvga-panel-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx-boot -> imx-boot-tagged ├── imx-boot-imx91-11x11-lpddr4-evk-sd.bin-flash_singleboot ├── imx-boot-tagged ├── imx-boot.tagged ├── imx-boot-tools │ ├── bl31-imx91.bin │ ├── bl31-imx91.bin-optee │ ├── csf_ahab.cfg.sample │ ├── csf_hab4.cfg.sample │ ├── imx_signer │ ├── lpddr4_dmem_1d_v202201.bin │ ├── lpddr4_dmem_2d_v202201.bin │ ├── lpddr4_imem_1d_v202201.bin │ ├── lpddr4_imem_2d_v202201.bin │ ├── mkimage_imx8 │ ├── mx91a0-ahab-container.img │ ├── soc.mak │ ├── spsdk_ahab.cfg.sample │ ├── tee.bin │ ├── u-boot-imx91-11x11-lpddr4-evk.bin-sd │ └── u-boot-spl.bin-imx91-11x11-lpddr4-evk-sd ├── imx-boot-untagged ├── lpddr4_dmem_1d_v202201.bin ├── lpddr4_dmem_2d_v202201.bin ├── lpddr4_imem_1d_v202201.bin ├── lpddr4_imem_2d_v202201.bin ├── modules--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.tgz ├── modules-imx91-11x11-lpddr4-evk.tgz -> modules--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.tgz ├── mx91a0-ahab-container.img ├── optee │ ├── ta │ │ ├── 023f8f1a-292a-432b-8fc4-de8471358067.elf │ │ ├── 023f8f1a-292a-432b-8fc4-de8471358067.stripped.elf │ │ ├── 02a42f43-d8b7-4a57-aa4d-87bd9b5587cb.elf │ │ ├── 02a42f43-d8b7-4a57-aa4d-87bd9b5587cb.stripped.elf │ │ ├── 25497083-a58a-4fc5-8a72-1ad7b69b8562.elf │ │ ├── 25497083-a58a-4fc5-8a72-1ad7b69b8562.stripped.elf │ │ ├── 380231ac-fb99-47ad-a689-9e017eb6e78a.elf │ │ ├── 380231ac-fb99-47ad-a689-9e017eb6e78a.stripped.elf │ │ ├── 528938ce-fc59-11e8-8eb2-f2801f1b9fd1.elf │ │ ├── 528938ce-fc59-11e8-8eb2-f2801f1b9fd1.stripped.elf │ │ ├── 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.elf │ │ ├── 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.stripped.elf │ │ ├── 5c206987-16a3-59cc-ab0f-64b9cfc9e758.elf │ │ ├── 5c206987-16a3-59cc-ab0f-64b9cfc9e758.stripped.elf │ │ ├── 5ce0c432-0ab0-40e5-a056-782ca0e6aba2.elf │ │ ├── 5ce0c432-0ab0-40e5-a056-782ca0e6aba2.stripped.elf │ │ ├── 731e279e-aafb-4575-a771-38caa6f0cca6.elf │ │ ├── 731e279e-aafb-4575-a771-38caa6f0cca6.stripped.elf │ │ ├── 80a4c275-0a47-4905-8285-1486a9771a08.elf │ │ ├── 80a4c275-0a47-4905-8285-1486a9771a08.stripped.elf │ │ ├── 873bcd08-c2c3-11e6-a937-d0bf9c45c61c.elf │ │ ├── 873bcd08-c2c3-11e6-a937-d0bf9c45c61c.stripped.elf │ │ ├── 8aaaf200-2450-11e4-abe20002a5d5c51c.elf │ │ ├── 8aaaf200-2450-11e4-abe20002a5d5c51c.stripped.elf │ │ ├── a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.elf │ │ ├── a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.stripped.elf │ │ ├── a720ccbb-51da-417d-b82e-e5445d474a7a.elf │ │ ├── a720ccbb-51da-417d-b82e-e5445d474a7a.stripped.elf │ │ ├── b3091a65-9751-4784-abf7-0298a7cc35ba.elf │ │ ├── b689f2a7-8adf-477a-9f99-32e90c0ad0a2.elf │ │ ├── b689f2a7-8adf-477a-9f99-32e90c0ad0a2.stripped.elf │ │ ├── c3f6e2c0-3548-11e1-b86c-0800200c9a66.elf │ │ ├── c3f6e2c0-3548-11e1-b86c-0800200c9a66.stripped.elf │ │ ├── cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.elf │ │ ├── cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.stripped.elf │ │ ├── d17f73a0-36ef-11e1-984a-0002a5d5c51b.elf │ │ ├── d17f73a0-36ef-11e1-984a-0002a5d5c51b.stripped.elf │ │ ├── e13010e0-2ae1-11e5-896a-0002a5d5c51b.elf │ │ ├── e13010e0-2ae1-11e5-896a-0002a5d5c51b.stripped.elf │ │ ├── e6a33ed4-562b-463a-bb7e-ff5e15a493c8.elf │ │ ├── e6a33ed4-562b-463a-bb7e-ff5e15a493c8.stripped.elf │ │ ├── f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.elf │ │ ├── f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.stripped.elf │ │ ├── f157cda0-550c-11e5-a6fa-0002a5d5c51b.elf │ │ ├── f157cda0-550c-11e5-a6fa-0002a5d5c51b.stripped.elf │ │ ├── fd02c9da-306c-48c7-a49c-bbd827ae86ee.elf │ │ ├── fd02c9da-306c-48c7-a49c-bbd827ae86ee.stripped.elf │ │ └── ffd2bded-ab7d-4988-95ee-e4962fff7154.elf │ ├── tee.bin │ ├── tee.elf │ ├── tee-header_v2.bin │ ├── tee.mx91evk.bin │ ├── tee-pageable_v2.bin │ ├── tee-pager_v2.bin │ └── tee-raw.bin ├── os_cntr_signed.bin ├── signed-imx-boot-imx91-11x11-lpddr4-evk-sd.bin-flash_singleboot ├── tee.bin -> optee/tee.mx91evk.bin ├── u-boot.bin -> u-boot-sd-2024.04-r0.bin ├── u-boot.bin-sd -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx91-11x11-lpddr4-evk.bin -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx91-11x11-lpddr4-evk.bin-sd -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd -> u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-imx-initial-env-sd -> u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-sd-2024.04-r0.bin ├── u-boot-spl.bin -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-imx91-11x11-lpddr4-evk -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-imx91-11x11-lpddr4-evk-sd -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-sd -> u-boot-spl.bin-sd-2024.04-r0 └── u-boot-spl.bin-sd-2024.04-r0 4 directories, 153 files よろしくお願いします キラン Re: How to Build & Test OPTEE on iMX91 processor こんにちは@KiranM7 ! NXP サポートにお問い合わせいただきありがとうございます。 OP-TEE は BSP でデフォルトで有効になっています。現在、 optee-test を実行するための公式ガイドはありませんが、詳細な手順については公式の OP-TEE ドキュメントを参照してください。 optee_test よろしくお願いします、 チャビラ
記事全体を表示
OpenSSL は refpem キーを正しく処理しませんが、nxp スキームは機能しています こんにちは、皆さん。 SE050 を node.js Web サーバーで使用できるように統合しようとしています。OpenSSL プロバイダーを含むミドルウェアを正常にコンパイルし、ssscli も動作するようになりました。 ssscli を使用してキー ペアを作成し、それを SE に挿入して refpem キーを作成しました。また、システムの openssl.cnf を simwtop/demos/linux/common/openssl30_sss_se050.cnf のものと一致するように調整しました。 しかし、OpenSSL は SE050 プロバイダーを呼び出す代わりに、キー スロットへの参照を実際の秘密キーとして使用するため、サーバーへの TLS 接続はハンドシェイクで失敗します。 また、OpenSSL CLI (openssl s_server) でも動作するようにしてみました。nxp: スキームを使用して接続CANますが、refpem キー ファイルは使用できません。 次のコマンドを実行するとエラーが発生します。 openssl s_server -accept 12345 -cert server.pem -key server.refpem.key -CAfile root.pem エラー: SSL3 alert read:fatal:decrypt error SSL_accept:error in error ERROR 20203CA4FFFF0000:error:1B80006E:lib(55):ossl_parse_query:trailing characters:../openssl-3.0.13/crypto/property/property_parse.c:454:HERE-->/usr/lib/libsssProvider.so 20203CA4FFFF0000:error:0A00041B:SSL routines:ssl3_read_bytes:tlsv1 alert decrypt error:../openssl-3.0.13/ssl/record/rec_layer_s3.c:1590:SSL alert number 51 shutting down SSL ただし、nxp URL スキームを使用すると、サーバーに正常に接続 CAN ます。 openssl s_server -accept 12345 -cert server.pem -key nxp:0x6789ABCD -CAfile root.pem ただし、node.js コードで nxp:0x6789ABCD キー参照を指定することはCANず、refpem ファイルを使用する必要があります。それをなんとかする方法はあるでしょうか? また、設定ファイルでプロパティクエリを指定して、OpenSSL がデフォルトのプロバイダーよりも SE050 プロバイダーを優先するようにしてみました。しかし、今のところ運がない。 # Relevant parts from openssl.cnf [openssl_init] providers = provider_sect alg_section = evp_properties [provider_sect] default = default_sect nxp_prov = nxp_prov_sec [default_sect] activate = 1 [nxp_prov_sec] identity = nxp_prov module = /usr/local/lib/libsssProvider.so activate = 1 [evp_properties] default_properties = ?provider=nxp_prov どのようなご助力もいただければ幸いです。 SE050 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 私が使用している Node バージョンは 20.12.2 であることをお伝えするのを忘れました。 20.x 以降のバージョンではこの問題は発生しない可能性がありますが、現時点ではこれを確認する方法がありません。 さらに調査を進めたところ、クライアント側の復号化の問題は、プロバイダーの読み込み順序が間違っていたために発生したことが判明しました。 そうは言っても、このバージョンの Node では乱数生成の処理に問題があることが判明しました。 この問題は、Node がプロバイダーを初期化する方法に関連しています。 具体的には、乱数ジェネレータの初期化で、sss_rand_get_ctx_params への呼び出しの無限ループが発生します。 node.cc ファイルには修正が含まれています (ソースにコメントが含まれています) が、libsssProvider.so では機能しません。 同じような状況に陥った人のために、いくつかの回避策を紹介します。 まず、これらはすべて libsssProvider に関連しており、主に Node または OpenSSL を変更しないことを目的としているSO、他のよりクリーンなソリューションが可能であることは明らかだと述べます。 コードを共有することはできませんが、以下の情報が十分に明確であることを願います。 利用可能なオプション: 1.CMakeLists.txt ファイルで、SSS_PROV_DISABLE_SE05X_RNG 変数を設定します。 これにより、ランダムに対する SE05X の使用が完全に無効になります。 理想的ではありませんが、特別なニーズがない場合は機能します。 2. sssProvider_main.cファイルで、指定された名前が既知の名前 (特にデフォルトではない名前) にならないSO、srands 構造体のアルゴリズムを変更します。これにより、openssl 構成ファイルでランダム キーを設定することで、必要に応じて SE05X ランダム モジュールを使用できるようになります。 3. ポイント 2 と似ていますが、このCASE、名前はオプションで環境変数で提供されます (srands は明らかに定数にすることはCANません)。この方法では、Node アプリケーションの場合にのみ、SE05X 乱数ジェネレーターの使用を回避し、代わりに他の用途でアクティブなままにすることができます。 refpems はこれらのオプションで正しく動作します。 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 私も@tksecとまったく同じ問題を経験しています。 OpenSSL cli ツールを使用してすべてが正常であれば、libsssProvider.SO を介して SE052 モジュールのキーを使用する TLS 接続を確立でCAN。 Node.jsでは、libsssProvider がロードされていることを確認しましたが、以下のエラーのように、ハンドシェイクは常に失敗します。 SSL3 アラート書き込み:致命的:復号化エラー SSL_connect:エラーでエラー 20109DB6FFFF0000:エラー:0A00007B:SSLルーチン:tls_process_cert_verify:不正な署名:/usr/src/debug/openssl/3.2.1/ssl/statem/statem_lib.c:584: @Kan_Liが提案したように、ID でキーを参照することは実際には機能しないようです。 - options.key に refpem ファイルへのパスを指定すると、サーバーは問題なく起動し、接続をリッスンしますが、報告されているようにハンドシェイクは失敗します。 - options.key にキーパスを urk (nxp: ) として指定すると、アプリケーションがクラッシュします - options.key にキー参照 (nxp: ) を指定すると、アプリケーションがクラッシュします SO、 @Kan_Liさん、これが問題なく動作するはずであると仮定して、サーバーを正常に初期化できる Node.js コードを共有していただけますCANか? よろしくお願いします。 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working こんにちは@tksec 、 node.js でキー参照を使用する適切な方法を見つけましたか? 私も同様の問題を抱えています。OpenSSL 3.0.14 で se05x-openssl-プロバイダ (v01.00.03) を使用してキー ペアを生成していますが、openssl プロバイダの Github リポジトリの Readme ファイルに記載されている「ファイル形式の参照キー」を使用できません。 他の2つのバージョン(参照キー付きのラベリング(例:nxp:"参照キーファイルへのパス")と キー ID 付きのラベリング (例: nxp:0x12345678) は正常に機能します。 Readme には次のように記載されています。「注意: この方法を使用する場合は、まず sss プロバイダをロードする必要があります。これにより、sss プロバイダが参照キーに存在するキー ID 情報をデコードできます。 」 残念ながら、その方法が分かりません。プロバイダーを openssl.cnf ファイルに追加してロードしても機能しませんでした。ファイル形式で参照キーを使用しようとすると、依然として復号化エラーが発生します。 よろしくお願いします。 よろしくお願いします トーマス Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working こんにちは@tksec 、 情報ありがとうございます!refpem ファイルを使用するユースCASEは何ですか?署名と検証?ここでこの問題を再現してみようと思います。 よろしくお願いいたします。 カン Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working こんにちは@Kan_Liさん はい、ssscli ツールを使用しました。MW v4.05.00を実行しています。別のシステムで OpenSSL を使用して元のキーを作成しました。ssscli set コマンドを使用して SE にロードし、ssscli refpem コマンドで refpem を作成しました。s_client、s_server、rsa などの openssl コマンドを使用する場合、キーは正常に使用および解析CAN。これは、OSSL_STORE API (openssl コマンドが内部的に実行するもの) を使用して EVP_PKEY に変換することもCANますが、NXP エンジン (EmbSe_LoadPrivKey 内) と node.js の両方で使用される PEM_read_bio_PrivateKey を使用して解析することはできません。 よろしくお願いします! Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working こんにちは@tksec 、 RSA キーの refpem をどのように生成しましたか? ssscli のツールで?現在どのバージョンのMWを使用していますか?ご説明をよろしくお願いいたします。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記: - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう! - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 --------------------------------------------------------------------------------- Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working こんにちは@Kan_Li refpem キーは openssl エンジンでのみ使用可能であることを明確にしていただきありがとうございます。特に node.js の問題は、提供されたキー文字列に対して PEM_read_bio_PrivateKey 関数を直接呼び出すことです。キー文字列が PEM 文字列やファイル パスではなく uri の場合、明らかに失敗します。OpenSSL プロバイダーに対する直接的なサポートはまだありません。 代わりに OpenSSL エンジンの使用に戻しましたが、同様の問題が発生しました。EC キーの使用は完全に機能しますが、RSA キーを使用すると、OpenSSL からのエラー:1E08010C:DECODER routines::unsupported が発生し、PEM ファイルの解析中に再び失敗します。コードをデバッグしたところ、エンジンのコード内の EmbSe_LoadPrivKey 内から呼び出される関数 PEM_read_bio_PrivateKey にエラーが遡って発生していることがわかりました。 OpenSSL エンジンで RSA refpem キーを処理する際にこのような問題が発生することをご存知ですか?これをどう解決すればいいでしょうか?私の場合、refpem は EC キーよりも RSA キーに対してより侵入的であるように見えますが、これが問題になるでしょうか? Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working こんにちは@tksec 、 refpem キー ファイルは openssl エンジン専用ですが、プロバイダーで openssl 3.xx を使用するため、代わりに "nxp:key_id" を使用してください。「se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient.sh」と「se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient_3_0.sh」を比較して違いを確認することができます。また、これに関してセキュリティ上の懸念事項はございますでしょうか。私の見解では、これはほとんどのスクリプトで受け入れられる文字列であるはずですが、なぜNode.jsコードでnxp:0x6789ABCDキー参照を指定できないのでしょうか?ご説明いただけますでしょうか。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記: - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう! - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 ---------------------------------------------------------------------------------
記事全体を表示