Support mac-arm64 properly #72
Comments
This should improve the development experience on mac-arm64 systems (Apple Silicon, M1 and later CPUs) by using toolchain and OpenOCD builds for that architecture, rather than relying on binary translation of the mac-x86_64 tools. mac-arm64 tools are only added to the current versions of these packages in this index: xpack-arm-none-eabi-gcc 13.2.1-1.1, and xpack-openocd 0.12.0-4, both as used in the current STM32 platform version, 2.9.0. Future versions should continue to offer mac-arm64 builds in this package index. Link: stm32duino#72 Signed-off-by: Mark Mentovai <mark@mentovai.com>
|
Hi @markmentovai
|
This provides a rebuild of all macOS executables. For reproducibility, this was done entirely by `build_mac.sh`. I verified that different machines produce bit-for-bit identical output. A build machine running Xcode 16.2 16C5032a on macOS 15.2 24C101 was used. These tools should run on macOS 10.13 and later. This version was selected as it's the minimum macOS version that the xPack tools declare support for. A build of libusb is included, so that the provided `dfu-util` no longer has an external dependency. The universal structure was chosen for these tools to avoid changing paths, anywhere they may be relied on. If desired, `build_mac.sh` can also be used to produce single-architecture tools, even cross-compiling, depending on the value of the `ARCH` variable. The current released versions were selected: - libusb 1.0.27 - dfu-util 0.11 (including dfu-prefix and dfu-suffix) - hid-flash from STM32_HID_Bootloader 2.2.2 (this program erroneously reports its version as 2.2.1), with a patch from Serasidis/STM32_HID_Bootloader#68 (comment). - upload_reset from this repository at the HEAD of main Link: stm32duino/BoardManagerFiles#72 Signed-off-by: Mark Mentovai <mark@mentovai.com>
|
Hi, Frederic. I’ve provided builds of all of the macOS tools in https://github.com/stm32duino/Arduino_Tools/ at stm32duino/Arduino_Tools#104. These are “universal” or “fat” binaries that contain both mac-x86_64 and mac-arm64 code. I’ve included the script that I used to build them, so that the builds are reproducible, and can be repeated easily in the future as things evolve. Cross-architecture builds are supported, so even if the only Apple you have is a mac-x86_64 system, you can do this build too with a new enough toolchain. (I used the current version, Xcode 16.2 on macOS 15.2, and took steps to ensure that the resulting executables will work on systems as old as macOS 10.13.) I also verified that I got bit-for-bit identical results by repeating the build on another system. One other change is that I’ve included a build of libusb alongside the tools, to eliminate the tricky external dependency in You mentioned |
|
Hi @markmentovai |
At present, development on mac-arm64* uses the mac-x86_64 tools, including the xPack toolchain. Although Apple makes binary translation available (under the name Rosetta), it produces suboptimal performance. Rosetta is not a bundled part of macOS, it’s an optional download, so not all mac-arm64 systems will even have it available. It’s also more difficult to debug and troubleshoot non-native code, and it leads to frustrating conflicts. For example,
dfu-utilfrom STM32Tools depends on/opt/local/lib/libusb-1.0.0.dylib, which if present on a mac-arm64 system is probably going to be a mac-arm64 library, and can’t be loaded into the mac-x86_64dfu-utilprocess. This produces an unusabledfu-utilon mac-arm64 systems without further (and very fiddly) intervention.Arduino’s package infrastructure falls back from mac-arm64 to mac-x86_64 and finally mac-x86, which is how these mac-x86_64 packages now advertised by STM32duino’s
package_index.jsonare making it onto mac-arm64 systems.At least for xPack-provided packages (both the toolchain and OpenOCD), providing native mac-arm64 tools is straightforward, as xPack has published them itself for quite some time: the toolchain since 10.3.1-2.3 (2022-03-24) and OpenOCD since 0.11.0-3 (2021-12-07). It’s trivial to add these to STM32duino’s
package_index.json, at least for current versions, to begin resolving this in favor of proper mac-arm64 support.Neither CMSIS nor STM32_SVD contain executable code for a build host, so they can be used as-is on mac-arm64 build hosts. (The same packages are already used across all supported build operating systems and architectures.) They can be added to STM32duino’s
package_index.jsonas mac-arm64 to make this relationship explicit.That leaves STM32Tools as the last package requiring a rebuild for mac-arm64. The
dfu-*tools appear to come straight from dfu-util**,hid-flashappears to come from STM32_HID_Bootloader, andupload_resetis directly within the Arduino_Tools repository. It is almost certainly straightforward to do mac-arm64 builds for all of these, but before doing so, I’d like to clarify what specific source (version, patches, build settings) was used for the existing versions, and whether binaries for this need to be built on common infrastructure.* What I call “mac-arm64” may otherwise be referred to as ”Apple Silicon”, M1, or some other M-number. I’m including these terms here for searchability.
** As part of this effort, it may be possible to fix the
dfu-utillibusbdependency problem, and not requirelibusbto be externally provided.The text was updated successfully, but these errors were encountered: