log_transfer crashed with a raw ImportError on setups whose pymavlink
predates the mavftp module (#27840). mavftp first shipped in pymavlink
2.4.42, so raise the floor in pyproject.toml, Tools/setup/requirements.txt
and the README, and guard the import in px4bench.ftp so an old install
reports a clear upgrade hint instead of a traceback. Both mavftp
consumers now import it through the guard.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Homebrew rebuilds and drops the gz bottles whenever homebrew-core bumps
protobuf or abseil, which breaks the macOS Gazebo install until the pins
catch up. conda-forge keeps every package it has published, so
Tools/setup/macos/pixi.toml and its lock install the same gz, protobuf,
abseil, OpenCV and GStreamer binaries until the lock is updated on
purpose. OpenCV is the headless build, and GStreamer brings the good,
bad and ugly plugin sets the gz camera plugin's pipeline uses.
macos.sh installs the environment with pixi and loads it from the venv
activation through a small script, since pixi shell-hook would export
the installing shell's PATH. The build and the gz launch do not depend
on that activation: CMake searches the environment like it pins the
.venv Python, and px4-rc.gzsim sources gz_env.sh before it looks for
gz, which loads the environment when it is not already active and puts
its lib dir ahead of Homebrew's in the dyld fallback path.
conda-forge's gz-transport13 does not pull in cppzmq, so the manifest
lists it.
The osrf/simulation pin, the protobuf pin and the weekly bot that
refreshed them are removed. The homebrew-core commit moves into
homebrew-pins.txt unchanged.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
PX4 SIH with the Hawkeye visualizer replaces jMAVSim, in SITL and as the
display-only viewer for SIH running on hardware. Drop the jMAVSim
submodule, its make targets, px4-rc.jmavsim, the 10017_jmavsim_iris
airframe and the VS Code debug helpers, stop installing Java and ant in
the macOS and Arch setup scripts, and point the remaining mentions at SIH
and Hawkeye.
BREAKING CHANGE: make px4_sitl jmavsim and SYS_AUTOSTART 10017 no longer
exist. Use make px4_sitl_sih sihsim_quadx with Hawkeye instead.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The job ran brew update and then installed whatever Homebrew was publishing, except Gazebo, which stayed on one commit. Those were built against different protobufs, so a release upstream failed the build with no commit here. Check the package repos out at commits recorded in the tree and do not update them. Run on macos-15 only, so the OS label cannot move either.
Assisted-by: Grok:grok-4.7
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The build runs brew update and then pours Gazebo from one pinned tap commit while the rest of the install, including protobuf, comes from current Homebrew. A release in either repo fails the check with no commit here, and the GitHub-hosted image moves on its own, so the job cannot be a closed set. Drop the build and the weekly pin refresh. The setup script, the pins, and the refresh script stay for local use.
Assisted-by: Grok:grok-4.7
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Every gz .pb.h refuses to compile against anything but the exact protobuf
its gencode came from, so the bottles gz-tap-pin.txt holds osrf/simulation
at only build against the protobuf homebrew-core shipped the day OSRF built
them. homebrew-core moves protobuf on its own schedule and OSRF rebuilds
days later, so `make px4_sitl` has been failing on macOS on every branch
since homebrew-core shipped protobuf 36.2.
Pin protobuf as well, to the homebrew-core revision that installs the
version the pinned gz bottles carry, and derive that pin from the bottles
themselves so the two can never disagree. A protobuf release then becomes a
no-op here instead of days of red CI while OSRF catches up.
The pinned install has to run after the other simulation packages and with
the dependents check off: opencv@4 depends on protobuf too, brew resolves a
dependency against the versions recorded in the dependent's bottle, and it
reinstalls dependents whose linkage it has just broken. Pinning the formula
with `brew pin` is not an option either, brew then refuses to install
anything that depends on it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julian Oes <julian@oes.ch>
* fix(macos.sh): trust brew taps before tapping them
Recent Homebrew validates every formula of a tap while tapping it. On
Homebrew 6.0+ loading a formula from an untrusted tap is refused, so
`brew tap osx-cross/arm` and `brew tap PX4/px4` now fail with
"Cannot tap ...: invalid syntax in tap!" because `brew trust` only ran
afterwards. Without the PX4/px4 tap, `brew install` aborts on `fastdds`
before pouring any package, ccache included, and the macOS CI job dies
with `ccache: command not found`. main has been red since 2026-09-14.
Run `brew trust` before `brew tap`; it accepts taps that are not
installed yet.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(macos.sh): trust osrf/simulation tap before tapping it
Same ordering problem as the toolchain taps: with Homebrew 6.0+ tapping
an untrusted tap fails, so there is no tap clone to apply the
gz-tap-pin.txt pin to. The later install of
osrf/simulation/gz-harmonic then taps it implicitly at HEAD, silently
skipping the pin and risking Gazebo building from source.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julian Oes <julian@oes.ch>
* fix(macos.sh): set -e to abort on first failure
The script kept going after a failed `brew tap` or `brew install`, so
the macOS CI job only failed much later with `ccache: command not
found`, far away from the actual cause.
Add `set -e`. Commands that are allowed to fail (`brew uninstall flock`
on a machine without it, `brew doctor` warnings, fetching the gz tap pin
whose failure is already handled by the following checkout) get an
explicit `|| true`.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Signed-off-by: Julian Oes <julian@oes.ch>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Co-authored-by: Julian Oes <julian@oes.ch>
The bash version spent most of its lines on plumbing: parsing a report
back out of a per-commit `brew ruby` child, awk and herestrings for set
logic, bash 3.2 workarounds, and a trap to restore the tap. The job
itself is small and lives inside Homebrew anyway, so run the whole thing
under Homebrew's Ruby and call its tap, formula and bottle APIs directly.
One process instead of one Homebrew startup per candidate commit, the
tap checkout restored by ensure, tarballs checked with Net::HTTP, and no
second language embedded in a string. Formulary.clear_cache and
Tap#clear_cache between checkouts keep each candidate's formulae fresh.
GITHUB_OUTPUT still arrives because brew forwards GITHUB_* whenever CI
is set. Same walk, same exemption for formulae unbottled at the pin,
same outputs; verified to pick the same commit as the bash version.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
homebrew-core moved to protobuf 36.0 and abseil 20260817.0, and the
macos-15 runner image (20260828) now ships that snapshot. The gz bottles
at the pinned commit c90f81ac were built against protobuf 35.1, so the
gz_bridge build fails on every run since today with
gz/msgs/details/discovery.pb.h:17:2: fatal error: "Protobuf C++
gencode is built with an incompatible version of"
on main as well as on this PR. 43aee9cc is tap HEAD, where OSRF has
rebuilt every gz-harmonic dependency for protobuf 36.0 and abseil
20260817.0 (the gz-msgs10 10.4.0_2 bottle's INSTALL_RECEIPT records
both). Tools/ci/refresh_gz_tap_pin.sh picked this commit.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The weekly refresh workflow carried its logic inline, compared only the
tap SHA against the pin, and duplicated the --sim-tools package list.
`brew install --dry-run` never prints "from source", so its bottle check
could not fire.
Tools/ci/refresh_gz_tap_pin.sh now owns the job and the workflow calls
it. It reads the osrf/simulation formulae from macos.sh, walks the tap
from HEAD back to the pin, asks Homebrew at each commit whether every
formula in the runtime closure has a bottle for the host, HEAD-requests
each tarball, and rewrites the pin to the first commit that passes.
Formulae with no bottle at the current pin (the gz-harmonic
meta-formula, which OSRF never bottles) are not required.
peter-evans/create-pull-request opens or updates the bot PR from the
script's outputs, so an unmerged bump is refreshed instead of duplicated.
The job runs on macos-15, the oldest macOS in compile_macos.yml, because
Homebrew pours an older macOS bottle onto a newer one, not the reverse.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
macos.sh only pinned osrf/simulation when --ci was passed, so dev
machines still hit OSRF's bottle-gap window and built Gazebo from
source. Apply it whenever --sim-tools runs.
The pin is a point-in-time SHA with nothing to advance it, so add a
weekly workflow that checks whether osrf/simulation HEAD is fully
bottled and opens a PR bumping gz-tap-pin.txt when it is.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: FARHANG <farhang.nba@gmail.com>
When homebrew-core bumps a shared dependency, OSRF's bot bumps each gz
formula's revision and deletes its bottle block within minutes of the upstream
merge. The matching rebuild is a separate, unautomated step: across 2026 the
gap ran 0.5 to 11 days, median 2.5, leaving gz unbottled roughly 18% of the
time. In that window macos.sh compiles gz-sim8, gz-msgs10 and five others from
source and the setup step goes from ~8min to 20-30min.
The removal only edits the formula. The bottle tarballs are never deleted from
OSRF's S3 bucket, so pinning to the last fully bottled revision keeps installs
binary while upstream catches up.
Gated behind a new --ci flag rather than applied unconditionally. Automation
wants a reproducible, fast install; development machines want the current
formulae and can absorb a source build, and should not have their tap left on
a detached HEAD as a side effect of running the setup script.
Only the gz tap is pinned. opencv@4, protobuf, gstreamer and the rest still
track homebrew-core, so CI keeps catching upstream formula breakage on every
PR, which is the reason --sim-tools runs there in the first place.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The Dockerfile only ever copied requirements.txt, so optional-requirements.txt
was never installed into the image even though it sits in the build context.
Every CI job needing pyelftools therefore fetched it from PyPI at job time and
failed whenever files.pythonhosted.org returned 502s.
symforce publishes no Linux aarch64 wheel and no sdist, so installing the file
unguarded would break the linux/arm64 image build. Gate it with an environment
marker so aarch64 installs pyelftools only.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
macos.sh --sim-tools installs the unversioned Homebrew opencv formula, which
is now 5.0.0, and PX4-OpticalFlow does not build against it:
klt_feature_tracker/src/trackFeatures.cpp:43:10:
fatal error: 'opencv2/core/types_c.h' file not found
PX4-OpticalFlow/src/flow_opencv.cpp:110:7:
fatal error: no member named 'undistortPoints' in namespace 'cv'
types_c.h was removed in OpenCV 5, and undistortPoints moved when calib3d was
split into 3d/calib. The failure lands about a thousand targets into
make px4_sitl and points at submodule sources rather than at the dependency.
ubuntu.sh takes libopencv-dev from apt, which is still 4.x, so CI never sees
this.
Install opencv@4 instead. It is keg-only, so find_package still resolves to
5.0.0 without a prefix hint. Add one alongside the qt@5 hint from 9c2e634325,
which is keg-only for the same reason.
Assisted-by: Claude:claude-opus-5[1m]
Signed-off-by: Jackson Korba <jackson.korba@gmail.com>
Homebrew 6.0+ refuses to load formulae from untrusted third-party taps. This adds a trusted block for OSRF taps.
Signed-off-by: Cade Andersen <cadecandersen@gmail.com>
Homebrew 6.0 (2026-06-11) makes tap-trust mandatory and refuses to load
formulae from untrusted third-party taps. This broke every macOS build:
brew install aborted with "Refusing to load formula px4/px4/fastdds from
untrusted tap px4/px4" before pouring any package, so ccache (and the
rest of the toolchain) was never installed and setup-ccache failed with
"ccache: command not found".
Trust the three required taps non-interactively before installing from
them. Guarded behind a brew trust capability check so older Homebrew,
which has no trust gate, skips it.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* src/drivers/cdcacm_autostart: Include posix.h for px4_close
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
* platforms/nuttx/CMakeLists.txt: Fix linking of nuttx libaries for memalign
This fixes memalign not found in linking step for some boards
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
* Add "flock" to macos.sh setup script
"flock" is not standard on macOS, and a dependency was missing from the
macOS setup path.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
* Fix clang-tidy errors in Bitset.hpp and in src/lib/matrix
Fix the "bugprone-dynamic-static-initializers" linter errors.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
* systemlib/hardfault_log: Fix clang-diagnostics error
Fix for
"[error] clang-diagnostic-error [error]
use of undeclared identifier XCPTCONTEXT_REGS".
XCPTCONTEXT_REGS is defined in nuttx irq.h, so include that.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
* uORB: Fix clang-tidy error "bugprone-dynamic-static-initializers"
Fix the clang-tidy error appearing on uORBManager _Instance variable by
adding a getter for the reference to the _Instance and using that instead.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
* CI: Add default ubuntu mirrors as fallback
In case of specified aws mirror doesn't have the package idicated by the
metadata, a the default ubuntu mirror as a backup.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
---------
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
* feat(secure_bootloader): add ed25519 key and signing helpers
Scaffolding for PX4 secure-boot firmware signing, split into two
self-contained scripts:
- generate_signing_keys.py: produces <name>.json (private+public hex)
for use by sign_firmware.py and <name>.pub (C-array public key)
for inclusion in the bootloader build via CONFIG_PUBLIC_KEYn.
Refuses to overwrite existing private-key files.
- sign_firmware.py: pads an input .bin to a 4-byte boundary and
appends a 64-byte ed25519 signature, producing a file that drops
directly into the flash slot described by the image TOC.
Optionally appends an R&D certificate binary after the signature.
Replaces the signing path of the old Tools/cryptotools.py that was
removed along with the log-encryption cleanup; the new layout keeps
bootloader-signing tooling separate from log encryption to avoid
confusing the two independent crypto surfaces.
* fix(bootloader): panic if px4_get_secure_random is ever called
sw_crypto's crypto_open() unconditionally references
px4_get_secure_random from its XCHACHA20 path, so even a bootloader
that only performs ed25519 signature verification (and never touches
stream ciphers) pulls in an undefined symbol at link time.
The app build resolves it through nuttx_random.c, which is gated
behind CONFIG_CRYPTO_RANDOM_POOL and only compiled in when the
NuttX random pool is enabled. That config isn't on in the tiny
bootloader NuttX defconfig, and enabling it would pull in a pile
of kernel code the bootloader doesn't need.
Supply the symbol locally, but make it call up_assert() instead of
returning zeros. Silently handing out predictable bytes would be a
serious security bug if anyone later enables the XCHACHA20 path in
the bootloader without wiring up a real RNG. Aborting makes the
mistake impossible to miss.
* fix(bootloader): add PROTO_VERIFY_SIG opcode for upload-time signature check
Today a signed-boot failure is invisible to the uploader: verify_app()
runs inside jump_to_app() after PROTO_BOOT has already rebooted the
chip, so the host sees a successful upload followed by the device
silently staying in the bootloader. There is no protocol-level signal
that the image that was just written is not going to run.
Add PROTO_VERIFY_SIG (0x39) so the host can ask the bootloader to run
find_toc() + verify_app(0) *before* the reboot and get a concrete
OK / FAILED / INVALID answer back over the still-open USB connection.
The new opcode is gated on BOOTLOADER_USE_SECURITY: bootloaders built
without secure boot return cmd_bad (INSYNC/INVALID) so an uploader
can tell "I don't know this command" apart from "verification failed".
Two subtleties required care:
1. PROG_MULTI deliberately defers the very first word of the app
image to a RAM variable (first_word) and only commits it to flash
inside PROTO_BOOT, so a partial upload can never become bootable.
But verify_app() reads directly from flash, so if we verified
before committing first_word, even a valid image would always
fail (the first four bytes at APP_LOAD_ADDRESS would still be
0xffffffff). The handler therefore mirrors the first half of the
PROTO_BOOT handler: gate on STATE_ALLOWS_REBOOT, program the
deferred first word, then run the crypto check.
2. On failure we deliberately do not try to "undo" the first-word
write — H7 flash programming granularity makes it impossible to
revert in place, and the device was going to end up in the same
reject state at the next boot either way. The improvement is
purely that the uploader sees the failure before REBOOT instead
of after.
Chose opcode 0x39 to stay clear of ArduPilot's 0x28 (READ_MULTI) and
0x40 (CHIP_FULL_ERASE), which PX4 does not currently use but which
an AP-compatible uploader might.
ArduPilot also has bootloader secure boot (monocypher ed25519, like
us) but their verification runs at boot time, not upload time — so
neither project currently solves the "upload silently wrote a bad
image" problem. This puts PX4 ahead on that.
* feat(Tools): add --image_signed to mark signed firmware for uploader
px_uploader.py only needs to run signature verification over USB for
images that actually carry a signature — asking the bootloader to
verify an unsigned image would always fail, and the extra round trip
is wasted time for the common unsigned case. It therefore needs a
reliable way to tell the two apart.
We cannot tell by inspecting the bytes: a sign_firmware.py output is
just the raw .bin with 64 bytes of ed25519 signature glued on the
end, indistinguishable in content from an unsigned image of the same
padded length. The natural place to put the flag is the .px4 JSON
envelope, which already carries board_id / version / summary / etc.
Add --image_signed to px_mkfw.py, which sets "image_signed": true
in the emitted JSON. The flag has no effect on what bytes actually
end up on the device — it just tells the uploader "this blob has a
signature, please verify it before booting".
* feat(Tools): verify firmware signature before reboot
After PROG_MULTI + GET_CRC, send a new VERIFY_SIG opcode (0x39) to
the bootloader to check the ed25519 signature over the freshly
flashed image *before* sending REBOOT. This way a signature failure
is reported as a clean error from the uploader script, instead of a
silent "device stays in bootloader after reboot" that leaves the user
guessing.
The uploader always probes VERIFY_SIG. The bootloader is the source
of truth for whether secure boot is enabled:
- INSYNC/OK -> verification passed, proceed to REBOOT
- INSYNC/FAILED -> raise; "Signature does not verify against any
trusted key" if the firmware claims to be signed,
"Secure bootloader rejected an unsigned image"
otherwise (= helpful guidance for the common
misconfiguration of uploading default firmware
to a secureboot bootloader)
- INSYNC/INVALID -> bootloader has no secure boot. Quietly proceed
unless the firmware metadata says image_signed,
in which case raise.
- recv timeout -> assume a pre-VERIFY_SIG bootloader, proceed.
Surfaces a "Verifying image signature... passed" line on the upload
status path when the firmware is marked signed, so users get a clear
positive signal that the secure-boot pipeline ran end-to-end.
Also drop the redundant logger.error in the upload() loop, which was
duplicating the error message printed by the top-level handler in
main() for every UploadError path (not specific to verify_signature,
but only became obvious once these clean error messages started
firing in normal usage).
* fix(cmake): fix .px4board variant resolution to require exact match
px4_config.cmake matched the requested CONFIG against each candidate
.px4board with `MATCHES`, which is a regex partial match. For a
config like `px4_fmu-v6x_bootloader_secureboot`, the iteration over
.px4board files (alphabetical glob order) would match
`bootloader.px4board` first — because "px4_fmu-v6x_bootloader" is a
prefix of "px4_fmu-v6x_bootloader_secureboot" — and stop, silently
selecting the wrong board config.
Use `STREQUAL` instead so each candidate has to match the full
requested CONFIG. Existing single-label cases (e.g. exact match on
`px4_fmu-v2_default` or `px4_fmu-v2`) are unaffected because they
were already exact in practice; this just plugs the prefix-match
hole that any future `<label>_<suffix>` variant would trip over.
* fix(nuttx): support bootloader_<variant> labels
Boards can ship bootloader variants beyond the default `bootloader`
label — e.g. a `bootloader_secureboot` that adds crypto + keystore
Kconfig on top of the same source tree. Two pieces of build glue
were hardcoded to the exact label `bootloader` and need to relax to
match any `bootloader_*` label:
1. platforms/nuttx/CMakeLists.txt picked the bootloader linker
script and bootloader-specific library list only when the label
was exactly `bootloader`. Any other label (including
`bootloader_secureboot`) silently fell through to the app build,
producing nonsensical link flags. Match `^bootloader` instead,
and explicitly set SCRIPT_PREFIX to `bootloader_` so all
bootloader variants share the single existing linker script
regardless of their full label.
2. platforms/nuttx/cmake/px4_impl_os.cmake selects the NuttX config
subdirectory by exact label match, falling back to `nsh` when no
matching directory exists. For `bootloader_secureboot` that fell
through to `nsh`, dragging in a full app-style NuttX with cromfs,
networking, and the full heap subsystem — a 128 KB bootloader
sector overflowed by ~50 KB. Add an intermediate fallback: if the
label starts with `bootloader` and a `bootloader/` subdir exists,
use that instead of `nsh`.
Both changes are backward-compatible: existing single-label
`bootloader` builds take exactly the same path as before. They only
gain the ability for boards to add `bootloader_<suffix>.px4board`
files without duplicating bootloader build wiring.
* feat(build): auto-sign secure-boot images via BOARD_SECUREBOOT
Add a Kconfig pair that boards can opt into:
CONFIG_BOARD_SECUREBOOT -- bool: sign the .px4 with ed25519
CONFIG_BOARD_SECUREBOOT_KEY -- string: path to JSON private key
(default: Tools/test_keys/test_keys.json)
When set, the .px4 build rule inserts a Tools/secure_bootloader/sign_firmware.py
step between the unsigned .bin and px_mkfw.py, and passes --image_signed
so the .px4 envelope's metadata flags it for the uploader's VERIFY_SIG
step. The unsigned .bin is still produced alongside the .px4, so users
can sign with their own key out-of-tree if they prefer.
A BOARD_SECUREBOOT_KEY environment variable overrides the Kconfig path
at build time, mirroring the override pattern used for CONFIG_PUBLIC_KEYn
in stub_keystore. This makes release builds practical:
BOARD_SECUREBOOT_KEY=/secure/path/release.json make px4_<board>_secureboot
Relative paths in the Kconfig are resolved against the repo root (not
the build directory) so the same value works regardless of where the
build runs from.
Default builds are byte-identical to before; the new code path is gated
on CONFIG_BOARD_SECUREBOOT being set.
* feat(boards): add secureboot demo variant + docs
Two coordinated build variants demonstrate end-to-end secure boot
on px4_fmu-v6x without touching the default builds:
px4_fmu-v6x_secureboot -- the app, with TOC + signing
px4_fmu-v6x_bootloader_secureboot -- the matching secure bootloader
App side (secureboot.px4board):
- Selects nuttx-config/scripts/secureboot-script.ld via
CONFIG_BOARD_LINKER_PREFIX. The script is a copy of the default
layout plus a fixed 0x800 reservation past the vector table for
the image TOC, and an empty .signature section at end-of-FLASH
so sign_firmware.py knows where the appended ed25519 signature
will land.
- Compiles src/toc.c (a four-entry IMAGE_MAIN_TOC matching the
layout used elsewhere in the tree) into drivers_board, gated on
PX4_BOARD_LABEL == secureboot so the default build still
produces the existing layout.
- Sets CONFIG_BOARD_SECUREBOOT=y so the .px4 build rule signs the
image with the upstream test key by default.
Bootloader side (bootloader_secureboot.px4board):
- Enables CONFIG_BOARD_CRYPTO + DRIVERS_SW_CRYPTO + DRIVERS_STUB_KEYSTORE,
which links monocypher and the stub keystore into the bootloader.
- Bakes Tools/test_keys/key0.pub in as CONFIG_PUBLIC_KEY0, paired
with the test_keys.json the app variant signs with.
- hw_config.h gates BOOTLOADER_USE_SECURITY, BOOTLOADER_SIGNING_ALGORITHM
(CRYPTO_ED25519), and BOARD_IMAGE_TOC_OFFSET (0x800) on PX4_CRYPTO,
so they only activate in this variant.
Together the two variants implement the workflow:
make px4_fmu-v6x_bootloader_secureboot # build + flash via SWD once
make px4_fmu-v6x_secureboot upload # signs with test key, verifies
Bootloader fits in 128 KB (~57 KB used) thanks to --gc-sections
stripping the unused libtomcrypt code; nothing in the bootloader
binary depends on monocypher beyond the ed25519 verifier.
Replace the bundled test key for production with
Tools/secure_bootloader/generate_signing_keys.py output and update
both .px4board files (or set BOARD_SECUREBOOT_KEY at build time) —
see docs/en/advanced_config/bootloader_secure_boot.md.
* fix(boards): cap H7 bootloader linker scripts at 128 KB
Roughly half of the H7 boards in tree had `LENGTH = 2048K` for the
bootloader sector in their bootloader_script.ld, even though the
matching app linker script places APP_LOAD_ADDRESS at 0x08020000 —
i.e. the bootloader actually only owns the first 128 KB sector.
The 2048K constraint is wrong: it lets a bootloader that grew past
the 128 KB sector silently overflow into the app sector at link
time and corrupt the start of the app on flash. The linker should
fail the build instead.
The current default bootloader is ~46 KB, well under 128 KB on every
affected board, so this change is a no-op for default builds. It
just plugs a footgun for anyone adding bootloader features (secure
boot, extra UI, network boot, ...) that would have otherwise
silently grown into the app's flash range.
Boards fixed:
3dr-style H7 reference boards: cubepilot/cubeorange,
cubepilot/cubeorangeplus, holybro/durandal-v1, narinfc/h7
vendor variants: corvon/743v1, cuav/nora, cuav/x7pro,
gearup/airbrainh743, hkust/nxt-dual, hkust/nxt-v1,
matek/h743, matek/h743-mini, matek/h743-slim,
micoair/h743, micoair/h743-aio, micoair/h743-lite,
micoair/h743-v2, x-mav/ap-h743r1, x-mav/ap-h743v2
Boards already correct (LENGTH = 128K) are unchanged.
* fix(ci): add pynacl to Python requirements
Tools/secure_bootloader/sign_firmware.py uses PyNaCl for ed25519
signing, and the .px4 build rule for boards with CONFIG_BOARD_SECUREBOOT
calls it as part of the normal build (e.g. px4_fmu-v6x_secureboot).
Without pynacl in the dev requirements, those builds fail in CI and
fresh dev setups.
* docs(update): Subedit
* docs(update): Fix example error I made
* fix(docs): document BOOT and SIG1 regions
* fix(platforms): style fix
* fix(ci): workaround to get pip dependency
* fix(ci): fall back to plain pip on older build containers
The voxl2 build image ships a pip that predates --break-system-packages
(added in pip 23.0.1), so the install step blew up with "no such option".
Modern containers enforce PEP 668 and need the flag; older ones don't
support it but also don't enforce PEP 668, so plain pip works there.
Try the modern flag first, fall back if pip rejects it.
Signed-off-by: Julian Oes <julian@oes.ch>
* fix(build): strip BUILD_DIR_SUFFIX from CONFIG in cmake-build
cmake-build was passing the full build-dir name (including any
BUILD_DIR_SUFFIX like _replay or _failsafe_web) as -DCONFIG=, which
the board-lookup in cmake/px4_config.cmake then tried to match
against <vendor>_<model>_<label> .px4board files. That used to work
by accident because px4_config.cmake matched with regex MATCHES, but
since the switch to STREQUAL (needed to disambiguate
bootloader_secureboot from bootloader) the suffixed CONFIG no longer
matches anything and LABEL ends up empty, tripping a CMake error in
kconfig.cmake.
Pass the bare CONFIG and keep the suffix only on the build dir so
both concerns are independent.
Signed-off-by: Julian Oes <julian@oes.ch>
---------
Signed-off-by: Julian Oes <julian@oes.ch>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
The px4-sim / px4-sim-gazebo Homebrew meta-formulae can no longer
pull their Gazebo dependency chain because Homebrew 4.5+ stopped
auto-resolving cross-tap deps. PX4/homebrew-px4#104 already
deprecated px4-dev into a no-op; #111 does the same for the sim
formulae. This PR is the PX4-side counterpart: move the sim install
into Tools/setup/macos.sh with an explicit package list and tap
registration, mirroring the pattern already used for the toolchain
block. Adds xquartz install on --sim-tools.
Beyond install, three runtime and configure gaps kept make px4_sitl
gz_x500 from working on a clean macOS:
- gz-gui8 (pulled in by gz-sim8) links against Qt5, but Homebrew's
qt@5 is keg-only so CMake cannot find it. Add a POSIX-scoped hint
in platforms/posix/cmake/px4_impl_os.cmake that resolves
brew --prefix qt@5 and appends it to CMAKE_PREFIX_PATH. No-ops on
non-APPLE builds and respects a user-set Qt5_DIR.
- On macOS, dyld does not search /opt/homebrew/lib by default.
gobject-introspection typelibs reference libs by bare basename,
causing gst-plugin-scanner to fail to load plugins and adding
~90s of timeout to Gazebo's cold start. Set
DYLD_FALLBACK_LIBRARY_PATH to the Homebrew prefix lib dir in
gz_env.sh so the bridge launch inherits it. Darwin-scoped, no
effect on Linux or CI.
- configure_file on gz_env.sh.in now uses @ONLY so shell ${VAR}
references pass through untouched.
Verified locally on macOS 26.4 / arm64 / Homebrew 5.1.7: configure
clean, 1119/1119 targets compile and link, vehicle spawns in
Gazebo Harmonic 8.11.0 with a single "Waiting for Gazebo world"
wait (was ~18 before the dyld fix).
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Homebrew 4.5 (April 2026) stopped auto-tapping cross-tap
dependencies declared in formulae, as a security + performance
change. The px4-dev meta-formula pulled in packages from
osx-cross/arm, PX4/px4, and discoteq/discoteq, so 'brew install
px4-dev' now aborts before any real work unless every tap has been
added explicitly. On macos-latest CI runners the chain broke at the
first unreachable dep (discoteq/discoteq/flock) and subsequent make
steps failed with 'ccache: command not found'.
Since Tools/setup/macos.sh is the canonical install path and already
tapped osx-cross/arm and PX4/px4 before calling brew install, the
simplest fix is to inline the package list and call brew install
directly. The px4-dev meta-formula will be kept upstream as a
deprecated no-op so older copies of macos.sh on long-lived branches
and cached Docker images keep working.
The inlined package list is the same set px4-dev depended on, minus
the dead-weight flock dependency that hadn't been invoked in the PX4
build since the NuttX 9.1.x era. See the accompanying PX4/homebrew-px4
PR for formula changes.
Docs updated to match: docs/en/dev_setup/dev_env_mac.md no longer
names the px4-dev formula, describes the package list directly.
Verified locally on macOS ARM64:
- ./Tools/setup/macos.sh runs to completion with both taps and all 13
packages resolving correctly
- make distclean && make px4_fmu-v6x_default builds successfully
(1250/1250 ninja steps, 1930096 B FLASH used)
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Several helper scripts assumes bash is available at /bin/bash. That breaks on systems
such as NixOS, where bash is resolved from PATH instead of a fixed /bin location and
causes failures like `bad interpreter` during `make format`, e.g., on my host machine:
```sh
$ make format
/PX4-Autopilot/Tools/astyle/check_code_style.sh: /PX4-Autopilot/Tools/astyle/fix_code_style.sh: /bin/bash: bad interpreter: No such file or directory
```
This change switches these entrypoints to `#!/usr/bin/env bash` so they locate bash properly.
No functional changes intended.
Signed-off-by: Onur Özkan <work@onurozkan.dev>
* Initial changes
* index fix
* gz index fix2
* gz index fix 3
* updates
* Run prettier
* zsh env
removed gz classic
* Corrections 2
* Cleanups
* Update docs/en/dev_setup/dev_env_mac.md
* Apply suggestions from code review
* Minor subedit and prettier
* small correction
* cleanups gz harmonic brew formula
* fix(macos.sh): invert px4-sim install condition for --sim-tools
The condition checked if px4-sim WAS installed before running
brew install, meaning it would never install on a fresh system.
Add the missing negation so it installs when NOT already present.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* docs: rewrite macOS dev environment setup guide
- Add Xcode Command Line Tools as prerequisite
- Default to ~/.zshrc (macOS default since Catalina)
- Explain why ulimit change is needed and why in startup file
- Add reminder to open new terminal after shell config changes
- Remove broken pip3 alias workaround
- Split git clone into clone + submodule update (canonical form)
- Recommend --sim-tools flag since first build uses gz_x500
- Document what macos.sh installs and its --reinstall flag
- Clarify Gazebo comes from --sim-tools / px4-sim formula
- Add XQuartz requirement for Gazebo display
- Add verification section with key tool checks and smoke test
- Remove outdated video guide comment block
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* conventions
---------
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Co-authored-by: Ramon Roche <mrpollo@gmail.com>
Replace the two separate echo lines ("Starting" and "(arch)") with a
single line showing architecture and UTC timestamp:
[docker-entrypoint.sh] aarch64 | 2026-02-09T15:23:45Z
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Remove Gazebo Classic installation branches for Ubuntu 18.04 and 20.04.
The script now only supports Ubuntu 22.04 and 24.04 with Gazebo Harmonic.
Supported Ubuntu LTS versions going forward:
- Ubuntu 24.04 (primary, used in CI and release builds)
- Ubuntu 22.04 (secondary, still supported)
When Ubuntu 26.04 LTS releases we will bump to 26.04/24.04.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Build all targets / Scan for Board Targets (push) Has been cancelled
Build all targets / Build Group [${{ matrix.group }}][${{ matrix.arch == 'nuttx' && 'x86' || 'arm64' }}] (push) Has been cancelled
Build all targets / Upload Artifacts to S3 (push) Has been cancelled
Build all targets / Create Release and Upload Artifacts (push) Has been cancelled
Checks / build (NO_NINJA_BUILD=1 px4_fmu-v5_default) (push) Has been cancelled
Checks / build (NO_NINJA_BUILD=1 px4_sitl_default) (push) Has been cancelled
Checks / build (check_format) (push) Has been cancelled
Checks / build (check_newlines) (push) Has been cancelled
Checks / build (module_documentation) (push) Has been cancelled
Checks / build (px4_fmu-v2_default stack_check) (push) Has been cancelled
Checks / build (px4_sitl_allyes) (push) Has been cancelled
Checks / build (shellcheck_all) (push) Has been cancelled
Checks / build (tests) (push) Has been cancelled
Checks / build (tests_coverage) (push) Has been cancelled
Checks / build (validate_module_configs) (push) Has been cancelled
Clang Tidy / build (push) Has been cancelled
MacOS build / build (px4_fmu-v5_default) (push) Has been cancelled
MacOS build / build (px4_sitl) (push) Has been cancelled
Ubuntu environment build / Build and Test (ubuntu:22.04) (push) Has been cancelled
Ubuntu environment build / Build and Test (ubuntu:24.04) (push) Has been cancelled
Container build / Set Tags and Variables (push) Has been cancelled
Container build / Build Container (amd64) (push) Has been cancelled
Container build / Build Container (arm64) (push) Has been cancelled
Container build / Deploy To Registry (push) Has been cancelled
EKF Update Change Indicator / unit_tests (push) Has been cancelled
Failsafe Simulator Build / build (failsafe_web) (push) Has been cancelled
FLASH usage analysis / Analyzing px4_fmu-v5x (push) Has been cancelled
FLASH usage analysis / Analyzing px4_fmu-v6x (push) Has been cancelled
FLASH usage analysis / Publish Results (push) Has been cancelled
ITCM check / Checking nxp_tropic-community (push) Has been cancelled
ITCM check / Checking px4_fmu-v5x (push) Has been cancelled
ITCM check / Checking px4_fmu-v6xrt (push) Has been cancelled
MAVROS Mission Tests / build (map[mission:MC_mission_box vehicle:iris]) (push) Has been cancelled
MAVROS Offboard Tests / build (map[test_file:mavros_posix_tests_offboard_posctl.test vehicle:iris]) (push) Has been cancelled
Nuttx Target with extra env config / build (px4_fmu-v5_default) (push) Has been cancelled
Python CI Checks / build (push) Has been cancelled
ROS Integration Tests / build (push) Has been cancelled
ROS Translation Node Tests / Build and test (map[ros_version:humble ubuntu:jammy]) (push) Has been cancelled
ROS Translation Node Tests / Build and test (map[ros_version:jazzy ubuntu:noble]) (push) Has been cancelled
SITL Tests / Testing PX4 tailsitter (push) Has been cancelled
SITL Tests / Testing PX4 iris (push) Has been cancelled
SITL Tests / Testing PX4 standard_vtol (push) Has been cancelled
Handle stale issues and PRs / stale (push) Has been cancelled
Fuzzing / Fuzzing (push) Has been cancelled
nsh console running on USB
param module running
working with i2c and common drivers
provided implementation for drv_pwm_output.h
i2cdetect working as expected with no device
mavlink started succesfully
mounts sd card and logger runs
logger to file succesfully
pwm_servo implemented without using Nuttx lib
pwm_out outputs expected waveforms
- however currently if the frequency is higher than what the pwm_out
driver runs, there will be aliasing, based on how the registers gets
resets
wifi softap working
- Seeing wifi hotspot
- cant connect due to wrong password
- problems with adjusting ssid and password
wifi ssid and password being set accordinglu
connected to wifi hotspot with dhpcd
- made some changes to nuttx to only build for SoftAP mode, however this
was effectivelyy removing the ifdef for STATION mode. Should investigate
the coexist option again
added ifdef to not use timer 0 when wifi enabled
- reverted esp32 rt_timer to make use of timer 0 by default
fix setting incorrect bit in hrt timer register
- hrt running as expected, but on startup the pwm_out driver starts up
at about 200Hz and then rises over a minute or so 250Hz. Not sure if
this was present previously, and could be due to Wifi running at time
priority on timer 0
pull xtensa compilers in setup.ubuntu.sh
revert logger stacksize and cmake argument
esp32 chip revision and PX4 UUID implemented
spi board reset implemented, formatting checked
devkit acts on startup as a wifi bridge for comms
- the most usefull setting for the general developer when buying a esp32 devkit
- testing Mavlink shell using ./Tools/mavlink_shell.py
- todo: Test mavlink messages being forward
improve wifi telemetry by increasing prio
- Remove power save mode on wifi
- increased daemon thread schedule priority to 50
compiles without Nuttx changes
- updated compiler settings to match those of nuttx on px4 side
add espressif_esp32 to excluded boards
ci: allow docker to find xtensa compilers
MAVROS Mission Tests / build (map[mission:MC_mission_box vehicle:iris]) (push) Waiting to run
MAVROS Mission Tests / build (map[mission:rover_mission_1 vehicle:rover]) (push) Waiting to run
MAVROS Offboard Tests / build (map[test_file:mavros_posix_tests_offboard_posctl.test vehicle:iris]) (push) Waiting to run
Nuttx Target with extra env config / build (px4_fmu-v5_default) (push) Waiting to run
Python CI Checks / build (push) Waiting to run
ROS Translation Node Tests / Build and test (map[ros_version:humble ubuntu:jammy]) (push) Waiting to run
ROS Translation Node Tests / Build and test (map[ros_version:jazzy ubuntu:noble]) (push) Waiting to run
SITL Tests / Testing PX4 tailsitter (push) Waiting to run
SITL Tests / Testing PX4 iris (push) Waiting to run
SITL Tests / Testing PX4 standard_vtol (push) Waiting to run
* Added the board configs for encryption, I had to disable smbus and px4 io in the arkv6x
* Added the key generator script
* Added the decryptor, logs are needed for it though
* Added the log download and modified the decryptor
* Quick fixes & README
* Additional modifications & cleanup
* Tested upd connection
Adjusted the log downloader to handle multiple entry responses from the FC
Edited README
* Reverted IP address change
* Added pycryptodome to the requirements.txt
* fixes for log download and decryption
* Removed old log decryptors and updated README
* Pointed the ark borads to the dummy key updated the README accordingly
* Adjusted the folders in README, removed new lines
* Extended command line arguments for all possibilities for description
* Added MAV_CMD_REQUEST_AUTOPILOT_CAPABILITIES after heartbeat received to make sure log request is answered in all cases
* Update Tools/log_encryption/README.md
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
* Update Tools/log_encryption/README.md
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
* Update Tools/log_encryption/README.md
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
* Update Tools/log_encryption/README.md
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
* Edited README, changed the serial connection logic and updated logdownload, made decryption a bit easier to understand
* Update Tools/log_encryption/README.md
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* Removed new lines
* arkv6x: add individual mags to default.px4board
---------
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Co-authored-by: Alex Klimaj <alex@arkelectron.com>
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Ramon Roche
Jacob Dahl
Julian Oes
PX4BuildBot
FARHANG
Matthias Grob
Jackson Korba
Cade Andersen
Jukka Laitinen
Kristiyan DimitrovandRamon Roche
Anil Kircaliali
Onur Özkan
Marin D
Holden Ramsey
henrykotze
Peter van der Perk
Alexander Lerach
Daniel Agar
Pernilla