Add wolfBoot support for booting VxWorks 7 SMP 64-bit (and signed ELF
images) on the NXP T2080 (e6500) / Curtiss-Wright VPX3-152.
Key fix: bring up the e6500 cluster L2 cache in the correct order -- set
L2PE (ECC) in its own polled write BEFORE enabling L2E, with L2FI|L2LFC --
matching CW U-Boot (SDK2.0). The previous bare-L2E init left the L2 ECC
array uninitialized for the kernel's 0x1E0000 set, machine-checking VxWorks
(MCSR[IF], L2ERRDET MBECC).
Also: ePAPR spin-table SMP bring-up of all four cores, ELF in-place loader
staging-overlap fix, DPAA/LIODN + QMan/BMan init, 64-bit OS handoff
(LAW/TLB/IVOR), and NAII 68PPC2 + CW VPX3-152 board configs.
Wires the new wolfBoot_gunzip inflater into the FIT image-loading path
and adds initramfs (ramdisk) extraction with DTB /chosen fixup so a
single signed FIT can carry kernel, DTB, and rootfs.
GZIP path
---------
* fit_load_image_ex(out_max) added; fit_load_image kept as a wrapper.
* When a subimage carries compression="gzip", inflate straight to the
FIT-declared load address, then verify the FIT hash-1 subnode
(sha256 / sha384 if available) for defense in depth on top of the
outer wolfBoot signature. The compression property is now read
unconditionally so a build without WOLFBOOT_GZIP can warn and fail
closed instead of silently memcpy-ing compressed bytes as if they
were raw.
* fit_verify_hash propagates wc_InitSha256 / wc_Sha256Update /
wc_Sha256Final return codes (and the SHA-384 equivalents) - any
non-zero return is treated as a verification failure so a misbehaving
backend cannot silently degrade to a no-op.
* GZIP=1 is the new default in the FIT-using example configs (zynqmp,
zynqmp_sdcard, polarfire_mpfs250, polarfire_mpfs250_qspi,
versal_vmk180, versal_vmk180_sdcard); set GZIP=0 to opt out.
Ramdisk path
------------
* fit_find_images() gains a ramdisk out-arg and fdt_fixup_initrd()
writes /chosen/linux,initrd-{start,end} as 64-bit big-endian cells.
* update_disk.c and update_ram.c load the FIT ramdisk node (under
WOLFBOOT_FIT_RAMDISK) and patch the loaded DTB. Compressed (gzip)
ramdisks reuse the same fit_load_image_ex() decompress path.
* RAMDISK=1 build switch defines WOLFBOOT_FIT_RAMDISK;
WOLFBOOT_LOAD_RAMDISK_ADDRESS is plumbed through tools/config.mk ->
Makefile sed -> include/target.h.in. Defaults to 0; when 0 the
ramdisk stays at whatever fit_load_image returned.
* hal/zynq.c and hal/versal.c bump fdt_totalsize headroom from 512 to
768 bytes to fit the new linux,initrd-{start,end} entries.
* config/examples/zynqmp_sdcard.config gains a commented-out opt-in
block (RAMDISK=1, WOLFBOOT_LOAD_RAMDISK_ADDRESS=0x40000000, alt
LINUX_BOOTARGS) so a single config file covers both rootfs-on-disk
and FIT-bundled-initramfs flows.
Builds against the existing master configs are byte-identical when
GZIP=0 and RAMDISK is unset.
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.
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).
Removed NVM_FLASH_WRITEONCE restriction for psoc6.
Update flash hal functions to support read-modify-erase-write way to perform the programming of flash.
Adds support for running wolfBoot in **Machine Mode (M-mode)** on the PolarFire SoC MPFS250T, booting from eNVM and loading a signed application from **SC QSPI flash** into on-chip LIM (Loosely Integrated Memory). No HSS (Hart Software Services) or DDR is required. It also extends the existing PolarFire HAL with multi-hart support, L2 cache configuration, per-hart UART, and refactors shared code (SDHCI, SCB mailbox, linker/test-app) for both S-mode and M-mode builds.
* 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