* boards: enable CONFIG_FS_LARGEFILE for NuttX boards with MMC/SD
Without large file support, fsblkcnt_t/off_t are 32-bit and statfs
consumers (procfs /fs/usage, df) compute the volume size as
f_bsize * f_blocks in 32 bits, which wraps at 4GB. Boards with an
SD card or eMMC larger than 4GB report the wrong capacity, e.g. a
32GB SD card on FMU-V6X:
nsh> ls -l /dev/mmcsd0
brw-rw-rw-1850212352 /dev/mmcsd0 (= 31914983424 mod 2^32)
nsh> df -h
vfat 1749M 240K 1749M /fs/microsd
With CONFIG_FS_LARGEFILE=y the same card reports the full 29G.
This enables the option on the 77 boards that build the MMC/SD block
driver (CONFIG_MMCSD=y, SDIO or SPI). Boards without removable storage
and constrained-flash targets (CONFIG_BOARD_CONSTRAINED_FLASH=y) are
left unchanged.
Note: on the px4_firmware_nuttx-10.3.0+ branch the 64-bit file types
are additionally gated on CONFIG_HAVE_LONG_LONG, which is only defined
via nuttx/compiler.h include order, making the option unreliable. That
gating is fixed by the companion NuttX backport PR
(PX4/NuttX, branch backport-fs-largefile, upstream commit 92b2f1bd3d3).
Tested on a custom STM32H743 board with 8GB eMMC and on FMU-V6X with a
32GB SD card.
* fix(boards): enable CONFIG_FS_LARGEFILE for MMC/SD variant configs
The test/console/stackcheck/socketcan/sysview/cyphal/debug/cryptotest
variant configs of boards covered by the previous commit were missed,
leaving them with 32-bit off_t. fmu-v5 protected is intentionally
excluded: protected-mode syscall proxies keep 32-bit widths.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* chore(nuttx): bump submodule for FS_LARGEFILE backport
Picks up the backport of upstream NuttX 92b2f1bd3d3, which gates the
64-bit file types on CONFIG_FS_LARGEFILE alone instead of the
include-order-dependent CONFIG_HAVE_LONG_LONG.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The per-channel send mutex is genuinely recursive: callers hold lock_send()
while the MAVLink C library re-enters send_start()/send_finish() on the same
mutex via MAVLINK_START_UART_SEND. On NuttX a recursive mutex only works with
CONFIG_PTHREAD_MUTEX_TYPES; without it pthread_mutexattr_settype() is a no-op
and the nested lock deadlocks. Only a handful of boards happened to enable the
option (for Zenoh), so mavlink could deadlock at startup on most boards, e.g.
when bringing up a USB link.
Enable CONFIG_PTHREAD_MUTEX_TYPES on the NuttX boards that build mavlink, add
a compile-time guard so a board missing the option fails the build loudly
instead of deadlocking silently, and check the settype() return. Enabling the
option is free in flash and RAM on these boards since they already enable
CONFIG_PRIORITY_INHERITANCE / CONFIG_PTHREAD_MUTEX_ROBUST.
Signed-off-by: Julian Oes <julian@oes.ch>
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
- split up old module into two, one handling setpoint generation, one control
- add lateral and longitudinal control setpoints topics that can also be
injected from companion computer
- add configuration topics that (optionally) configure the controller
with limits and momentary settings
Signed-off-by: RomanBapst <bapstroman@gmail.com>
192.168.0.x is often used by routers for WIFI/ethernet networks, and thus
can create conflicts.
This can happen for example if a companion is connected to the FMU via
ethernet and at the same time connects to a WIFI network as DHCP client.
- during casual testing on default configs the stack was penetration was reaching ~90% which is a bit too close for comfort
- increasing by 50% to be conservative
* Fixedwing rate control into a separate module
* Start fw_rate_control for vtol
* Move over airspeed related parameters to fw_rate_control
Co-authored-by: Silvan Fuhrer <silvan@auterion.com>
- new modules/simulation directory to collect all simulators and related modules
- new Tools/simulation directory to collect and organize scattered simulation submodules, scripts, etc
- simulation module renamed to simulator_mavlink
- sih renamed to simulator_sih (not a great name, but I wanted to be clear it was a simulator)
- ignition_simulator renamed to simulator_ignition_bridge
- large sitl_target.cmake split by simulation option and in some cases pushed to appropriate modules
- sitl targets broken down to what's actually available (eg jmavsim only has 1 model and 1 world)
- new Gazebo consistently referred to as Ignition for now (probably the least confusing thing until we fully drop Gazebo classic support someday)
- cmake NuttX build wrapper compile in place instead of copying source tree to build directory
- slightly faster skipping necessary copying (depending on system)
- allows debugging in place
- easier to work directly in NuttX following official documentation
- simplifies overall build which should make it easier to resolve any remaining NuttX dependency issues in the build system
- the downside is switching back and forth between different builds always require rebuilding NuttX, but I think this is worth the improved developer experience
- also no longer builds px4io and bootloader in every single build, for most users these rarely change and we're wasting a lot of build time
