The P1021 QE and T10xx QE/FMan microcode blobs are validated only for
structural integrity (header magic, version, size bounds) before they
are activated; no cryptographic authentication is applied. State that
in Targets.md for both targets, with the deployment-model reasoning:
the P1021 microcode region sits inside the update partition, and the
T10xx regions require local board flash write access, which also
allows replacing the wolfBoot image itself.
Same residual claim as F-8000 and F-9761 (T10xx QE and FMan paths);
the bounds fixes for all three are already in master (000c05c7,
91c020a2). Product decision: no microcode authentication feature.
test-configs.yml already builds this config; what nothing covers is the
keytools half of the documented procedure -- signing and encrypting an
AArch64 payload and assembling the boot image. That is where the wrong
key size in the docs hid, so build it in CI.
Builds with DEBUG_UART=1, the mode the docs tell users to run and one
that did not compile until now. It stops short of booting: the target
emits nothing on the console under QEMU, so there is nothing to assert.
DEBUG_UART=1 did not compile: uart_init() declared an unused local and
-Werror rejected it, so the target's console output could never be
enabled. Drop the local.
The documented key file is 44 bytes, but AES256-CTR wants a 32-byte key
plus a 16-byte IV; sign fails with "Error reading IV" as written. Use
48 bytes, matching the key the HAL used to carry.
Drop the internal report numbers from source, test and Makefile
comments: they mean nothing outside the tracker and do not belong in
the tree. Condense the long inline comment blocks the review flagged,
and note in the raspi3 encrypted example and its docs that CI builds
but does not boot it, so the end-to-end path has no automated
coverage.
Comments and docs only; no functional change.
Removing the hardcoded test key is right, but nothing on this target
calls wolfBoot_set_encrypt_key() any more, so the shipped example and
the docs walk-through (whose example key was that same test key) no
longer boot an encrypted image. Say so in both places.
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.
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.
PolarFire MPFS250, Versal VMK180, and ZynqMP "Booting PetaLinux"
walkthroughs now describe both options for handing PetaLinux off through
the FIT image:
* Option A (default GZIP=1): set compression="gzip" in the .its,
point data at Image.gz / linux.bin.gz, and let mkimage build the
FIT directly. wolfBoot decompresses straight to the kernel load
address at boot and verifies hash-1.
* Option B (GZIP=0): keep the existing host-side gzip -cdvk /
gunzip step and compression="none" in the .its.
ZynqMP also gains a "FIT ramdisk (initramfs)" subsection covering
RAMDISK=1, WOLFBOOT_LOAD_RAMDISK_ADDRESS, the commented-out opt-in
block in zynqmp_sdcard.config, gzip ramdisk support, and a sample ITS
layout with kernel + DTB + ramdisk subimages.
David Garske
Daniele Lacamera
Mattia Moffa
Marco Oliverio
Yosuke Shimizu
Tobias Frauenschläger