Storage
RMK's storage system provides persistent data storage for keyboard settings, keymaps, and system configuration. It uses your microcontroller's internal flash memory to save changes between power cycles.
default storage configuration works perfectly. If there's no default config for your chip, the last two sectors will be used. In most cases, you only need to modify settings for advanced use cases or when troubleshooting storage-related issues.
The [storage] section in keyboard.toml configures RMK's storage.
Configuration Options
enabled must agree with the storage Cargo feature of the rmk crate in both directions: enabled = false requires disabling the feature (for example with default-features = false), and a build without the feature requires enabled = false. The build fails otherwise.
Storage and DFU
When using DFU (dfu_rp / dfu_nrf), the storage partition is placed after the DFU download slot, determined by the rmk-memory.x linker script. In this mode:
start_addris ignored — RMK automatically places storage at the address defined inrmk-memory.x(__bootloader_storage_start).- The default
num_sectorsis 8 (32 KB, matching rmk-boot's default storage area). You can overridenum_sectorsto use fewer sectors, but cannot exceed the allocated area.
If you change the storage size in rmk-boot's build.rs, rebuild the bootloader and regenerate rmk-memory.x. All partition addresses recalculate automatically.
Every firmware build embeds a unique build hash, and on boot RMK compares it with the hash saved in Flash. If they differ (for example after flashing a new build), the whole storage area is erased and re-initialized with the firmware's defaults, so saved keymap changes and BLE bonds don't survive a firmware update.