MCUXpresso Secure Provisioning Tool (SEC) is a graphical user interface (GUI) tool covering secure boot process and Trust Provisioning capabilities, primarily aimed at microcontroller customers. It provides unified GUI front-end over existing command-line tools (elftosb, blhost, sdphost, cst, pfr, tpconfig, tphost).
Features
Downloads
Supported Operating Systems:
Revision History
6.0
Known problems and limitations
id:mcux-secure-tool
HI Marek, that's on macOS 13.1 (Ventura; darwin 22.2.0).
I know the documentation states only Mac OS 12.4 Monterey is supported, but downgrading to Monterey doesn't seem likely to fix this, given the nature of the error.
Thanks, but it seems the "MAC" version does not launch.
Looking at the error messages, it seems it does not work on recent (arm64-based) Macs:
MCUXpresso Secure Provisioning v6.app % ./Contents/MacOS/securep
INFO: [root] workspace /Users/ivo/secure_provisioning
WARNING: [root] Loading settings from workspace: No settings file found
Traceback (most recent call last):
File "PyInstaller/loader/pyimod03_ctypes.py", line 53, in __init__
File "ctypes/__init__.py", line 374, in __init__
OSError: dlopen(/var/folders/mm/9yxjtsmj5r743v3ps_zmz6n80000gn/T/tmp4j8_kunq.dylib, 0x0006): tried: '/var/folders/mm/9yxjtsmj5r743v3ps_zmz6n80000gn/T/tmp4j8_kunq.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/System/Volumes/Preboot/Cryptexes/OS/var/folders/mm/9yxjtsmj5r743v3ps_zmz6n80000gn/T/tmp4j8_kunq.dylib' (no such file), '/var/folders/mm/9yxjtsmj5r743v3ps_zmz6n80000gn/T/tmp4j8_kunq.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/private/var/folders/mm/9yxjtsmj5r743v3ps_zmz6n80000gn/T/tmp4j8_kunq.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/System/Volumes/Preboot/Cryptexes/OS/private/var/folders/mm/9yxjtsmj5r743v3ps_zmz6n80000gn/T/tmp4j8_kunq.dylib' (no such file), '/private/var/folders/mm/9yxjtsmj5r743v3ps_zmz6n80000gn/T/tmp4j8_kunq.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))
Hello Ivo,
SEC is built for Intel architecture. The first Mac for M1 had an emulator (Rosetta) installed by default. Unfortunately the next versions comes without Rosetta and users have to install it manually. I do not have Mac M1 available, could you please try this: https://support.apple.com/en-us/HT211861
or search other resources for installing Rosetta?
Best regards,
Libor
I'm afraid that despite Rosetta 2 being installed, it still fails with arm64/x86_64 errors even if invoked with "arch -x86_64 /Applications/MCUX_Provi_v6/MCUXpresso\ Secure\ Provisioning\ v6.app/Contents/MacOS/securep"
No big deal, I'll just use a Linux box.
Hello Ivo,
we have identified that the issue is integration between Secure Provisioning Python JLink package and installed SEGGER J-Link SW. Most probably you have installed only M1 version of SEGGER J-Link. If "Universal installer" is used (that contains both Intel and Arm architecture), then Secure Provisioning Tool (SEC) works even on Mac M1 (please mind that at this moment it is not a supported platform, and it will be addressed in the future versions of SEC).
https://www.segger.com/downloads/jlink/
Regards,
Libor
This work around doesn't work. When will Mac M1 be supported? v7 still does not support Mac M1...
Hello Scott,
M1 will have native support in the following v8 (mid Q1 2024). Could you please execute the `securep` executable from the terminal and paste here the error, so I can see whether it is above mentioned problem or something different?
Thank you,
Libor
It's unfortunate it will take so long for a fix since the Mac arm64 has been out for quite some time now. Is it open source, could I compile the app myself?
Here is the error:
"
Traceback (most recent call last):
File "PyInstaller/loader/pyimod03_ctypes.py", line 53, in __init__
File "ctypes/__init__.py", line 374, in __init__
OSError: dlopen(/var/folders/gl/4qfmnn7s10l2s624c_mmlldr0000gn/T/tmpi7dou0_w.dylib, 0x0006): tried: '/var/folders/gl/4qfmnn7s10l2s624c_mmlldr0000gn/T/tmpi7dou0_w.dylib' (mach-o file, but is an incompatible architecture (have (arm64), need (x86_64))), '/private/var/folders/gl/4qfmnn7s10l2s624c_mmlldr0000gn/T/tmpi7dou0_w.dylib' (mach-o file, but is an incompatible architecture (have (arm64), need (x86_64)))"
Hi Scott,
if you run SEC tool as Intel application under Rosetta, all used libraries must be installed for Intel architecture. The SEC tool fails if it invokes any library for M1 architecture.
From your log, it is not clear, which library is failing. If you can find this, you can replace/re-install it.
Hi Scott,
on clean Intel Mac OS with the Rosetta the SEC can be executed (even it is not officially supported). There must be something interfering (brew? other python?) on your machine, that is not obvious from the console output.
I'm afraid you have to wait for v8, or do a workaround with a virtualization like UTM, VirtualBox, etc.
Regards,
Libor
I am trying to use this on a ARM Mac, not an Intel Mac... My machine is clean, technically only a month old, fresh install of Mac Sonoma 14.1 on a Mac Studio M2 Ultra...
Hi Scott,
It's unfortunate it will take so long for a fix since the Mac arm64 has been out for quite some time now. Is it open source, could I compile the app myself?
No, it is not an open source.
OSError: dlopen(/var/folders/gl/4qfmnn7s10l2s624c_mmlldr0000gn/T/tmpi7dou0_w.dylib, 0x0006): tried: '/var/folders/gl/4qfmnn7s10l2s624c_mmlldr0000gn/T/tmpi7dou0_w.dylib' (mach-o file, but is an incompatible architecture (have (arm64), need (x86_64))), '/private/var/folders/gl/4qfmnn7s10l2s624c_mmlldr0000gn/T/tmpi7dou0_w.dylib' (mach-o file, but is an incompatible architecture (have (arm64), need (x86_64)))"
The folder and file names are cryptic so I'm unable to tell what library is in conflict with the Secure Provisioning Tool, but symptoms are similar. Secure Provisioning Tool running under Rosetta as x86_64, finds a library arm64 only.
Could you please check if you have set DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH?
set | grep DYLD
and if yes, unset them by
unset DYLD_LIBRARY_PATH
unset DYLD_FALLBACK_LIBRARY_PATH
and from the same terminal execute the ./securep ? There might be a library that interferes with the Secure Provisioning. I must say it is a shot in the dark, still worth to try it.
Regards,
Libor
Sorry, nothing comes up with: "set | grep DYLD"...
Hi Ivo,
what Mac OS version is it?