[macOS] Support for ST-Link-v1 in macOS High Sierra? (Kernel Extension)

[PickRelated]

Since El Capitain there were no new kexts. I would love to launch my STLink v1 on MacOS High Sierra.

Could you please write one? Or may be you could help me out with doing it myself? I have never written kexts or software under MacOS before.

Thanks!

[PickRelated]

I think the problem might be with High Sierra itself because when I try to load kext I get this.

$ sudo kextutil -v /System/Library/Extensions/stlink_shield.kext

Defaulting to kernel file '/System/Library/Kernels/kernel'
Untrusted kexts are not allowed
Kext with invalid signature (-67062) denied: /Library/StagedExtensions/System/Library/Extensions/B100D010-6109-4259-BD2B-2A33C2518E76.kext
Bundle (/System/Library/Extensions/stlink_shield.kext) failed to validate, deleting: /Library/StagedExtensions/System/Library/Extensions/B100D010-6109-4259-BD2B-2A33C2518E76.kext
Unable to stage kext (/System/Library/Extensions/stlink_shield.kext) to secure location.

[PickRelated]

I have disabled SIP and the kext was successfully loaded. But st-util still has no luck with my STM32VLDiscovery.

$ st-util

st-util 1.4.0
2018-09-08T21:19:44 WARN usb.c: Couldn't find any ST-Link/V2 devices

[PickRelated]

Might also be helpful. When I try to trace the kext problems I get this.

$ sudo kextutil -t -n stlink_shield10_10.kext
Kext with invalid signatured (-67062) allowed: <OSKext 0x7ff7a8700a70 [0x7fff92302980]> { URL = "stlink_shield10_10.kext/ -- file:///Users/pin/rep/stlink/stlinkv1_macosx_driver/osx/", ID = "com.libusb.stlink_shield" }
Code Signing Failure: not code signed
Warnings:
    Personality CFBundleIdentifier differs from containing kext's (not necessarily a mistake, but rarely done):
        DeviceDriver
        InterfaceDriver
    Kext has no executable or compatible version, so it should not declare any OSBundleLibraries.

Warnings:
    Personality CFBundleIdentifier differs from containing kext's (not necessarily a mistake, but rarely done):
        DeviceDriver
        InterfaceDriver
    Kext has no executable or compatible version, so it should not declare any OSBundleLibraries.

stlink_shield10_10.kext appears to be loadable (including linkage for on-disk libraries).

[xor-gate]

I would recommend buying a v2 or v2-1 programmer. STMicroelectronics also doesn't support v1 anymore in their stlink utility if I'm correct. Just bring your v1 to the museum and spend 20 euro, then you are the man.

[PickRelated]

I have v2, but I am traveling and I have to program two devices at the same time for their communication. One STM32VLDiscovery is attached to st-link v2 and other STM32VLDiscovery I want to program by itself, not disconnecting a thousand wires from another board :(
I am sure if you just fix kext library versions or something - it will work. This kext simply has to overtake default mass storage driver as I understand.

I think the problem lies here. But I do not know what to put instead

			<key>CFBundleIdentifier</key>
			<string>com.apple.kpi.iokit</string>

[PickRelated]

ioreg -c IOUSBInterface gives next output. I think there is a mismatch in driver used or something?

    | |   |       | | +-o STM32 STLink@fd130000  <class IOUSBHostDevice, id 0x10000094f, !registered, !matched, active, busy 0, retain 16>

   ...

      | | | +-o STM32 STLink@fd130000  <class AppleUSBDevice, id 0x100000951, registered, matched, active, busy 0 (1 ms), retain 13>
      | | |   +-o IOService  <class IOService, id 0x100000956, !registered, !matched, active, busy 0, retain 4>

[xor-gate]

I have no idea, not su much people use the stlink v1.

[Nightwalker-87]

Related to #574.

[Nightwalker-87]

We will be having problems regarding Kernel Extensions (kext) in future releases of macOS as these have been deprecated by Apple: https://developer.apple.com/de/support/kernel-extensions/

Against this background we will not provide a new kext for later macOS versions.
The above implies as well that we either need a new approach to ensure the same functionality currently present or as an alternative cease any support for the legacy ST-Link-v1 programmer in the stlink toolset.

Discussion on this topic is now open. Please have your say.

[chenguokai]

After detailed search, I have the following findings:

It is a known problem to libusb https://github.com/libusb/libusb/wiki/FAQ I would recommend trying unload kexts that match the ST Link v1. Volunteers needed to test. Other methods seem to be more tricky and destructive. I would not recommend modifying stock kexts or loading codeless kexts. The former one might cause boot failure, the latter one requires users to disable SIP as long as they do not own a kext develop license. Also I tried updateing the kext without SIP on, but no luck.

If the matches cannot be bypassed, a drop at least for newer systems can be expected.

Edit: A kext for High Sierra in public domain is available from https://www.avrfreaks.net/forum/atmelice-signed-dummy-kext-macos-x-high-sierra, modifying the pid and vid for ST Link may work.
AtmelICE.kext.zip
Still, volunters needed.

[Nightwalker-87]

Well, SIP is not a problem for us (it should not be disabled completely BTW!) - we have documentation in our tutorial on how to keep it enabled and being able to load kexts at the same time. Trying it with unsigned kexts being blocked by SIP does not help any further - we now that this causes strange side effects (i would not like to investigate really).

[chenguokai]

@Nightwalker-87 Ever since macOS 10.14, it has been no longer possible to partially disable SIP, i.e. the tutorial does not apply to the latest two versions of macOS.

[Nightwalker-87]

Oh, I didn't realise that - Thank you. I fixed this in commit 99a8aaa.

[Nightwalker-87]

So what's the plan on how to proceed here? Would it be worth the efforts to write a kext for macOS 10.13 High Sierra, or shall we leave it? As far as I can read from our STlinkv1-Driver we currently support 10.6 - 10.10. Additionally there is a reference (#574 (comment)) that the 10.10 kext is still usable on 10.13, so I assume it also runs on 10.12 and 10.11. If there is no change necessary in the module itself, we may think to simply modify/duplicate the codeless 10.10 kext for 10.11 to 10.13 (10.14, 10.15?) OR simplify the current one to be multi-version compatible. Further I'd propose to exclude the look into the future (deprecation of kexts) here in this issue. We may put that up on the agenda in a future release. It is not that urgent right now and we don't no exactly what the future brings to us. @chenguokai can you look at this again? Additionally we need someone with a mac and a STlink-v1 for testing.

[chenguokai]

Kexts are actually directories with a special structure. The codeless Kext used for STLink v1 has a even simpler structure, with only a Info.plist inside. Info.plist is read by the system to see what kinds of device it states to support by pid and vid. This Kext is loaded so that the default SCSI Kext provided by macOS will not load for STLink which prevents libusb from attaching and that’s all.
The incompatibility comes from the API change in 10.11. The usb stack was changed with a new name. As a result, it is ideal to provide a Kext for newer systems, changes the name of its dependency. Would not be so hard to do because the atmel Kext for newer systems provides a good reference.

In theory the new codeless Kext works from 10.11 to 10.15, with SIP disabled on 10.14 and 10.15.

There is indeed a depreciation of Kexts coming, while in my view, as long as Apple continues using Kexts for their internal drivers, a codeless Kext will survive for a long time.

If someone feels happy to test a new Kext, I would like to make one. If it indeed works, the support prolongs, otherwise leaving a note in the documentation stating that it is not supported while some of them may work without a Kext would be a solution.

Edit: kext for test, modified version of Atmel's signed kext (in public domain).

• PID and VID adjusted for STLink v1
• Signature removed
• Should at least work on 10.13, may work on 10.11 and 10.12 (The original kext is stated to be for 10.13)

Test_stlinkv1.kext.zip

[Nightwalker-87]

I have the possibility to install the kext in an 10.13 and 10.14 VM. I suppose you are on Catalina. So at least the kext install and integration could be tested. As mentioned before it would still be helpful to have someone to do additional testing with a STlink-v1 programmer.

[chenguokai]

I am currently on Mojave 10.14 due to 32 bit support. Should not be a problem since codeless kexts barely need changes.

[Nightwalker-87]

@chenguokai: Would you mind to look into this? I am currently focussing on finalising the windows binary distribution topic and travis test-build improvements, but can do some tests on 10.13 VM later on, if useful.

[chenguokai]

Would you mind to look into this?

I am not quite sure about “look into”. If there are users who feel happy to do some test, I will surely provide essential instructions. I cannot test myself because I do not have a ST-Link v1, no purchase available too.

[Nightwalker-87]

If I get to know what has to be changed for newer macOS versions specifically, based on a copy-paste-kext, I would take action myself.

[chenguokai]

A codeless kext has the following structure:

KEXTNAME.kext
....Contents
........Info.plist

Info.plist is either in binary or xml form. In our case, no binary form kexts have been found.

The change is caused by the removal of IOUSBDevice (previously defined in IOKitPeraonalities/DeviceDriver)

IOUSBDevice occurrences should be replaced by IOUSBinterface like the one in https://www.avrfreaks.net/sites/default/files/forum_attachments/AtmelICE-kext-for-High-Sierra.zip

If _CodeSignature is presented in the kext template that you intend to modify for ST-Link v1, you need to remove it (if signing is applicable, redo the signing is the best practice), since coming modifications break the signature.

idProduct and idVendor should be adjusted to what ST-Link v1 reports (can be found in older kexts)

com.apple.kpi.kern in OSBundleLibraries seems to be redundant.

Other attributes, if different, should obey newer conventions presented in the Atmel's implementation.

[Nightwalker-87]

I found this interesting link: https://visserslatijn.wordpress.com/2019/01/20/upgrade-st-link-v1-to-v2/ We may add that to our project documentation.

Additionally I'd suggest to drop unsupported macOS 10.6 to 10.12 in the kext and thus give it another maintenance by ensuring it to run on 10.13 - 10.15 (with a ❤️ for a very small mac-usergroup).

[chenguokai]

Great hack👏
Quite agree that we drop some old hardware-old OS combinations support.

Also, a kinda crazy idea here, if there are some open source / dumped stlink v3 implementation, they might help identifying why the experimental v3 support fails somewhere.

[Nightwalker-87]

Having noticed there is an old xcode project file in the kext-driver zip-file, led me to the idea to import that into xcode 11.3.1, because I think it is much easier to handle and edit all settings from there. The project settings and parameters should now be compatible with xcode 11 and later with updates and guided clean-up.

I've created targets for 10.13 to 10.15, but need to know exactly how to set the CFBundleIdentifier (I think this needs to be com.apple.kpi.iokit) and it's related settings for each of the mentioned versions. The code signing identity is now set to Sign to Run Locally, so I hope it'll work this way. However some assistance would be helpful. I've had a quick look into the AtmelICE-kext, but have not spent much time on it yet.

[chenguokai]

I think this needs to be com.apple.kpi.iokit

I think so, too :-)