Julian Oes 1a3d232e7b fix(bootloader): remove broken PROTO_SET_DELAY boot-delay feature (#27081)
The bootloader boot-delay feature has been mechanically broken on
every modern FMU board since the STM32F7/H7 transition. It has three
independent bugs that prevent it from ever working:

1. Offset mismatch: BOOT_DELAY_ADDRESS is hardcoded to 0x1a0, but the
   NuttX vector table is 504 B (F76x) to 664 B (H743) long. The
   linker places _bootdelay_signature at ALIGN(32) past end of
   vectors (e.g. 0x2a0 on CubeOrange), never at 0x1a0. The bootloader
   reads random exception_common pointers in place of the magic and
   never matches BOOT_DELAY_SIGNATURE1/2. Verified on CubeOrange with
   objdump of cubepilot_cubeorange_default.elf.

2. Flash cache never flushes: fc_write() stores arbitrary writes in
   cache line 1 and only flushes on a very specific condition tied
   to the sequential firmware upload flow. A standalone write during
   PROTO_SET_DELAY is cached forever. fc_read() then returns the
   cached value, so the post-write verify lies and the bootloader
   reports success. Nothing ever reaches flash.

3. H7 write granularity: the STM32H7 flash controller requires a
   full 32-byte program cycle per write. Single 32-bit writes from
   flash_func_write_word() would not be accepted by the controller
   even if they reached it.

The feature has been silently dead on every H7/F7 FMU board for
years and no one noticed, which is strong evidence nothing actually
depends on it. Rather than fix it (which would mean rewriting
PROTO_SET_DELAY, the flash cache path, and the H7 flash programming
path), remove it.

Changes:
- bl.c: PROTO_SET_DELAY case now immediately NACKs (goto cmd_bad)
  so clients that still send the command get a clear rejection
  instead of the previous silent fake-success. The opcode stays in
  the protocol enum for backwards compatibility.
- bl.h: drop BOOT_DELAY_SIGNATURE1/2 and BOOT_DELAY_MAX.
- stm/stm32_common/main.c, nxp/imxrt_common/main.c: drop the
  startup boot-delay sig check block.
- image_toc.c: decouple find_toc() from BOOT_DELAY_ADDRESS.
  BOARD_IMAGE_TOC_OFFSET is now the required define when
  BOOTLOADER_USE_TOC is enabled. The body is wrapped in #ifdef
  BOOTLOADER_USE_TOC and falls back to a stub returning false when
  the TOC is not in use (no upstream board currently enables it).
- Linker scripts: strip EXTERN(_bootdelay_signature) and the
  FILL/. += 8 block from all 142 affected .ld files across boards/.
- hw_config.h: strip the #define BOOT_DELAY_ADDRESS and its comment
  block entry from all 48 affected boards.
- Tools/px4_uploader.py, Tools/teensy_uploader.py: remove --boot-delay,
  set_boot_delay(), and SET_BOOT_DELAY client-side counterpart.

Smoke-built on cubepilot_cubeorange_default and
cubepilot_cubeorange_bootloader; no link errors, no unresolved
symbols, flash usage unchanged.

Tested:
- New BL, new FW
- Old BL, old FW
- Old BL, new FW
- New BL, old FW
2026-04-29 13:04:03 +12:00
2026-04-28 22:23:25 +00:00

PX4 Autopilot

The autopilot stack the industry builds on.

Release DOI Discord

OpenSSF Best Practices LFX Health Score LFX Contributors LFX Active Contributors


About

PX4 is an open-source autopilot stack for drones and unmanned vehicles. It supports multirotors, fixed-wing, VTOL, rovers, and many more experimental platforms from racing quads to industrial survey aircraft. It runs on NuttX, Linux, and macOS. Licensed under BSD 3-Clause.

Why PX4

Modular architecture. PX4 is built around uORB, a DDS-compatible publish/subscribe middleware. Modules are fully parallelized and thread safe. You can build custom configurations and trim what you don't need.

Wide hardware support. PX4 runs on a wide range of autopilot boards and supports an extensive set of sensors, telemetry radios, and actuators through the Pixhawk ecosystem.

Developer friendly. First-class support for MAVLink and DDS / ROS 2 integration. Comprehensive SITL simulation, hardware-in-the-loop testing, and log analysis tools. An active developer community on Discord and the weekly dev call.

Vendor neutral governance. PX4 is hosted under the Dronecode Foundation, part of the Linux Foundation. Business-friendly BSD-3 license. No single vendor controls the roadmap.

Supported Vehicles

Multicopter
Multicopter
Fixed Wing
Fixed Wing
VTOL
VTOL
Rover
Rover

…and many more: helicopters, autogyros, airships, submarines, boats, and other experimental platforms. These frames have basic support but are not part of the regular flight-test program. See the full airframe reference.

Try PX4

Run PX4 in simulation with a single command. No build tools, no dependencies beyond Docker:

docker run --rm -it -p 14550:14550/udp px4io/px4-sitl:latest

Open QGroundControl and fly. See PX4 Simulation Quickstart for more options.

Build from Source

git clone https://github.com/PX4/PX4-Autopilot.git --recursive
cd PX4-Autopilot
make px4_sitl

Note

See the Development Guide for toolchain setup and build options.

Documentation & Resources

Resource Description
User Guide Build, configure, and fly with PX4
Developer Guide Modify the flight stack, add peripherals, port to new hardware
Airframe Reference Full list of supported frames
Autopilot Hardware Compatible flight controllers
Release Notes What's new in each release
Contribution Guide How to contribute to PX4

Community

Contributing

We welcome contributions of all kinds — bug reports, documentation, new features, and code reviews. Please read the Contribution Guide to get started.

Citation

If you use PX4 in academic work, please cite it. BibTeX:

@software{px4_autopilot,
  author    = {Meier, Lorenz and {The PX4 Contributors}},
  title     = {{PX4 Autopilot}},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.595432},
  url       = {https://px4.io}
}

The DOI above is a Zenodo concept DOI that always resolves to the latest release. For a version-pinned citation, see the Zenodo record or our CITATION.cff.

Governance

The PX4 Autopilot project is hosted by the Dronecode Foundation, a Linux Foundation Collaborative Project. Dronecode holds all PX4 trademarks and serves as the project's legal guardian, ensuring vendor-neutral stewardship — no single company owns the name or controls the roadmap. The source code is licensed under the BSD 3-Clause license, so you are free to use, modify, and distribute it in your own projects.

Dronecode Logo

Languages
C++ 49.9%
C 37.2%
CMake 4.6%
Python 3.7%
Linker Script 3%
Other 1.4%