- Add NVM ECC mode, which introduces a new erase check HAL API to use
flash controller HW to blank check sectors instead of reading them
and comparing to an erased byte (which typically triggers an ECC
fault)
- Add NVM Journal mode as an alternative to NVM_FLASH_WRITE_ONCE that
does not require a sector-size RAM buffer and dramatically reduces
the number of erases and programs required to set individual flags,
while also being much more robust to power-cuts.
c3f9717f guarded the success/trigger/sector-flag declarations behind
WOLFBOOT_FIXED_PARTITIONS, but wolfboot.h includes target.h only under
__WOLFBOOT, so test-apps (compiled without __WOLFBOOT) never saw the
macro and failed with implicit-declaration errors on imx95_m7, mcxa,
mcxw and mcxw-tz. Unguard the header declarations; keep the definitions
guarded and move wolfBoot_success out of the fixed-partition guard
since it only uses the partition-state API.
- libwolfboot.c: keep the partition state APIs (set/get_partition_state)
available to CUSTOM_PARTITION_TRAILER / WOLFBOOT_NO_PARTITIONS builds;
guard the fixed-partition APIs (sector flags, erase, trigger, success)
behind WOLFBOOT_FIXED_PARTITIONS. Add the unit-custom-trailer-nopart
compile target to lock in that configuration.
- unit-p1021-fcm-bytes.c: add program tests for status 0x81 (fail) and
0x00 (write-protected), asserting no later page is programmed.
- unit-p1021-erase-advance.c: add an erase test for status 0x00
(write-protected), asserting failure before advancing to the next block.
Add HAVE_PARTITION_TRAILERS macro (set when WOLFBOOT_FIXED_PARTITIONS or
CUSTOM_PARTITION_TRAILER is defined) and use it to gate the TESTING state
transition in update_ram.c. Previously the gate was WOLFBOOT_FIXED_PARTITIONS
only, so targets using custom partition trailers never transitioned from
UPDATING to TESTING, allowing rollback to older versions.
Add unit-update-ram-custom-trailer test covering the CUSTOM_PARTITION_TRAILER
path with mocked get/set_trailer_at callbacks.
Every wolfPKCS11 field write flushed the payload sector and the header
sector to flash (2 erases + 2 programs of a full sector each), and the
token store re-serializes all objects per C_CreateObject/C_DestroyObject,
so those calls cost hundreds of sector erases and tens of seconds on
flash with slow erase times.
Cache modified sectors in RAM and commit them together when the store
window closes:
- sector cache sized to the worst-case span of one object plus the
header sector (WOLFBOOT_PKCS11_STORE_CACHE_SECTORS), LRU eviction
when exceeded
- header sector commits last, so a committed header is the atomic
commit point of the batch: power failure during a flush leaves the
flash in either the pre-batch or the post-batch state
- per-commit backup sector write preserved, keeping recovery of the
sector in flight at failure time
- delete_object commits on return (durability contract, unit-tested)
- nodes table, bitmap, payload ids and the live object size
(handle->size) are read from the cache when the sector is dirty
Measured on an STM32H5 with 8KB sectors, wolfPKCS11 in the secure
world: C_CreateObject 1.5s -> 0.15s, C_DestroyObject 1.3s -> 0.12s,
456 -> 40 sector erases per create, and the count no longer scales
with the number of objects in the token.
PKCS11_STORE_STATS (off by default) adds flash-activity counters and a
test-app bench to quantify store traffic: make PKCS11_STORE_STATS=1.
The comment labeled IMG_STATE_TESTING as an 'ELF loading state', but
the constant is wolfBoot's general dual-bank confirm/rollback marker:
it is set on the BOOT partition after every swap (update_flash.c,
update_flash_hwswap.c, update_ram.c - none ELF-specific) and cleared
by wolfBoot_success(); if still present at the next boot it triggers
a rollback. A maintainer trusting the old comment could have treated
the state as inert on non-ELF targets and disabled the anti-brick
path.
Reword to the accurate description already used in
docs/flash_partitions.md, keeping the note that it only lives on the
boot partition so it cannot conflict with IMAGE_STATE_UPDATING.
Comment-only change; no code or behavior changes.
- Check diag_erase() return value in wolfBoot_record_failure()
- Dedicated WOLFBOOT_FAILURE_PHASE_SELF_UPDATE
- Mark the diagnostics flash write buffers XALIGNED_STACK(4) for HALs
that access the source word by word
- Ensure diagnostics, update, or swap partitions don't overlap the
bootloader
When boot/update partition verification fails during boot or update,
with this option the event is logged to flash in an ad-hoc partition.
Information about logged failures is made available to the application
through an API.
* Initial port refresh for the NXP T2080 target
* IFC Flash driver and multi-core support on T2080
* Working wolfBoot test-app startup on T2080
* Support for NAII and Curtiss-Wright T2080 vendor boards
- Integrates wolfPSA as psa_crypto/psa_store engine in TrustZone
- Provides interface to access APIs from non-secure mode
- Patches to enable wolfboot as TEE module in zephyr
- Patches to enable stm32h563-nucleo/ns as target in zephyr
- psa_crypto zephyr example using wolfboot/wolfPSA as secure engine
Cleanup STM32H5 HAL port.
Refactor `__ARM_FEATURE_CMSE` to `TZ_SECURE()`
Refactor attribute cmse_nonsecure_entry to use new macro `CSME_NSE_API`
Added TPM Non Secure Callable API's
Added TPM support to STM32H5 test application
- Make the update and swap partitions secure and inaccessible from the
app except via NSC API
- Add a couple of necessary new NSC functions
- Update the app to only use NSC API
- Fix hal_flash_erase to account for secure addresses
- Fix some bugs in xmodem implementation
During fallback operations, use a different encryption IV than the one
used to encrypt the backup during the update. This ensures that the same
IV is never reused to encrypt different sectors.
Brett Nicholas
Daniele Lacamera
Aidan Garske
David Garske
Mattia Moffa
aidan garske
Yosuke Shimizu
Thomas Cook
gojimmypi