Я бы делал как-то так: качнул у опенвртшников их тулчейн (gcc), сорцы и конфиг ядра, именно того которое в роутере...

А потом
1) https://www.geeksforgeeks.org/linux-kernel-module-programmin.../ как простой пример что есть модуль и как его сбилдить.
2) Если это не круто (там кросс не предусмотрен) - сорцы kmod посмотреть, там еще примеры модулей ядра. Но все же кернель вот именно той версии и его конфиг - понадобится. С опенврт не должно быть большой проблемой.
3) Идея в том что для билда только вот именно своего модуля пинается make ... modules M=<наш добавочный модуль> и билдится только он.
4) Кросс ядра (и модулей) достаточно неинтрузивен. make ARCH=<arch> CROSS_COMPILE=<cross_toolchain_prefix> <target>, при том <target> это как раз "M=<ваш модуль> modules".

И таки обычно юзают билдсистему ядра, а само ядро и компилер - лучше всего взять как на таргете, одна из причин по которым openwrt выкладывает свои тулчейны которыми билдили систему. Если ваш clang может генерить код той архитектуре с тм же ABI - ну, окей, наверное и он прокатит если его указать как CROSS_COMPILE= но вот тут уже на вашей совести чтобы ABI и набор команд были те же самые.

Можно ли это на cmake натянуть? Наверное, при сильном желании. Но если в i++'ном ядре что-то поменяют, кто вам будет доктор. Они никогда не давали гарантий на то что internals ядра наружу неизменные. Поэтому реюзнуть билдсистему кернела выглядит безопаснее всего - она точно знает как свое ядро и модули в нем собирать а то что там +1 модуль втерся, ну, ок, почему нет?

Это же и насчет минимального SDK. Внутренности ядра достаточно динамично меняются. Угонится ли за этим "мини SDK" отдельный такой вопрос. Вообще сборка ядра под штуки типа сабжа не такой уж большой и страшный процесс, кстати говоря.

Еще если включены подписи модулей их еще подписать надо - ключ готового ядра, конечно, вам никто не даст, придется все ядро отстроить и им пользоваться. Но у опенврт вроде обычно подписи не включены вроде и это не должно стать проблемой, скорее на всякий случай.