Support mac-arm64 properly

[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-util from 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_64 dfu-util process. This produces an unusable dfu-util on 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.json are 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.json as 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-flash appears to come from STM32_HID_Bootloader, and upload_reset is 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-util libusb dependency problem, and not require libusb to be externally provided.

[fpistm]

Hi @markmentovai
I've first comment on the PR. It's a bit werid arduino documentation are not aligned.
Anyway, I can't do the build for this target as I do not have a MAC with this architecture.
If you can provide them I will add it.
About dedicated binaries:

• dfu-util it is the one from the official release unfortunately the mac-arm64 seems not provided so you will have to build it from the dfu 11 official sources.
• HID bootloader: this is the official source with one patch. See chore: update to hid-flash 64-bit Arduino_Tools#94
• upload_reset: use the source available in the repo here: https://github.com/stm32duino/Arduino_Tools/blob/main/src/upload_reset/unix/upload_reset.c
• check_port: https://github.com/stm32duino/Arduino_Tools/blob/main/src/check_port/check_port.c

[markmentovai]

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 dfu-util.

You mentioned check_port in #72 (comment). I don’t see an existing build of that tool for macOS, and the tool itself appears to be Windows-specific, so I left it out.

[fpistm]

Hi @markmentovai
Thanks for all PR and work.
Will review it soon.