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.
Run wolfBoot on the PIC32CZ CA9x host core (Cortex-M7) as a wolfHSM client,
offloading the image digest (SHA-256) and the ECDSA P-256 signature check to
the wolfHSM server.
* file level rename for ML-DSA
* Add missing source file to build system
* Update some macros
* Other minor fixes
* Update size limitations for some slight increases
- HAL: Remove debug spifi_test_mode_switch(), use wolfBoot_printf
instead of raw uart_write, add printf.h include
- Test app: Use check_parts() (was defined but unused), replace
custom print_str/print_hex32 with wolfBoot_printf, fix LED logic
to show LED1 for v1 and LED2 for v2+ (was always LED1)
- Docs: Remove incorrect MCUXpresso SDK section (port is bare-metal),
fix typo, add swap timing note, add flash script references
- Build: Add --no-warn-rwx-segments to arch.mk, improve Makefile
comments
- Add tools/scripts/nxp-lpc54s018m-flash.sh following the
nxp-s32k142-flash.sh pattern (build, sign, flash via pyocd)
Tested: full boot + firmware update cycle (v1 -> v2 swap) verified
on LPC54S018M-EVK hardware.
The LPC54S018M HAL had three critical SPIFI controller issues preventing
flash write/erase operations from working, which blocked wolfBoot_success(),
wolfBoot_update_trigger(), and the firmware swap:
1. Wrong memory-mode read command: Used opcode 0x6B (Quad Output, serial
address) but the boot ROM configures 0xEB (Quad I/O, quad address) with
MCMD=0xEB930000. The mismatch caused garbled address bits when re-entering
XIP after flash operations, crashing on instruction fetch.
2. SPIFI POLL mode not waiting: The boot ROM leaves CLIMIT[7:0]=0x00 which
makes the hardware POLL comparison always succeed immediately. Set
IDATA=0x00 and CLIMIT[7:0]=0x01 to properly wait for flash BUSY to clear.
3. SPIFI reset clears CTRL/CLIMIT: The reset used to exit memory mode clears
the boot ROM's timing config (CTRL=0x600F03E8) and cache limit
(CLIMIT=0x08000000). Save and restore both registers around every reset.
Additional changes:
- Add RAMFUNCTION memcpy (src/string.o) to test app for SPIFI XIP safety
- Add bare-metal UART driver for Flexcomm0 (non-blocking, skips if FC0
doesn't respond — observed on some LPC54S018M-EVK boards)
- Add DSB+ISB barriers after entering memory mode for pipeline coherency
- Enable DEBUG_UART in example config
- Update test app to follow LPC55S69 port patterns with LED indicators
for boot version and update status
Tested: cold boot, ECC256 signature verify, wolfBoot_success(),
wolfBoot_update_trigger(), and full v1->v2 firmware swap all working.
Swap takes ~60 seconds for the 960KB partition (240 sector operations).