From c61d37e15923521ed7cf86c3b57bd65c1190aba9 Mon Sep 17 00:00:00 2001 From: zvecr Date: Sun, 23 Jan 2022 22:17:09 +0000 Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20master=20@?= =?UTF-8?q?=207d6e15423be8c34dd456cd2c057f50f5c3d0a70c=20=F0=9F=9A=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- pr_checklist.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/pr_checklist.md b/pr_checklist.md index 25f3d7662e..1bd6200b82 100644 --- a/pr_checklist.md +++ b/pr_checklist.md @@ -110,6 +110,8 @@ Also, specific to ChibiOS: - a lot of the time, an equivalent Nucleo board can be used with a different flash size or slightly different model in the same family - example: For an STM32L082KZ, given the similarity to an STM32L073RZ, you can use `BOARD = ST_NUCLEO64_L073RZ` in rules.mk - QMK is migrating to not having custom board definitions if at all possible, due to the ongoing maintenance burden when upgrading ChibiOS +- New board definitions must not be embedded in a keyboard PR + - See _Core PRs_ below for the procedure for adding a new board to QMK - if a board definition is unavoidable, `board.c` must have a standard `__early_init()` (as per normal ChibiOS board defs) and an empty `boardInit()`: - see Arm/ChibiOS [early initialization](https://docs.qmk.fm/#/platformdev_chibios_earlyinit?id=board-init) - `__early_init()` should be replaced by either `early_hardware_init_pre()` or `early_hardware_init_post()` as appropriate @@ -118,7 +120,7 @@ Also, specific to ChibiOS: ## Core PRs - must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline -- any support for new hardware now requires a corresponding test board under `keyboards/handwired/onekey` +- any new boards adding support for new hardware now requires a corresponding test board under `keyboards/handwired/onekey` - for new MCUs, a new "child" keyboard should be added that targets your newly-added MCU, so that builds can be verified - for new hardware support such as display panels, core-side matrix implementations, or other peripherals, an associated keymap should be provided - if an existing keymap exists that can leverage this functionality this may not be required (e.g. a new RGB driver chip, supported by the `rgb` keymap) -- consult with the QMK Collaborators on Discord to determine if there is sufficient overlap already