diff options
| author | Nick Brassel <nick@tzarc.org> | 2022-01-24 09:15:09 +1100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-01-23 22:15:09 +0000 |
| commit | 7d6e15423be8c34dd456cd2c057f50f5c3d0a70c (patch) | |
| tree | 05bccee9ee8e71395c5a862d65c98a6dee081d7d /docs/pr_checklist.md | |
| parent | c30bdcbca8afe1d8d005843acec075f921813d44 (diff) | |
| download | qmk_firmware-7d6e15423be8c34dd456cd2c057f50f5c3d0a70c.tar.gz qmk_firmware-7d6e15423be8c34dd456cd2c057f50f5c3d0a70c.zip | |
Add some clarity regarding new board definitions (#16018)
Diffstat (limited to 'docs/pr_checklist.md')
| -rw-r--r-- | docs/pr_checklist.md | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/docs/pr_checklist.md b/docs/pr_checklist.md index 25f3d7662..1bd6200b8 100644 --- a/docs/pr_checklist.md +++ b/docs/pr_checklist.md | |||
| @@ -110,6 +110,8 @@ Also, specific to ChibiOS: | |||
| 110 | - 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 | 110 | - 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 |
| 111 | - example: For an STM32L082KZ, given the similarity to an STM32L073RZ, you can use `BOARD = ST_NUCLEO64_L073RZ` in rules.mk | 111 | - example: For an STM32L082KZ, given the similarity to an STM32L073RZ, you can use `BOARD = ST_NUCLEO64_L073RZ` in rules.mk |
| 112 | - QMK is migrating to not having custom board definitions if at all possible, due to the ongoing maintenance burden when upgrading ChibiOS | 112 | - QMK is migrating to not having custom board definitions if at all possible, due to the ongoing maintenance burden when upgrading ChibiOS |
| 113 | - New board definitions must not be embedded in a keyboard PR | ||
| 114 | - See _Core PRs_ below for the procedure for adding a new board to QMK | ||
| 113 | - if a board definition is unavoidable, `board.c` must have a standard `__early_init()` (as per normal ChibiOS board defs) and an empty `boardInit()`: | 115 | - if a board definition is unavoidable, `board.c` must have a standard `__early_init()` (as per normal ChibiOS board defs) and an empty `boardInit()`: |
| 114 | - see Arm/ChibiOS [early initialization](https://docs.qmk.fm/#/platformdev_chibios_earlyinit?id=board-init) | 116 | - see Arm/ChibiOS [early initialization](https://docs.qmk.fm/#/platformdev_chibios_earlyinit?id=board-init) |
| 115 | - `__early_init()` should be replaced by either `early_hardware_init_pre()` or `early_hardware_init_post()` as appropriate | 117 | - `__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: | |||
| 118 | ## Core PRs | 120 | ## Core PRs |
| 119 | 121 | ||
| 120 | - must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline | 122 | - must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline |
| 121 | - any support for new hardware now requires a corresponding test board under `keyboards/handwired/onekey` | 123 | - any new boards adding support for new hardware now requires a corresponding test board under `keyboards/handwired/onekey` |
| 122 | - for new MCUs, a new "child" keyboard should be added that targets your newly-added MCU, so that builds can be verified | 124 | - for new MCUs, a new "child" keyboard should be added that targets your newly-added MCU, so that builds can be verified |
| 123 | - for new hardware support such as display panels, core-side matrix implementations, or other peripherals, an associated keymap should be provided | 125 | - for new hardware support such as display panels, core-side matrix implementations, or other peripherals, an associated keymap should be provided |
| 124 | - 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 | 126 | - 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 |