MPUの型番による違い
lib/chibios/os/common/ext/ST/以下のヘッダファイルに書いてある。
問題は、全型番が網羅されているわけではないこと。自分の型番がないときは近いものを見ることになる。が、これはどうもSTM32CubeMX（ST製ツール）が自動生成したヘッダファイルらしい。ChibiOS内では使われていないらしいマクロがある。たとえばFLASH_BANK1_END。Flashのサイズだけ違う型番ならここを変えればいいのかな？ と思うが、ほかのところで使われている様子がない。
STM32CubeMXのインストール…ができなかったのでprevious version
もしJavaランタイムがなければOpenJDK8をインストール。
cmd.exeをAdministratorモードで開いて、java -jar SetupSTM32CubeMX-6.0.1.exe
信じられないほど時間がかかる。もしかしてダウンロードしてる？ 230MBもあるインストーラなのに？
今度は普通のcmd.exeでC:\Program Files\STMicroelectronics\STM32Cube\STM32CubeMXでjava -jar STM32CubeMX.exe
→スプラッシュスクリーンが消えたあとhalt。なんじゃこりゃ。
しょうがないのでバージョンを下げて5.6.1で同じようにしたら動いた。
STM32CubeMXの自動生成コードはChibiOSとは似てるけど違うけど参考になる
Makefileプロジェクトを自動生成してみた。
自動生成コードのいいところ：使うところだけ切り出してある場合が多いので、ChibiOSより探しものに便利。特にMakefile。
全型番を網羅していないのは、ヘッダファイルではSTM32CubeMXも同じ。違うのはLDSCRIPTで、STM32CubeMXはFlashサイズ違いにLDSCRIPTで対応している。しかしChibiOSのLDSCRIPT（lib/chibios/os/common/startup/ARMCMx/compilers/GCC/ld/にある）には欠けている型番がある。たとえばSTM32F072x8。この場合、QMKのkeyboardのrules.mkでMCU_LDSCRIPTで独自のLDSCRIPTを指定するらしい。keyboards/xiaomi/mk02/rules.mk参照。
ポエム：MPUの型番は掛け算なので、自動生成するSTM32CubeMXはこれでいいとして、ChibiOSはヘッダファイルやLDSCRIPTの構成を工夫しないとつらいのではありませんか？
GCC拡張
QMKは__attribute__ ((weak))というGCC拡張を大前提に設計されているらしい。
普通のリンカは同名の関数定義が複数あるとエラーを吐く。しかしELFにはWeak symbolなるものがあって、通常の関数定義（Strong symbol）はWeak symbolを上書きできる。参照
Custom Matrixが関数定義だけでできるとは一体どういうトリックなのか？ と思ったら、こういう仕掛けだった。
#defineのインデント
何気なくchconf.hをclang-formatでフォーマットしたら、地獄めぐりをさせられた。問題はlib/chobios/os/rt/rt.mkの
CHCONF := $(strip $(shell cat $(CHCONFDIR)/chconf.h | egrep -e "\#define"))
なんとgrepで#defineという文字列を探している。そのためマクロをインデントして# defineとするとコンパイルエラーになる。エラーになってくれるならまだいいほうで、黙って変な動作をして、地獄の底を引きずり回されることもあるだろう。