# Prusa-Firmware-Buddy: the C firmware behind the MINI, MK4, XL and CORE One

> Prusa-Firmware-Buddy is the open source firmware for Prusa's 32-bit ARM 3D printers, covering the MINI, MK3.5, MK3.9, MK4, XL and CORE One, with a Python driven CMake build and a multi-printer XL architecture. It suits a firmware developer working on a Prusa printer, and the source is GPL while the graphics and design are non-commercial.

**prusa3d/Prusa-Firmware-Buddy** — Firmware for the Original Prusa MINI, Original Prusa MK4, Original Prusa XL and Prusa CORE One 3D printers by Prusa Research.

- Repository: https://github.com/prusa3d/Prusa-Firmware-Buddy
- Stars: 1,633 · Forks: 401
- Language: C
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/prusa3d-prusa-firmware-buddy

## One firmware codebase for six printer models

Prusa-Firmware-Buddy holds the source code and firmware releases for the Original Prusa 3D printers built on 32-bit ARM microcontrollers. The currently supported models are listed in the readme, and they are Original Prusa MINI and MINI+, Original Prusa MK3.5, Original Prusa MK3.9, Original Prusa MK4, Original Prusa XL, and Prusa CORE One.

The interesting engineering fact is that the MINI and the XL share a codebase despite being very different machines. The XL is a large format printer with a toolchanger style bed arrangement and multiple arms, and the MINI is a small enclosed printer, so the fact that one firmware tree drives both tells you the abstraction is at the level of motion control and peripherals rather than at the level of a printer product. A consequence of that design shows up in the release list, where different versions are tagged for different hardware. The listed releases are v6.9.2, titled as firmware for the Prusa CORE One+ (Gen 2) INDX and CORE One INDX, and v6.10.3, titled as firmware for the Prusa XL+ and XL, with v6.9.1 also listed. So the version line is shared but the artifacts are per model, which is the pattern you would expect from a codebase that has to support several boards.

The primary language is C, and the repository is a working development tree rather than a release archive. It carries a CMakeLists.txt and a CMakePresets.json at the top level, a ProjectOptions.cmake holding the build configuration variables, a Doxyfile for documentation, a .clang-format and a .clangd for the C tooling, a .pre-commit-config.yaml, a pyproject.toml with the pytest and pyright configuration, and a requirements.txt for the Python side.

## build.py is a wrapper around a CMake driven build

The build entry point is a Python script, and the readme is explicit about the relationship. The build process of the project is driven by CMake and build.py is just a high-level wrapper around it. The practical consequence is that almost any editor works, since most modern IDEs support some kind of CMake integration, and the repository ships setup notes for Visual Studio Code, Vim, Eclipse with STM32CubeIDE, and other LSP based IDEs including Atom and Sublime Text.

The requirements are Python 3.8 or newer, and a system installation of the requests package installed with pip or a system package manager. Cloning the repository is a plain git clone of the GitHub URL.

Running the build with no arguments builds a release version of the firmware for all supported printers and bootloader settings, and the binaries land under ./build/products. The options control the shape of the build. The --build-type flag selects the configuration, with debug and release listed. The --preset flag selects which printers to build for. The --host-tools flag includes host tools in the build. There is also a prerelease mode, which defaults to beta and can be changed with --prerelease alpha, or you can use --final to build a final version. The readme also shows how to point the build at a custom toolchain and how to select a different generator.

```bash
python utils/build.py --preset mini,xl --build-type debug
```

```bash
python utils/build.py --preset mini --toolchain cmake/AnyGccArmNoneEabi.cmake --generator 'Unix Makefiles'
```

That second example is worth noting, because using Make instead of Ninja is marked as not recommended, and the ability to substitute the arm-none-eabi toolchain is the kind of thing that matters when you are chasing a build difference between machines.

## The XL architecture and the puppies it has to look after

The XL case is the part of the project with real architectural weight, and the readme explains it in detail. The firmware of XLBuddy contains firmwares for the puppies, which are the Dwarf and the Modularbed, so it can flash them when necessary. There are several supported ways of dealing with those firmwares during development, and choosing between them is a real decision rather than a preference.

The first option is the default, building the Dwarf and Modularbed firmware automatically and flashing it on startup by XLBuddy, with the Dwarf and ModularBed firmware built from this repository, and the puppies required to be running the Puppy Bootloader. The second option is to use pre-built firmware and let XLBuddy flash it on startup, with the location of the binary file specified through DWARF_BINARY_PATH or MODULARBED_BINARY_PATH, for example by passing the path to a .bin file into the cmake configuration.

```bash
cmake .. --preset xl_release_boot -DDWARF_BINARY_PATH=/Downloads/dwarf-4.4.0-boot.bin
```

The third option is to exclude the puppy firmware entirely and have XLBuddy neither flash nor interact with the puppies, by setting ENABLE_PUPPY_BOOTLOAD to NO, and it is up to you to flash the correct firmware to the puppies in the noboot variant. The fourth is to keep the bootloaders but not write firmware on boot, with PUPPY_SKIP_FLASH_FW set to YES, so the project disables puppy flashing on boot while leaving the other puppies in their previous state, using a puppy build config with bootloaders such as xl-dwarf_debug_boot. The readme notes the cache variables are documented in ProjectOptions.cmake, and it recommends a breakpoint at the end of puppy_task_body() so that buddy does not reset the puppy immediately when it stops on a breakpoint.

This is a genuinely multi-processor design, and it is the part of the codebase where a newcomer should slow down.

## Tests, tooling and the Python side of the tree

The testing setup is documented in a comprehensive testing guide under tests/unit/README.md, and the Python tooling in the repository is worth a look because it tells you what the project uses for automation. The requirements file pins the toolchain, and the notable entries are numpy at a fixed version, pytest for the unit tests, and tree-sitter with tree-sitter-cpp, which is a parser for C++ used presumably to work with the source itself. There is also cbor2 for binary serialisation, pillow for image handling, qoi for image encoding, polib for translation files, nunavut for localisation, simple_parsing for argument parsing, and prek as a pre-commit runner, with gcovr for coverage reporting.

The pyproject.toml configures pytest with asyncio_mode set to auto, and pyright execution environments that add utils to the extra paths for the integration tests and for utils itself, which is a small sign that the integration test harness lives in utils and is written in Python rather than being part of the firmware.

The repository also has integration-test-requirements.txt, a separate file for the test dependencies, and an .editorconfig-adjacent set of formatting configuration, including a .cmake-format.py for the CMake files and a .git-blame-ignore-revs file, which is the convention for marking a bulk reformat commit so that git blame stays useful afterwards. There is a .github/ directory for the workflows, a .claude/ directory, a .vscode/ directory, a doc/ directory, and an include/, lib/ and src/ triple for the C sources, which is a Prusa convention where the public headers, the shared library and the application code are kept apart.

## Where Prusa-Firmware-Buddy is the wrong tool

Three cases argue against it. The first is being an end user. The readme is direct about the physical requirement, since to install custom firmware you have to break the appendix on the board, and it links a Prusa help article on how to do that. That is fine for a developer with a spare machine and a willingness to open it, and it is not fine for someone who wants to update their printer. Prusa ships ready made firmware releases in this repository, and the update path that the company supports is not a source build.

The second case is a commercial reuse of the assets. The licensing is split. The firmware source code is under the GNU General Public License v3.0, the graphics and design are under Attribution-NonCommercial-ShareAlike 4.0 International, and the fonts are under different terms with a pointer to LICENSE.md. So the code is copyleft and reusable, and the visual assets are not usable in a commercial product without a separate permission. A team shipping a printer product that reuses the UI assets has to deal with that, and a team shipping only the code does not.

The third case is a printer not on the list. The supported models are the MINI, MINI+, MK3.5, MK3.9, MK4, XL and CORE One, and the firmware is tied to the 32-bit ARM microcontrollers, so a printer with different hardware is a different project entirely.

On the practical side, the build is a firmware build, not an application build. You need the arm-none-eabi toolchain, and the readme's Windows troubleshooting note is about the Microsoft Store aliasing python.exe, which is the kind of environment friction that firmware development always brings. There is also a build flag worth knowing about, the --prerelease option, because by default the build produces beta firmware, and for anything you intend to flash onto a machine other people rely on, that distinction matters.

## Conclusion

Prusa-Firmware-Buddy suits a developer who wants to modify or audit the firmware running on a Prusa printer they own, and who can accept that the XL build also builds and flashes firmware for its companion boards. It does not suit an end user looking for a firmware updater, since installing custom firmware requires opening the printer, and it does not suit a product team wanting to reuse the graphics and design assets commercially, because those are under a non-commercial licence. Before you start, read LICENSE.md rather than assuming the GPL covers everything, check that your model is in the supported list, and note that the last push was on 2026-10-06 with the newest listed release v6.9.2 from 2026-10-07.

## FAQ

### Which Prusa printers does Prusa-Firmware-Buddy support?

The readme lists Original Prusa MINI and MINI+, MK3.5, MK3.9, MK4, XL, and Prusa CORE One, all built on 32-bit ARM microcontrollers.

### How do I build the firmware?

Run python utils/build.py, which is a wrapper around the CMake build, and the binaries end up under ./build/products. Use --preset to choose printers, --build-type for debug or release, --host-tools to include host tools, and --final to build a final rather than a beta prerelease.

### What are the puppies in the Prusa XL firmware?

They are the Dwarf and Modularbed boards, and the XL firmware contains their firmware so XLBuddy can flash it on startup. The readme describes four ways to handle them, from building and flashing them automatically, through using a prebuilt binary via DWARF_BINARY_PATH or MODULARBED_BINARY_PATH, to disabling puppy flashing entirely with ENABLE_PUPPY_BOOTLOAD or PUPPY_SKIP_FLASH_FW.

### Can I install custom firmware on my Prusa printer from this repository?

Yes, but it requires physical access. The readme says you have to break the appendix on the board and links a Prusa help article explaining how, and the repository also ships prebuilt firmware releases for ordinary updates.

## Sources

- [Issues](https://github.com/prusa3d/Prusa-Firmware-Buddy/issues)
- [prusa3d/Prusa-Firmware-Buddy on GitHub](https://github.com/prusa3d/Prusa-Firmware-Buddy)
- [README](https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/master/README.md)
- [Releases](https://github.com/prusa3d/Prusa-Firmware-Buddy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/prusa3d-prusa-firmware-buddy