qmk/qmk_firmware

[Bug] kinesis/kint41 firmware does not successfully compile

negatv opened this issue · 8 comments

Describe the Bug

Firmware for kinesis/kint41 does not currently successfully compile using the configurator.

I have pulled latest code from master and was able to build locally.

Compiling: keyboards/kinesis/kinesis.c                                                             In file included from ./lib/chibios/os/common/ports/ARMCMx/chcore.h:70:0,
                 from ./lib/chibios/os/rt/include/ch.h:112,
                 from ./lib/chibios/os/hal/osal/rt-nil/osal.h:32,
                 from ./lib/chibios/os/hal/include/hal.h:28,
                 from tmk_core/common/chibios/platform_deps.h:18,
                 from quantum/quantum.h:18,
                 from keyboards/kinesis/kint41/kint41.h:19,
                 from keyboards/kinesis/kinesis.h:20,
                 from keyboards/kinesis/kinesis.c:1:
./lib/chibios-contrib/os/common/startup/ARMCMx/devices/MIMXRT1062/cmparams.h:70:24: fatal error: MIMXRT1062.h: No such file or directory
 #include "MIMXRT1062.h"
                        ^
compilation terminated.
 �
make: *** kconfig41/keyboards/kinesis/kinesis.o] Error 1

Additional Context?

No response

I've found the cause of this error, but I need to check with someone about a proposed fix – I'm not familiar with the infrastructure where this needs to be fixed.

@noroadsleft is this resolved?

No, the issue still exists.

I've figured how to fix this, but the issue has been that all the proposed solutions create new problems for QMK.

Can you elaborate on what the new problems are? Maybe someone has a good idea on how to fix it :)

It's been a while, but when initially building from source for the Teensy 4.1, I had to 'make git-submodule' and it resolved the issue. Can't say that is the solution in this case, but the error message does point to not being able to find the header file "MIMXRT1062.h".

This issue has to do with the mcux-sdk submodule inside of chibios-contrib. The QMK API tries to determine which submodules to pull down before compiling a board, but it does not do it recursively (and shouldn't). The options here are to recurse checking out submodules for only chibios-contrib, or to add custom code for mcux-sdk. Both are not great solutions.

@stapelberg what was the reason for adding this, and is there a way to eliminate the need for it?

@stapelberg what was the reason for adding this, and is there a way to eliminate the need for it?

For older NXP controllers, ChibiOS uses its own USB low-level driver.

However, NXP switched to an entirely different IP for USB 2.0 in their newer controllers (used in Teensy 4.x), which works in an entirely different way.

Updating the ChibiOS driver to the new IP is way too much work — I spent weeks trying, unsuccessfully.
Hence, we ended up using the well-tested NXP USB SDK in ChibiOS instead to get reliable USB support.

So, the mcux-sdk is absolutely required and I don’t see any way to get rid of it.