Merge remote-tracking branch 'upstream/develop' into xap

docs/breaking_changes.md

@@ -47,30 +47,11 @@ Criteria for acceptance:
     * This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PR's ID.
     * One strong recommendation that the ChangeLog document matches the PR description on GitHub, so as to ensure traceability.
 
-# Checklists
+## Checklists
 
 This section documents various processes we use when running the Breaking Changes process.
 
-## Creating the `develop` branch
-
-This happens immediately after the previous `develop` branch is merged.
-
-* `qmk_firmware` git commands
-    * [ ] `git checkout master`
-    * [ ] `git pull --ff-only`
-    * [ ] `git checkout develop`
-    * [ ] `git pull --ff-only`
-    * [ ] `git merge -no-ff master`
-    * [ ] Edit `readme.md`
-        * [ ] Add a big notice at the top that this is a testing branch.
-        * [ ] Include a link to this document
-    * [ ] `git commit -m 'Branch point for <DATE> Breaking Change'`
-    * [ ] `git tag breakpoint_<YYYY>_<MM>_<DD>`
-    * [ ] `git tag <next_version>` # Prevent the breakpoint tag from confusing version incrementing
-    * [ ] `git push upstream develop`
-    * [ ] `git push --tags`
-
-## 4 Weeks Before Merge
+### 4 Weeks Before Merge
 
 * `develop` is now closed to new PR's, only fixes for current PR's may be merged
 * Post call for testers
@@ -78,7 +59,7 @@ This happens immediately after the previous `develop` branch is merged.
     * [ ] GitHub PR
     * [ ] https://reddit.com/r/olkb
 
-## 2 Weeks Before Merge
+### 2 Weeks Before Merge
 
 * `develop` is now closed to existing PR merges, only bugfixes for previous merges may be included
 * Post call for testers
@@ -86,21 +67,21 @@ This happens immediately after the previous `develop` branch is merged.
     * [ ] GitHub PR
     * [ ] https://reddit.com/r/olkb
 
-## 1 Week Before Merge
+### 1 Week Before Merge
 
 * Announce that master will be closed from <2 Days Before> to <Day of Merge>
     * [ ] Discord
     * [ ] GitHub PR
     * [ ] https://reddit.com/r/olkb
 
-## 2 Days Before Merge
+### 2 Days Before Merge
 
 * Announce that master is closed for 2 days
     * [ ] Discord
     * [ ] GitHub PR
     * [ ] https://reddit.com/r/olkb
 
-## Day Of Merge
+### Day Of Merge
 
 * `qmk_firmware` git commands
     * [ ] `git checkout develop`
@@ -117,8 +98,39 @@ This happens immediately after the previous `develop` branch is merged.
     * [ ] `git checkout master`
     * [ ] `git pull --ff-only`
     * [ ] `git merge --no-ff develop`
+    * [ ] `git tag <next_version>` # Prevent the breakpoint tag from confusing version incrementing
+    * [ ] `git push upstream <next_version>`
     * [ ] `git push upstream master`
 
 ## Post-merge operations
 
+### Updating the `develop` branch
+
+This happens immediately after the previous `develop` branch is merged to `master`.
+
+* `qmk_firmware` git commands
+    * [ ] `git checkout master`
+    * [ ] `git pull --ff-only`
+    * [ ] `git checkout develop`
+    * [ ] `git pull --ff-only`
+    * [ ] `git merge --no-ff master`
+    * [ ] Edit `readme.md`
+        * [ ] Add a big notice at the top that this is a testing branch.
+        * [ ] Include a link to this document
+    * [ ] `git commit -m 'Branch point for <DATE> Breaking Change'`
+    * [ ] `git tag breakpoint_<YYYY>_<MM>_<DD>`
+    * [ ] `git push upstream breakpoint_<YYYY>_<MM>_<DD>`
+    
+* All submodules under `lib` now need to be checked against their QMK-based forks:
+    * [ ] `git submodule foreach git log -n1`
+    * [ ] Validate each submodule SHA1 matches the qmk fork, e.g. for ChibiOS:
+        * Go to [qmk/ChibiOS](https://github.com/qmk/ChibiOS)
+        * Compare the commit hash in the above output to the commit hash in the repository
+        * If there's a mismatch:
+            * [ ] `cd lib/chibios`
+            * [ ] `git fetch --all`
+            * [ ] `git checkout master`
+            * [ ] `git reset --hard <commit hash>`
+            * [ ] `git push origin master --force-with-lease`
+
 * (Optional) [update ChibiOS + ChibiOS-Contrib on `develop`](chibios_upgrade_instructions.md)

docs/feature_split_keyboard.md

@@ -141,6 +141,9 @@ Next, you will have to flash the EEPROM files once for the correct hand to the c
 * ARM controllers with a DFU compatible bootloader (e.g. Proton-C):
   * `:dfu-util-split-left`
   * `:dfu-util-split-right`
+* ARM controllers with a UF2 compatible bootloader:
+  * `:uf2-split-left`
+  * `:uf2-split-right`
 
 Example:
 

docs/flashing.md

@@ -266,7 +266,7 @@ Flashing sequence:
 ### `make` Targets
 
 * `:dfu-util`: Waits until an STM32 bootloader device is available, and then flashes the firmware.
-* `:dfu-util-split-left` and `:dfu-util-split-right`: Flashes the firmware as with `:avrdude`, but also sets the handedness setting in EEPROM. This is ideal for Proton-C-based split keyboards.
+* `:dfu-util-split-left` and `:dfu-util-split-right`: Flashes the firmware as with `:dfu-util`, but also sets the handedness setting in EEPROM. This is ideal for Proton-C-based split keyboards.
 * `:st-link-cli`: Allows you to flash the firmware via the ST-Link CLI utility, rather than dfu-util. Requires an ST-Link dongle.
 * `:st-flash`: Allows you to flash the firmware via the `st-flash` utility from [STLink Tools](https://github.com/stlink-org/stlink), rather than dfu-util. Requires an ST-Link dongle.
 
@@ -358,3 +358,7 @@ CLI Flashing sequence:
 2. Wait for the OS to detect the device
 3. Flash via QMK CLI eg. `qmk flash --keyboard handwired/onekey/blackpill_f411_tinyuf2 --keymap default`
 4. Wait for the keyboard to become available
+
+### `make` Targets
+
+* `:uf2-split-left` and `:uf2-split-right`: Flashes the firmware but also sets the handedness setting in EEPROM by generating a side specific firmware.

docs/zh-cn/flashing.md

@@ -252,7 +252,7 @@ BOOTLOADER = stm32-dfu
 ### `make` 构建目标
 
 * `:dfu-util`: 每5秒检测一次直到发现可用的STM32 bootloader设备，然后进行固件刷写。
-* `:dfu-util-split-left` 和 `:dfu-util-split-right`: 同 `:avrdude` 一样会刷写固件，但额外地会设置手性设置到EEPROM中，对于基于Proton-C的分体式键盘这是理想的方法。
+* `:dfu-util-split-left` 和 `:dfu-util-split-right`: 同 `:dfu-util` 一样会刷写固件，但额外地会设置手性设置到EEPROM中，对于基于Proton-C的分体式键盘这是理想的方法。
 * `:st-link-cli`: 通过ST-Link CLI工具集而非dfu-util进行刷写，需要有ST-Link电子狗。
 * `:st-flash`: 通过[STLink工具](https://github.com/stlink-org/stlink)内的 `st-flash` 工具而非dfu-util进行刷写，需要有ST-Link电子狗。