The previous commit moved WOLFBOOT_ORIGIN from 0x8000000 to 0x10000000
to match the linker script, but WOLFBOOT_LOAD_ADDRESS is also 0x10000000.
This causes wolfBoot to overwrite itself when loading the firmware image
(32MB FIT written to 0x10000000 overwrites wolfBoot's .text at the same
address mid-read, hanging the boot).
Revert to 0x8000000 (128MB, same as U-Boot) and update linker script to
match. WOLFBOOT_LOAD_ADDRESS at 0x10000000 is safely above wolfBoot's
2MB footprint at 0x8000000-0x8200000.
hal/zynq.c:
- Route IOU_TAPDLY_BYPASS writes through pmu_request at EL<=2 in the
<=40 MHz and <=100 MHz branches (previously only done at <=150 MHz);
the register is equally unwritable from EL2/EL1 at lower clocks.
- Add qspi_flash_reset() (RESET_ENABLE 0x66 + RESET_MEMORY 0x99),
called per chip in qspi_init so the flash starts from a known state
regardless of what FSBL/BootROM left behind (XIP, 4-byte addr,
auto-boot).
- Drop unused 'reg' in csu_aes and 'ms' in csu_init so
-Werror=unused-variable builds (OPTIMIZATION_LEVEL=0 / DEBUG=1) pass.
hal/zynq.ld:
- Move wolfBoot ORIGIN from 0x08000000 to 0x10000000. Large FIT images
(kernel load=0x00200000, payload >~126 MB) would sweep across
0x08000000 at handoff and overwrite wolfBoot's own code.
tools/scripts/zcu102/zcu102-ca53-qspi.cmm:
- Rewrite against the Lauterbach TRACE32 ZCU102 QSPI demo: PREPAREONLY
entry mode, single/dual toggle, READ_ID_TEST, separate flash dialogs
for BOOT.BIN (offset 0) and test-app/image_v1_signed.bin.
- Document the ~128 MB TRACE32 temp-memory ceiling on FLASHFILE.Create:
larger files must be split externally and loaded in chunks.
Add the pieces needed to boot Linux end-to-end from the ZCU102 SD card
with wolfBoot at EL2:
* src/boot_aarch64_start.S: new el2_flush_and_disable_mmu helper that
cleans D-cache to PoC, invalidates I-cache to PoU, and clears
SCTLR_EL2.{M,C,I}, then returns. Satisfies the ARM64 Linux boot
protocol and is also correct for any other payload that sets up its
own translation (hypervisor, RTOS, later bootloader stage).
* src/boot_aarch64.c: call el2_flush_and_disable_mmu from do_boot() on
the EL2 direct-jump path before falling through to the br x4 block.
Also pull in hal/zynq.h and hal/nxp_ls1028a.h so the EL_HYPERVISOR /
BOOT_EL1 guards compile for those targets.
* hal/zynq.c: implement hal_dts_fixup() — set /chosen/bootargs from
LINUX_BOOTARGS (with a LINUX_BOOTARGS_ROOT default of /dev/mmcblk0p4)
and grow DTB totalsize by 512 bytes to give fdt_setprop() headroom
(matches hal/versal.c). Add hal_get_timer_us() via CNTPCT_EL0.
* src/sdhci.c: add a 1 ms settling delay after sdhci_platform_init()
and a CMD0 retry loop (up to 10 x 10 ms) so the ZCU102 Arasan
controller reliably detects the card after the slot-type change +
soft reset.
* config/examples/zynqmp_sdcard.config: stay at EL2 by default (comment
out BOOT_EL1), default rootfs to /dev/mmcblk0p4, turn DEBUG off.
* hal/versal.c: correct the default LINUX_BOOTARGS_ROOT to
/dev/mmcblk0p4 to match the shipped MBR layout.
* docs/Targets.md: note the unconditional EL2 cleanup in the ZynqMP
and Versal SD-card sections.
Behavior change: non-Linux AArch64 EL2 payloads now enter with MMU
off and caches clean instead of inheriting wolfBoot's tables. No
in-tree payload relies on the old state leakage.
- 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).
Daniele Lacamera
Brett Nicholas
Paul Adelsbach
David Garske
Thomas Cook
Aidan Garske