# RFC: embed the build configuration in the identify dictionary

**URL:** <https://klipper.discourse.group/t/rfc-embed-the-build-configuration-in-the-identify-dictionary/26245>\
**Category:** Developers\
**Created:** [August 16, 2026, 9:06pm UTC](https://klipper.discourse.group/t/rfc-embed-the-build-configuration-in-the-identify-dictionary/26245 "2026-08-16T21:06:15Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![mjonuschat](https://avatars.discourse-cdn.com/v4/letter/m/ecccb3/32.png) [@mjonuschat](https://klipper.discourse.group/u/mjonuschat)\
**Post date:** [August 16, 2026, 9:06pm UTC](https://klipper.discourse.group/t/rfc-embed-the-build-configuration-in-the-identify-dictionary/26245/1 "2026-08-16T21:06:15Z")

</div>

A Klipper `.config` lives in one file at the repo root, overwritten every time you run `make menuconfig` for a different board. Once firmware is flashed there’s no record of how it was produced. Anyone running multiple boards runs into this eventually: a board is running firmware that is hard to reproduce, there’s no way to confirm a restored `.config` matches what’s running. Any tool that wants to rebuild firmware for an existing board has to ask a human first.

## Proposal

Have firmware report its own build configuration, in minimal `savedefconfig` form, through the identify dictionary it already serves over the wire. One new key, `kconfig`:

```auto
"kconfig": {
  "defconfig": "CONFIG_MACH_STM32=y\nCONFIG_MACH_STM32F407=y\n"
}

```

The (compressed) dictionary and the `identify` command both already exist, so the protocol wouldn’t need to change. It’d take one `make` rule plus a small handler in `buildcommands.py`. `savedefconfig.py` is already part of the vendored kconfiglib, just not wired up.

Since `savedefconfig` only records what deviates from Kconfig defaults, the payload would track how customized a board’s config is, not the size of the whole tree. A near-default board would cost next to nothing to embed. A board with a lot of non-default options set would cost more, but it’d still be a handful of lines compared to a multi-KB `.config` dump, compressing alongside data that’s already going into the dictionary.

What this would touch: a `make` step that regenerates the minimal config on every build, wired so a config change couldn’t leave a stale payload behind, plus exposing it on the host the same way existing build info already works.

This is self-reported metadata, not an attempt at attestation, and does not guarantee that replaying it later reproduces a byte-identical binary, since defaults can shift between revisions.

Happy to open a PR if this sounds interesting.

---

<div class="post-metadata">

**Author:** ![nefelim4ag](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/nefelim4ag/32/2387_2.png) [@nefelim4ag](https://klipper.discourse.group/u/nefelim4ag)\
**Post date:** [August 16, 2026, 9:42pm UTC](https://klipper.discourse.group/t/rfc-embed-the-build-configuration-in-the-identify-dictionary/26245/2 "2026-08-16T21:42:29Z")

</div>

FWIW, under normal circumstances, menuconfig is pretty small, for example:

```auto
[*] Enable extra low-level configuration options
    Micro-controller Architecture (STMicroelectronics STM32) --->
    Processor model (STM32F407) --->
    Bootloader offset (32KiB bootloader) --->
    Clock Reference (8 MHz crystal) --->
    Communication interface (USB (on PA11/PA12)) --->
    USB ids --->
[*] Optimize stepper code for 'step on both edges' (NEW)
() GPIO pins to set at micro-controller startup

```

Where one only cares about the MCU model, bootloader offset, clock reference, communication type, and pins.

They are partially defined in the “config” section:

```JSON
{
  "config": {
    "ADC_MAX": 4095,
    "BUS_PINS_i2c1": "PB6,PB7",
...
    "CLOCK_FREQ": 168000000,
    "MCU": "stm32f407xx", # < this
    "PWM_MAX": 32768,
    "RECEIVE_WINDOW": 192,
    "RESERVE_PINS_CAN": "PB8,PB9", # < this
    "RESERVE_PINS_USB": "PA11,PA12", # < this
    "RESERVE_PINS_crystal": "PH0,PH1",
    "STATS_SUMSQ_BASE": 256,
    "STEPPER_OPTIMIZED_EDGE": 21,
    "STEPPER_STEP_BOTH_EDGE": 1
  },
}

```

So, from my PoV, if one wants to save something crucial to reproduce the firmware, it could be the clock reference crystal or the bootloader offset.

Otherwise, there were some old ideas about how to deal with firmware updates: [Experiment with automated mcu flashing](https://klipper.discourse.group/t/experiment-with-automated-mcu-flashing/1691)

I’m not saying that you should or shouldn’t do, I’m just adding some context.

My personal solution is pretty simple; I save the configs:

```auto
ls -l ./.config*
-rw-r--r-- 1 user user 4375 Aug 16 23:35 ./.config
-rw-r--r-- 1 user user 4153 Nov 8 2025 ./.config_back
-rw-r--r-- 1 user user 4098 Nov 21 2025 ./.config_carto
-rw-r--r-- 1 user user 4306 Nov 19 2025 ./.config_ebb42
-rw-r--r-- 1 user user 4102 Aug 16 23:33 ./.config.old
-rw-r--r-- 1 user user 2322 Jan 26 2025 ./.config_rp2040
-rw-r--r-- 1 user user 3858 Dec 11 2025 ./.config_stm32

```

IIRC, there were some automated solutions with saved configs.

Hope that explains something,  
-Timofey

---

<div class="post-metadata">

**Author:** ![mjonuschat](https://avatars.discourse-cdn.com/v4/letter/m/ecccb3/32.png) [@mjonuschat](https://klipper.discourse.group/u/mjonuschat)\
**Post date:** [August 16, 2026, 9:56pm UTC](https://klipper.discourse.group/t/rfc-embed-the-build-configuration-in-the-identify-dictionary/26245/3 "2026-08-16T21:56:33Z")

</div>

Yes, this is exactly why I am proposing the `savedefconfig`, it would just save the delta to the menuconfig. It’s an integral part of the kconfig lib. This is an example from an Octopus Pro (H723):

```auto
{
    "mcu_kconfig": {
        "defconfig": "CONFIG_LOW_LEVEL_OPTIONS=y\nCONFIG_MACH_STM32=y\nCONFIG_MACH_STM32H723=y\nCONFIG_STM32_CLOCK_REF_25M=y\n# CONFIG_USB_SERIAL_NUMBER_CHIPID is not set\n# CONFIG_WANT_HX71X is not set\nCONFIG_INITIAL_PINS=PD12\n"
    }
}

```

So it only saves the things you mentioned like MCU type, clock frequency and other overrides like the initial pins.

Saving the configs on disk is obviously a working solution - this would just enable tooling to query the board instead of relying on on-disk configs (after the initial flash).

---

<div class="post-metadata">

**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\
**Post date:** [August 18, 2026, 5:32pm UTC](https://klipper.discourse.group/t/rfc-embed-the-build-configuration-in-the-identify-dictionary/26245/4 "2026-08-18T17:32:23Z")

</div>

For what it is worth, the reason I did not originally have the code save the kconfig in the final binary is that some chips have very tiny flash sizes and the kconfig can be quite large. If `savedefconfig` can actually produce a relatively small description then I think it could be useful.

Cheers,  
-Kevin

---

<div class="post-metadata">

**Author:** ![mjonuschat](https://avatars.discourse-cdn.com/v4/letter/m/ecccb3/32.png) [@mjonuschat](https://klipper.discourse.group/u/mjonuschat)\
**Post date:** [August 20, 2026, 5:16pm UTC](https://klipper.discourse.group/t/rfc-embed-the-build-configuration-in-the-identify-dictionary/26245/5 "2026-08-20T17:16:03Z")

</div>

Thank you both for your insights. I’ll clean up my prototype and send a PR on GitHub.

I’ll try to collect some real world size comparisons. I think the V0 display might be a good example. Any other configs that are size constrained and would make good test subjects?

---

<div class="post-metadata">

**Author:** ![mjonuschat](https://avatars.discourse-cdn.com/v4/letter/m/ecccb3/32.png) [@mjonuschat](https://klipper.discourse.group/u/mjonuschat)\
**Post date:** [August 30, 2026, 4:35am UTC](https://klipper.discourse.group/t/rfc-embed-the-build-configuration-in-the-identify-dictionary/26245/6 "2026-08-30T04:35:25Z")

</div>

PR: [build: expose minimal Kconfig in MCU identify data by mjonuschat · Pull Request #7357 · Klipper3d/klipper · GitHub](https://github.com/Klipper3d/klipper/pull/7357)

---

<div class="post-metadata">

**Author:** ![mjonuschat](https://avatars.discourse-cdn.com/v4/letter/m/ecccb3/32.png) [@mjonuschat](https://klipper.discourse.group/u/mjonuschat)\
**Post date:** [September 25, 2026, 2:11am UTC](https://klipper.discourse.group/t/rfc-embed-the-build-configuration-in-the-identify-dictionary/26245/7 "2026-09-25T02:11:41Z")

</div>

Here’s an initial tool that builds on top of this work and tries to make updating MCUs easier: [GitHub - mjonuschat/aldis: MCU firmware updater for Klipper printers · GitHub](https://github.com/mjonuschat/aldis)