Teensy 4.1 (kint41) QMK support

[stapelberg]

Status

• milestone: light up LED
• milestone: print debug messages on the serial port
• milestone: light up a LED from ChibiOS
• milestone: print debug messages on the serial port from ChibiOS
• ChibiOS tests are passing successfully!
• milestone: USB stack used successfully from ChibiOS

USB

• the Teensy 4.1 has two USB 2.0 OTG controllers
• I’m trying to make controller USB1 (base address 0x402E0000) work (eval board: the USB port right next to the ethernet port, called “USB OTG” in the documentation, teensy 4.1: the main and only USB port)
• There are 5 different USB implementations I know of:
  1. NXP SDK (usb_device_dci.c)
     • supports KHCI (USB Full Speed)
     • supports EHCI (USB High speed, what the Teensy 4.1 uses)
     • supports LPC USB IP3511 FS
     • supports LPC USB IP3511 HS
  2. Paul Stoffregen’s official Arduino Teensy 4 core (usb.c)
     • Uses the EHCI interface, but also uses the teensy register macros, not NXP’s CMSIS.
  3. ChibiOS-Contrib Kinetis (hal_usb_lld.c)
     • The KINETIS hal_usb_lld.c uses the KHCI interface, which is not available on the Teensy 4.1 anymore.
     • Maybe we need to create a hal_usb_lld.c that uses the EHCI interface.
  4. The stack in libgreat is more readable/descriptive, but not 100% sure about correctness—might be better to prefer the NXP stack for now.
  5. Tamago’s USB stack: https://github.com/f-secure-foundry/tamago/tree/master/soc/imx6/usb

Building

• You need ChibiOS/ChibiOS@3249070 or newer (fixes the interrupt vector table alignment for teensy 4.1)
• My ChibiOS-Contrib WIP branch can be found at https://github.com/stapelberg/ChibiOS-Contrib/commits/teensy41

Wiring/testing

1. Connect a USB-to-serial adapter to teensy 4.1 pins G (GND), 16 (RX) and 17 (TX).
2. Build and flash the ChibiOS-Contrib teensy 4.1 demo:

   cd ChibiOS-Contrib/demos/MIMXRT1062/RT-TEENSY4_1
   make
   teensy-loader-cli -w -v --mcu=TEENSY40 build/ch.hex
   

3. After turning on the teensy 4.1, you should see debug messages on the serial console, followed by the ChibiOS test suites.

[stapelberg]

Status update: as of commit stapelberg/ChibiOS-Contrib@c6d4537, the ChibiOS serial usb device enumerates in my tests, and can be opened, but no data is sent/received over any endpoint but 0.

This line is where the device hangs: https://github.com/stapelberg/ChibiOS-Contrib/blob/c6d4537b6afbdb407f88526c0d5bdc72e7449c3a/os/hal/ports/MIMXRT1062/LLD/USBHSv1/hal_usb_lld.c#L172

Full log:

ISR
  setup ep=0
clear_out_queue
clear_out_queue, endpoint = 20002000, t = 00000000
_usb_ep0setup()
usb_lld_read_setup
bmRequestType = 00000000, bRequest = 00000009, wValue = 00000001, wIndex = 00000000, wLength = 00000000
usbcfg.c:usb_event(event=2)
usb_lld_init_endpoint(ep=1)
  OUT endpoint (RX enable), mode=2, maxsize=64
  IN endpoint (TX enable), mode=2, maxsize=64
usb_lld_init_endpoint(ep=2)
  IN endpoint (TX enable), mode=3, maxsize=16
usb_lld_start_out(ep=1)
usb_packet_receive(n=256)
usb_transfer_schedule(endpoint=20002080, transfer=2000327C, n=256, primebit=2, notify=1)

  ERROR: too many prime attempts, aborting
[…]

[stapelberg]

Status update: I managed to build a working firmware!

I pushed the various changes to GitHub for now, and will clean them up and send them upstream later as time permits.

You can try the current state using:

qmk clone -b kint41 kinx-project/qmk_firmware
qmk compile -kb kinesis/kint41 -km default
teensy-loader-cli -w -v --mcu=TEENSY40 .build/kinesis_kint41_default.hex

[stapelberg]

Status update: ChibiOS/ChibiOS-Contrib#246 is now cleaned up and ready for review, and all repositories have been updated based on the current QMK develop branch.

The instructions in #5 (comment) remain valid for trying out the firmware.

[mdempsky]

With ChibiOS/ChibiOS-Contrib#246 merged, what's the status of this issue? Is there still more to do for the 4.1 to be fully supported? Thanks.

[stapelberg]

With ChibiOS/ChibiOS-Contrib#246 merged, what's the status of this issue? Is there still more to do for the 4.1 to be fully supported? Thanks.

If you’re okay with building from my repository instead of QMK’s, then I consider the kint41 fully supported. I have been using a kint41 as my daily driver for weeks now, and have not noticed any issues. I know there is at least one other user without any issues.

QMK itself tracks their own branch of ChibiOS-Contrib which lags behind upstream, so for proper upstream support, my changes first need to make it into that branch. I want to ask QMK to cherry-pick, but wanted to finish some related work on keyboard latency to make sure I don’t ask prematurely (in case my work identifies other changes needed). Will probably ask next week or so.

[mdempsky]

SGTM, Teensy 4.1 ordered. Thanks!

[stapelberg]

I want to ask QMK to cherry-pick, but wanted to finish some related work on keyboard latency to make sure I don’t ask prematurely (in case my work identifies other changes needed)

Finished the latency work and asked QMK for the cherry-pick in qmk/qmk_firmware#12843

[tsharky]

Status update: I managed to build a working firmware!

I pushed the various changes to GitHub for now, and will clean them up and send them upstream later as time permits.

You can try the current state using:

qmk clone -b kint41 kinx-project/qmk_firmware
qmk compile -kb kinesis/kint41 -km default
teensy-loader-cli -w -v --mcu=TEENSY40 .build/kinesis_kint41_default.hex

Hey,
I can't compile kinesis boards from your fork on my windows machine.
Both 'kint41' and 'kint2pp' give me an unicode error.

Ψ Compiling keymap with make -j 1 kinesis/kint41:default


QMK Firmware 0.9.32
Making kinesis/kint41 with keymap default

ERROR 'charmap' codec can't decode byte 0x90 in position 1558: character maps to <undefined>
Traceback (most recent call last):
  File "C:/tools/qmk_msys/mingw64/lib/python3.8/site-packages/milc/milc.py", line 476, in __call__
    return self.__call__()
  File "C:/tools/qmk_msys/mingw64/lib/python3.8/site-packages/milc/milc.py", line 479, in __call__
    return self._subcommand(self)
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/decorators.py", line 42, in wrapper
    return func(*args, **kwargs)
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/decorators.py", line 85, in wrapper
    return func(*args, **kwargs)
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/cli/generate/rules_mk.py", line 58, in generate_rules_mk
    kb_info_json = dotty(info_json(cli.config.generate_rules_mk.keyboard))
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/info.py", line 57, in info_json
    info_data = merge_info_jsons(keyboard, info_data)
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/info.py", line 476, in merge_info_jsons
    new_info_data = json_load(info_file)
  File "C:/Projects/qmk_firmware_kinx-project/lib/python/qmk/json_schema.py", line 18, in json_load
    return hjson.load(json_file.open())
  File "C:/tools/qmk_msys/mingw64/lib/python3.8/site-packages/hjson/__init__.py", line 117, in load
    return loads(fp.read(),
  File "c:/tools/qmk_msys/mingw64/lib/python3.8/encodings/cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x90 in position 1558: character maps to <undefined>
build_keyboard.mk:104: 'UnicodeDecodeError'>: No such file or directory
make[1]: *** No rule to make target ''UnicodeDecodeError'>'.  Stop.
Make finished with errors
make: *** [Makefile:530: kinesis/kint41:default] Error 1

I can compile 'kint2pp' from the official qmk project without issues.
Any chance you know how to fix it?

I'm new to Kinesis and QMK, so I have no clue where to look for differences between your fork and qmk.

Greetings!

[stapelberg]

I can compile 'kint2pp' from the official qmk project without issues.
Any chance you know how to fix it?

I rebased the kint41 branch on top of the current QMK development branch.

Possibly that fixes your problem (given that you say compiling QMK itself works).

Can you try cloning again and see if compilation now works?

If no, does compilation of kint36 work from the QMK upstream develop branch for you?

[cadusk]

My issue is related to pin names.
Before fetching latest, builds were working.

Now looks like pin names that don't match this criteria will fail:
pin[0] in 'ABCDEFGHIJK' and pin[1].isdigit()

Here's the output of the error message

Ψ Compiling keymap with make -j 1 kinesis/kint41:default


QMK Firmware 0.9.32
Making kinesis/kint41 with keymap default

⚠ Nonstandard pin format: LINE_PIN20
⚠ Nonstandard pin format: LINE_PIN21
☒ Invalid API data: kinesis/kint41: matrix_pins.cols.0: 'LINE_PIN20' is not valid under any of the given schemas
arm-none-eabi-gcc (Arch Repository) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

⚠ Nonstandard pin format: LINE_PIN20
⚠ Nonstandard pin format: LINE_PIN21
☒ Invalid API data: kinesis/kint41: matrix_pins.cols.0: 'LINE_PIN20' is not valid under any of the given schemas
⚠ Nonstandard pin format: LINE_PIN20
⚠ Nonstandard pin format: LINE_PIN21
☒ Invalid API data: kinesis/kint41: matrix_pins.cols.0: 'LINE_PIN20' is not valid under any of the given schemas
⚠ Nonstandard pin format: LINE_PIN20
⚠ Nonstandard pin format: LINE_PIN21
☒ Invalid API data: kinesis/kint41: matrix_pins.cols.0: 'LINE_PIN20' is not valid under any of the given schemas
Compiling: keyboards/kinesis/kinesis.c                                                             <command-line>: fatal error: .build/obj_kinesis_kint41/src/info_config.h: No such file or directory
compilation terminated.
 [ERRORS]
 | 
 | 
 | 
make[1]: *** [tmk_core/rules.mk:436: .build/obj_kinesis_kint41_default/keyboards/kinesis/kinesis.o] Error 1
Make finished with errors
make: *** [Makefile:530: kinesis/kint41:default] Error 1

Also, builds of kint2pp and kint36 build just fine.

[stapelberg]

Sorry about that. Turns out clean builds were broken, but my working copy still had the required files lying around so I didn’t notice.

I pushed the old version for now, until I can properly fix the pin issue.

[stapelberg]

Posted qmk/qmk_firmware#13052 upstream to ask about how to approach the pin naming issue.

[cadusk]

Thanks, Michael. It builds fine now.

[stapelberg]

I rebased the kint41 branch on top of the current QMK development branch.

Possibly that fixes your problem (given that you say compiling QMK itself works).

Can you try cloning again and see if compilation now works?

You can now find these changes in the kint41-upstream branch: https://github.com/kinx-project/qmk_firmware/commits/kint41-upstream

[stapelberg]

Upstreaming status: the required core QMK pull requests have been sent:

• core: make RESET key work with Teensy 4.x qmk/qmk_firmware#13076 (reset key)
• core: wire up flash make target for Teensy 4.x qmk/qmk_firmware#13077 (flash target)
• core: bump USB spec version in device descriptor to 2.0 qmk/qmk_firmware#13078 (usb 2.0)
• allow LINE_PINxx for Teensy 4.x pins qmk/qmk_firmware#13247 (allow line_pinxx on teensy 4.x)
• Optimize our jsonschema by using refs qmk/qmk_firmware#13271

The main keyboard addition PR has now been sent as well: qmk/qmk_firmware#13333

[tsharky]

I rebased the kint41 branch on top of the current QMK development branch.
Possibly that fixes your problem (given that you say compiling QMK itself works).
Can you try cloning again and see if compilation now works?

You can now find these changes in the kint41-upstream branch: https://github.com/kinx-project/qmk_firmware/commits/kint41-upstream

For me it still did not build on a windows machine (upstream branch as well). In the meanwhile I worked with kint41 branch on a fedora vm and arch linux. That worked fine.

[stapelberg]

For me it still did not build on a windows machine (upstream branch as well)

You might want to file an issue at https://github.com/qmk/qmk_firmware/issues about that, then

[stapelberg]

Support for the Teensy 4.0 and Teensy 4.1 (both via the kint41 target) has been added to QMK in commit qmk/qmk_firmware@f533d9e (develop branch)! 🎉

[gr4yscale]

@stapelberg Thanks for your work on this, and the previous iterations of the kinT board. I successfully compiled QMK for a Teensy 2.0++ with the kint2pp from master branch of qmk/qmk_firmware, and just love it! I got a Teensy 4.1 + kinT for my 2nd Kinesis, not having as much luck...

I compiled your fork with the previous instructions, but I had an issue with bottom row keys not working - could be hw, but I wanted to first compile from the develop branch of qmk/qmk_firmware.

develop branch of qmk_firmware seems very tricky to work with It seems that the supported sub-commands such as qmk compile do not exist for develop branch. Using qmk clone -b develop to try to get the official branch doesn't help things, either. So it seems that make is the only supported way to build firmware on develop branch, which would be fine, except it seems broken? I've followed their docs for the Makefile.

This is more of a QMK question, but maybe you've encountered this. I've looked around a bit, no one seems to have problems using the develop branch. Furthermore, official tooling (qmk cli tool) seems to not approve of the develop branch:

Path '/home/gr4yscale/qmk_firmware' exists but is not a qmk_firmware clone!

It seems that the version check line in Makefile is causing a problem. I tried using SKIP_VERSION=true. Actually I see that the problem is with the qmk_cli tool which they call into using the Makefile to call into some python code. Mine is from the AUR (source repository for arch linux package) but maybe the problem is that it's out of sync with dev branch of qmk_firmware, but I don't see a dev branch, or any new commits on qmk_cli master.

Actually, in writing this up, I discovered that they very recently changed something about how they're parsing args. Probably something broke there. I tried reverting, since your changes came in after this:

❯ git revert bbe43a91ebf193bbc8c09ba59209b0524367e68c
Removing lib/python/qmk/cli/generate/version_h.py
[develop c709b4ee0] Revert "CLI: Add subcommand to generate version.h (#13151)"
 5 files changed, 45 insertions(+), 79 deletions(-)
 delete mode 100644 lib/python/qmk/cli/generate/version_h.py

Before reverting this, I got the following output:

❯ make kinesis/kint41:default:flash
QMK Firmware 0.13.5
usage: qmk [-h] [-V] [-v] [--datetime-fmt DATETIME_FMT] [--log-fmt LOG_FMT]
           [--log-file-fmt LOG_FILE_FMT]
           [--log-file-level {debug,info,warning,error,critical}]
           [--log-file LOG_FILE] [--color] [--no-color] [--unicode]
           [--no-unicode] [--interactive] [--config-file CONFIG_FILE]
           {config,clone,env,setup} ...
**qmk: error: argument {config,clone,env,setup}: invalid choice: 'generate-version-h' (choose from 'config', 'clone', 'env', 'setup')**

Can you please tell me what version of qmk_cli you have?

❯qmk -V
0.0.51


~/qmk_firmware develop ⇡
❯ make kinesis/kint41:default
QMK Firmware 0.13.19
ERROR: Cannot run "qmk hello"!

 Please run qmk setup to install all the dependencies QMK requires.

make: *** [Makefile:512: kinesis/kint41:default] Error 1

~/qmk_firmware develop ⇡
❯ qmk setup
☒ Path '/home/gr4yscale/qmk_firmware' exists but is not a qmk_firmware clone!

Note that I'm also always getting complaints about "qmk hello", and searching the qmk_cli repo on GH does not show anything about "hello"...

This is a nightmare! I have an injured hand, this is not helping, since my backup kinesis is at the office. Getting the other keyboard going was much much smoother. I am considering driving 30 minutes away to buy a teensy 2.0++ tomorrow and to desolder the Teensy 4.1. :(

Thanks in advance for any help.

[stapelberg]

compiled your fork with the previous instructions, but I had an issue with bottom row keys not working - could be hw

Most likely. All keys should be working in all of the published firmware revisions.

It seems that the supported sub-commands such as qmk compile do not exist for develop branch

This is not what I’m seeing:

~/kinx/workspace/qmk_firmware develop % qmk compile -km stapelberg -kb kinesis/kint41            
Ψ Compiling keymap with make -j 1 kinesis/kint41:stapelberg


QMK Firmware 0.13.19
Making kinesis/kint41 with keymap stapelberg

arm-none-eabi-gcc (Arch Repository) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text	   data	    bss	    dec	    hex	filename
      0	  36446	      0	  36446	   8e5e	.build/kinesis_kint41_stapelberg.hex

Compiling: quantum/command.c                                                                        [OK]
Linking: .build/kinesis_kint41_stapelberg.elf                                                       [OK]
Creating binary load file for flashing: .build/kinesis_kint41_stapelberg.bin                        [OK]
Creating load file for flashing: .build/kinesis_kint41_stapelberg.hex                               [OK]

Size after:
   text	   data	    bss	    dec	    hex	filename
      0	  36446	      0	  36446	   8e5e	.build/kinesis_kint41_stapelberg.hex

Copying kinesis_kint41_stapelberg.bin to qmk_firmware folder                                        [OK]
(Firmware size check does not yet support cortex-m4 microprocessors; skipping.)

Try uninstalling all QMK packages from the AUR, then install the QMK CLI from your repo as per the QMK instructions (using pip).

You can always consider starting a different Linux distribution using docker, too, and building there.

[gr4yscale]

@stapelberg Some good news (and apologies for the longreads + frustration!) Compiling from develop

Apparently pip version of qmk_cli is out of date. The version that I get from Arch User Repository is correct. Still surprised why I didn't see anything searching with GH search tool for "hello" ...perhaps case sensitivity, I didn't clone and ack or grep it. edit: This may not be the case, I'll do some testing.

Apparently qmk setup or something else installed the pip version behind my back... After removing that, and hacking the Makefile temporarily to reference /usr/bin/qmk things are moving...

make -d kinesis/kint41:default
...
Successfully remade target file 'kinesis/kint41:default'.

I also needed to not invoke make with sudo, to get the qmk bin to be found. Will check into that.

❯ qmk hello
Ψ Hello, World!

I see your message came through after I wrote this. Thank you for the quick response! Actually, I had tried removing the QMK packages from AUR first, and went with straight pip packages, but was having troubles. Still, that is the most logical to me as well. I'll build up a clean dev environment using docker as you suggest.

Thanks again for the quick help! You're amazing. I'll now move on to testing those bottom row keys...it's likely just the jumper cable not tucked in tightly, I believe the solder joints are good.

[gr4yscale]

@stapelberg Just to say thanks again, and that I noticed that you (or someone) managed to get console debugging working with CONSOLE_ENABLE = yes, which means it's now possible to use hid_listen for debugging - in the previous fork, it was causing the kb to be unresponsive.

Great work! :) Let me know if I can test anything or help in any way with any remaining tasks.

[gr4yscale]

@stapelberg Indeed the column 4 missing was a bad solder joint, probably broke after I cut pin headers down.

Thanks to your diligent work on the silk screens and schematic, it was a breeze to identify the offending connection.

Very inspiring stuff; I am ready to try designing a board with KiCad. Learned a lot of theory and some basics of eagle, but KiCad is much more appealing given that it's FOSS and thus easier to learn in together with a group.

Thanks again!

[stapelberg]

Glad to hear you could get it to work 👍

[tamsky]

@stapelberg Just to say thanks again, and that I noticed that you (or someone) managed to get console debugging working with CONSOLE_ENABLE = yes, which means it's now possible to use hid_listen for debugging - in the previous fork, it was causing the kb to be unresponsive.

I'm currently unable to get CONSOLE_ENABLE working on a teensy 4.0.

Compiling your qmk kinesis/kint41 with CONSOLE_ENABLE = yes set in the rules.mk file,
neither qmk console nor hid_listen are able to connect to the kint41 firmware after it boots.

Only when I press the teensy's reset button while running qmk console, it does print anything other than "Looking for devices..."

Looking for devices...                                                                               
<hit reset button on teensy here>
Ψ Bootloader Connected: halfkay: Teensy Halfkay

Questions:

• Are there a set of steps that can help confirm that CONSOLE_ENABLE = yes is having the intended effect on the resulting qmk Teensy 4.0 firmware ?
• Perhaps there's an additional USB device that should show up when it's working as expected? How to identify it?
• What's the correct tool to use to listen to the enabled console's debug messages?
  hid_listen apparently does not directly support anything other than teensy 2.x boards (and earlier).

[stapelberg]

Compiling your qmk kinesis/kint41 with CONSOLE_ENABLE = yes set in the rules.mk file,

In which rules.mk file specifically are you putting this line?

For me, it did not work in keyboards/kinesis/kint41/rules.mk, but it worked in my custom keymap keyboards/kinesis/keymaps/stapelberg/rules.mk

hid_listen apparently does not directly support anything other than teensy 2.x boards (and earlier).

AFAIR, hid_listen works just as well with the newer Teensy models.

[tamsky]

Amazing and helpful news. Thank you.

Yes, I was adding CONSOLE_ENABLE = yes to keyboards/kinesis/kint41/rules.mk, because none of the docs specify to add it to the .../keymaps/*/rules.mk. Both qmk console and hid_listen now work as expected.

Would you consider this a makefile or QMK bug -- should I report it upstream?

---

Now I can proceed to debug my Row/Col issues using your code from
https://michael.stapelberg.ch/posts/2021-05-08-keyboard-input-latency-qmk-kinesis/

void keyboard_post_init_user() {
  debug_config.enable = true;
  debug_config.matrix = true;
}

[tamsky]

hid_listen apparently does not directly support anything other than teensy 2.x boards (and earlier).

AFAIR, hid_listen works just as well with the newer Teensy models.

I agree it's now working for me, but I'm definitely also curious what you think of Paul's reply here on this topic:

• https://forum.pjrc.com/threads/67784-Is-Teensy-4-0-compatible-with-hid_listen?p=284301&viewfull=1#post284301

[stapelberg]

Would you consider this a makefile or QMK bug -- should I report it upstream?

Yes, please report this upstream. I don’t know why it only works in one place, and ran into this issue myself :)

I agree it's now working for me, but I'm definitely also curious what you think of Paul's reply here on this topic:

I think Paul’s talking about out hid_listen working out of the box with the Teensy software stack. QMK already provides a bunch of different USB devices regardless of the underlying stack, and can easily keep doing that regardless of what the Teensy stack does. On the USB protocol level, the hid_listen approach works fine even for non-Teensy microcontrollers.

[gregschlom]

I'm getting the following error when I try to compile :

/lib/chibios-contrib/os/common/startup/ARMCMx/devices/MIMXRT1062/cmparams.h:70:24: fatal error: MIMXRT1062.h: No such file or directory

This is on branch develop of QMK, compiling with qmk compile -km stapelberg -kb kinesis/kint41

Any help would be appreciated!

EDIT: Nevermind, the issue was that I was building from QMK's repo. Switching to kinx-project/qmk_firmware fixed the issue.

[stapelberg]

EDIT: Nevermind, the issue was that I was building from QMK's repo. Switching to kinx-project/qmk_firmware fixed the issue.

No, you should be able to build from QMK’s repo. The kinx-project/qmk_firmware repo is not maintained (it’s old).

Your build issue sounds like you didn’t have all the submodules set up correctly. make git-submodule should probably fix this.

[brandondees]

From the above it seemed as if just running this from the normal QMK repo should be expected to work now, but it seems like something's missing here.

$ qmk flash -kb kinesis/kint41 -km default
Ψ Compiling keymap with make --jobs=1 kinesis/kint41:default:flash


QMK Firmware 0.14.29
Making kinesis/kint41 with keymap default and target flash

arm-none-eabi-gcc.exe (GCC) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text    data     bss     dec     hex filename
      0   39542       0   39542    9a76 .build/kinesis_kint41_default.hex

Compiling: quantum/command.c                                                                        [OK]
Linking: .build/kinesis_kint41_default.elf                                                          [OK]
Creating binary load file for flashing: .build/kinesis_kint41_default.bin                           [OK]
Creating load file for flashing: .build/kinesis_kint41_default.hex                                  [OK]
Copying kinesis_kint41_default.hex to qmk_firmware folder                                           [OK]

Size after:
   text    data     bss     dec     hex filename
      0   39542       0   39542    9a76 .build/kinesis_kint41_default.hex

Unknown MCU type "imxrt1062"
Supported MCUs are:
 - at90usb162
 - atmega32u4
 - at90usb646
 - at90usb1286
 - mkl26z64
 - mk20dx128
 - mk20dx256
 - mk66fx1m0
 - mk64fx512
make[1]: *** [platforms/chibios/flash.mk:82: flash] Error 1
Make finished with errors
make: *** [Makefile:510: kinesis/kint41:default:flash] Error 1
[Brandon@DESKTOP-JDED116 qmk_firmware]$

I'll probably go ahead and try the kinx-project fork next since that sounds like it should more definitely be able to work but I'd appreciate any help troubleshooting for this or else guidance on how to get whatever's the current best-available level of feature support.

BTW thanks @stapelberg for the excellent kit.

update: looking more closely it seems windows support isn't all there, so i'll try again from linux when i find the chance.

[stapelberg]

From the above it seemed as if just running this from the normal QMK repo should be expected to work now, but it seems like something's missing here.

Yeah, it should definitely be expected to work.

If building from the official QMK doesn’t work for anyone, it’s often best to check there for issues, or just try building an older version of QMK :)

For your specific case, this error message:

Unknown MCU type "imxrt1062"
Supported MCUs are:

…sounds like it comes from the teensy-loader-cli program: https://www.pjrc.com/teensy/loader.html

Are you sure you have a recent-enough version installed? Sounds like the one you have doesn’t know about the Teensy 4 yet.

[brandondees]

Ah thanks for that clue, I would never have made the connection. Looking into how to get latest teensy loader within QMK MSYS now...

Update:
Well that wasn't as easy as it should be but after some digging I was able to compile teensy loader from source and then things worked just fine!

For reference for the next person:
the msys2 package for teensy_loader_cli isn't updated so build from source is necessary. to build from source, I needed to refer to this issue: PaulStoffregen/teensy_loader_cli#55 and apply this fix: PaulStoffregen/teensy_loader_cli#59 and then bypass the makefile and run the build command for windows directly, copying the resulting file into the path location where the outdated packaged version was sitting.