mfulz_github/qmk_firmware
1
0
Fork 1
mirror of https://github.com/mfulz/qmk_firmware.git synced 2025-10-31 13:22:31 +01:00
Code Issues Projects Releases Wiki Activity

Deploying to gh-pages from master @ 7d6e15423be8c34dd456cd2c057f50f5c3d0a70c 🚀

Browse Source
This commit is contained in:
zvecr 2022-01-23 22:17:09 +00:00
parent 17225ab284
commit c61d37e159
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
pr_checklist.md
View File

@ -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 - 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 - 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 - 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()`: - 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) - 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 - `__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 ## Core PRs
- must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline - 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 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 - 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 - 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