-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bootloader/retention boot mode support #2683
Open
petejohanson
wants to merge
3
commits into
zmkfirmware:main
Choose a base branch
from
petejohanson:bootloader/retention-boot-mode-support
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Bootloader/retention boot mode support #2683
petejohanson
wants to merge
3
commits into
zmkfirmware:main
from
petejohanson:bootloader/retention-boot-mode-support
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If this passes all the various testing, we'd probably want to add some either .dtsi files, snippets, or both, to allow for consistent setup of the devicetree/Kconfig bits. |
96c6d03
to
6976913
Compare
6976913
to
08df8ab
Compare
08df8ab
to
f8fd36e
Compare
Tested successfully on "Bruce the Keyboard" (STM32F072). Output from QMK Toolbox
|
To trigger bootloaders that use a magic value in RAM to trigger bootloader mode, add a mapping retained memory driver that maps write/read of boot mode values to a special magic value stored in the actually backing RAM.
Support new generic Zephyr retention boot mode API in the reset behavior.
f8fd36e
to
1d6658d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
behaviors
board
PRs and issues related to boards.
core
Core functionality/behavior of ZMK
enhancement
New feature or request
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ok, expanding our support for entering the bootloader on more targets!
Overview
This PR works to expand our bootloader support beyond the Adafruit nRF bootloader by moving to new (relatively) new Zephyr retention boot mode support. The scope of this change includes:
BOOT_MODE_TYPE_BOOTLOADER
to storing the 32-bit "magic value" to the real underlying retention location.v3.5+zmk-fixes
branch that includes a new STM32 bootloader support, to jump automatically to the ROM bootloader when startup determines the bootmode was set to bootloader before the restart. This piece is tested on stm32f072 only so far, my testing on F4 is complicated by all my devices having tinyuf2 flashed to them as a second stage bootloader.Bootloaders Supported
Adafruit nRF52
The nRF52 bootloader should be supported, will be testing this more tomorrow, by the following:
And enabling:
Adafruit bossa/samd21 and tinyuf2 UF2 Bootloaders
The adafruit tinyuf2 and samd21 bootloaders both use the same magic value stored in the last 4 bytes of RAM to trigger bootloader mode, so the setup for these two bootloaders is effectively the same:
Here is an example for samd21e18 (which has 32K of RAM)
Devicetree:
Kconfig settings:
Similar mechanism forks on stm32f4 with tinyuf2 as long as you use the correct reg/offsets for the RAM on the given device.
STM32 ROM Bootloader
The STM32 ROM bootloader is handled a bit differently, using an early init callback that checks the bootmode in RAM, and if finding
BOOT_MODE_TYPE_BOOTLOADER
, uses a small bit of code to de-init and jump to the bootloader directly. That means no magic value mapping has to occur.The following works on stm32f072.
Devicetree:
This also requires the ROM bootloader details (found in AN2606 from ST) has been added to the SoC .dtsi file, e.g. from https://github.com/zmkfirmware/zephyr/pull/39/files#diff-c3c466b9a87ae3801f4ebf6b99797e29304b66407ef9393c203b92896eafd229
Kconfig:
Testing
I've specifically tested so far:
Still needs testing: