Add Raspberry Pi Compute Module 4 (BCM2711) target

Makefile

@@ -310,6 +310,10 @@ ifeq ($(TARGET),raspi3)
     MAIN_TARGET:=wolfboot.bin
 endif
 
+ifeq ($(TARGET),cm4)
+    MAIN_TARGET:=wolfboot.bin
+endif
+
 ifeq ($(TARGET),sim)
     CFLAGS+=-fno-pie
     LDFLAGS+=-no-pie

arch.mk

@@ -117,8 +117,18 @@ ifeq ($(ARCH),AARCH64)
     SPI_TARGET=nxp
   endif
 
+  ifeq ($(TARGET),cm4)
+    # Raspberry Pi Compute Module 4 - Broadcom BCM2711, Cortex-A72
+    ARCH_FLAGS=-mcpu=cortex-a72+crypto -march=armv8-a+crypto -mtune=cortex-a72
+    # -mstrict-align: wolfBoot runs with the MMU off (simple startup), so data
+    # accesses are Device memory where unaligned access faults. Required for the
+    # FIPS in-core HMAC over the code region (NO_ARM_ASM drops the asm path that
+    # otherwise sets this).
+    CFLAGS+=$(ARCH_FLAGS) -DCORTEX_A72 -mstrict-align
+  endif
+
   # Default ARM ASM setting for unrecognized AARCH64 targets
-  ifeq ($(filter zynq versal nxp_ls1028a,$(TARGET)),)
+  ifeq ($(filter zynq versal nxp_ls1028a cm4,$(TARGET)),)
     NO_ARM_ASM?=1
   endif
 

config/examples/cm4-fips.config

@@ -0,0 +1,25 @@
+# Raspberry Pi CM4 (BCM2711) with the wolfCrypt FIPS 140-3 module.
+# Point WOLFBOOT_LIB_WOLFSSL at an unpacked FIPS / FIPS-ready wolfSSL tree.
+# Entropy comes from the BCM2711 RNG200 hardware TRNG (hal/cm4.c). See
+# docs/FIPS.md for the in-core hash-seal procedure (done on-target over UART).
+ARCH?=AARCH64
+TARGET?=cm4
+SIGN?=ECC384
+HASH?=SHA384
+FIPS?=1
+WOLFBOOT_LIB_WOLFSSL?=../wolfssl-5.9.2-gplv3-fips-ready
+DEBUG?=1
+DEBUG_UART?=1
+VTOR?=1
+SPMATH?=1
+NO_ARM_ASM?=1
+PKA?=0
+WOLFTPM?=0
+NO_XIP?=1
+NO_QNX?=1
+IMAGE_HEADER_SIZE?=1024
+WOLFBOOT_SECTOR_SIZE=0x400
+WOLFBOOT_NO_PARTITIONS=1
+WOLFBOOT_RAMBOOT_MAX_SIZE=0x20000000
+WOLFBOOT_LOAD_ADDRESS?=0x3080000
+WOLFBOOT_LOAD_DTS_ADDRESS?=0x400000

config/examples/cm4.config

@@ -0,0 +1,18 @@
+ARCH?=AARCH64
+TARGET?=cm4
+SIGN?=ECC384
+HASH?=SHA384
+DEBUG?=1
+VTOR?=1
+SPMATH?=1
+IMAGE_HEADER_SIZE?=1024
+PKA?=0
+WOLFTPM?=0
+DEBUG_UART?=0
+NO_XIP?=1
+NO_QNX?=1
+WOLFBOOT_SECTOR_SIZE=0x400
+WOLFBOOT_NO_PARTITIONS=1
+WOLFBOOT_RAMBOOT_MAX_SIZE=0x20000000
+WOLFBOOT_LOAD_ADDRESS?=0x3080000
+WOLFBOOT_LOAD_DTS_ADDRESS?=0x400000

config/examples/cm4_sdcard.config

@@ -0,0 +1,39 @@
+# Raspberry Pi CM4 (BCM2711) - eMMC/SD A/B disk boot (Phase 2)
+#
+# Boots from the BCM2711 EMMC2 controller (Arasan SDHCI @ 0xFE340000), which
+# drives the onboard eMMC (eMMC variants) or the microSD (CM4 Lite). wolfBoot
+# reads GPT A/B image partitions via update_disk.c and boots the highest valid
+# version with rollback.
+#
+# NOTE: the EMMC2 platform glue in hal/cm4.c is bring-up scaffolding pending
+# on-hardware validation (controller clock/pinmux state left by the GPU
+# firmware, card-detect wiring on the carrier). Use SDHCI_FORCE_CARD_DETECT
+# for the embedded eMMC path.
+ARCH?=AARCH64
+TARGET?=cm4
+SIGN?=ECC384
+HASH?=SHA384
+IMAGE_HEADER_SIZE?=1024
+DEBUG?=0
+DEBUG_UART?=1
+DISK_SDCARD?=1
+DISK_EMMC?=0
+CFLAGS_EXTRA+=-DSDHCI_FORCE_CARD_DETECT
+EXT_FLASH?=0
+NO_XIP=1
+NO_QNX?=1
+ELF?=1
+VTOR?=1
+SPMATH?=1
+PKA?=0
+WOLFTPM?=0
+WOLFBOOT_NO_PARTITIONS=1
+CFLAGS_EXTRA+=-DBOOT_PART_A=1
+CFLAGS_EXTRA+=-DBOOT_PART_B=2
+CFLAGS_EXTRA+=-DDISK_BLOCK_SIZE=0x80000
+WOLFBOOT_LOAD_ADDRESS?=0x10000000
+WOLFBOOT_RAMBOOT_MAX_SIZE=0x2BC00000
+WOLFBOOT_LOAD_DTS_ADDRESS?=0x1000
+WOLFBOOT_PARTITION_BOOT_ADDRESS=0x80200000
+WOLFBOOT_PARTITION_SIZE=0x4000000
+WOLFBOOT_SECTOR_SIZE=0x1000

config/examples/sim-fips.config

@@ -0,0 +1,22 @@
+# wolfBoot simulator build using the wolfCrypt FIPS 140-3 module.
+# Point WOLFBOOT_LIB_WOLFSSL at an unpacked FIPS (or FIPS-ready) wolfSSL tree.
+# Prototype target for the CM4 FIPS integration (see docs/FIPS.md).
+ARCH=sim
+TARGET=sim
+SIGN?=ECC384
+HASH?=SHA384
+FIPS?=1
+WOLFBOOT_LIB_WOLFSSL?=../wolfssl-5.9.2-gplv3-fips-ready
+WOLFBOOT_SMALL_STACK?=0
+SPI_FLASH=0
+DEBUG=1
+
+# sizes should be multiple of system page size
+WOLFBOOT_PARTITION_SIZE=0x40000
+WOLFBOOT_SECTOR_SIZE=0x1000
+WOLFBOOT_PARTITION_BOOT_ADDRESS=0x80000
+WOLFBOOT_PARTITION_UPDATE_ADDRESS=0x100000
+WOLFBOOT_PARTITION_SWAP_ADDRESS=0x180000
+
+# required for keytools
+WOLFBOOT_FIXED_PARTITIONS=1

docs/FIPS.md

@@ -0,0 +1,112 @@
+# wolfBoot with wolfCrypt FIPS 140-3
+
+wolfBoot can perform its firmware signature verification using the wolfCrypt
+FIPS 140-3 validated cryptographic module. In this configuration the boot-time
+integrity and authenticity checks (ECDSA/RSA signature, SHA hashing) run inside
+the validated module boundary, and the module runs its power-on self-tests
+(POST) and conditional algorithm self-tests (CASTs) before it is used.
+
+This document describes how to build wolfBoot against a FIPS wolfCrypt source
+tree and how to seal the module's in-core integrity hash.
+
+## Background
+
+A standard wolfBoot build compiles a curated list of individual
+`wolfcrypt/src/*.o` files (see `arch.mk` and `options.mk`) with
+`WOLFCRYPT_ONLY`. A FIPS build instead compiles the whole validated module
+boundary together, adds the boundary sources (`fips.c`, `fips_test.c`), and
+verifies an in-core integrity hash (HMAC-SHA-256 over the module's code and
+read-only data) at initialization. The signature/hash algorithms wolfBoot uses
+for verification are unchanged - only their implementation moves into the
+validated boundary.
+
+Approved algorithms for firmware verification include ECDSA (P-256/P-384/P-521)
+and RSA with SHA-256/384/512. EdDSA (Ed25519/Ed448) is outside the module
+boundary; use `SIGN=ECC384 HASH=SHA384` (or an RSA/SHA variant) for FIPS.
+
+## Getting the FIPS source
+
+Obtain a FIPS wolfCrypt source tree. For evaluation, the FIPS-ready bundle can
+be downloaded from wolfSSL:
+
+```
+https://www.wolfssl.com/wolfssl-5.9.2-gplv3-fips-ready.zip
+```
+
+Production use requires the licensed, validated FIPS bundle. Unpack it and
+point wolfBoot at it with `WOLFBOOT_LIB_WOLFSSL`.
+
+## Building wolfBoot with FIPS
+
+1. Point the build at the FIPS wolfSSL tree (default is `lib/wolfssl`):
+
+   ```
+   make WOLFBOOT_LIB_WOLFSSL=/path/to/wolfssl-fips-ready ...
+   ```
+
+2. Enable FIPS in `include/user_settings.h` (gated so non-FIPS builds are
+   unaffected). `settings.h` in the FIPS tree defines the exact version, so
+   just enable FIPS:
+
+   ```c
+   #define HAVE_FIPS
+   ```
+
+   The FIPS-ready 5.9.2 bundle reports `HAVE_FIPS_VERSION 7`
+   (`HAVE_FIPS_VERSION_MINOR 0`).
+
+3. Add the FIPS boundary sources (`fips.c`, `fips_test.c`) and the in-boundary
+   crypto objects to the wolfcrypt object list, and add the FIPS in-core memory
+   sections to the target linker script so the integrity hash covers exactly
+   the module boundary.
+
+## Sealing the in-core integrity hash
+
+The validated module verifies an in-core integrity hash at startup. A fresh
+build ships with a placeholder, so the first run reports a mismatch. Capture
+the runtime hash and seal it:
+
+1. Build and run. Register a FIPS callback so a mismatch reports the runtime
+   hash. On the CM4 target the test application (`test-app/app_cm4.c`) does this
+   over the UART: it calls `wolfCrypt_SetCb_fips()` and, on `IN_CORE_FIPS_E`,
+   prints the hash.
+
+2. Copy the reported hash into `verifyCore[]` in
+   `wolfcrypt/src/fips_test.c` (the build macro / array that seals the hash).
+
+3. Rebuild (and re-flash). The in-core check now passes and the module reaches
+   the operational state; `wolfCrypt_GetStatus_fips()` returns 0.
+
+## Entropy source (required)
+
+The FIPS DRBG needs a seed source. wolfBoot's lean configuration compiles out the OS seed paths, so a seed must be provided via `CUSTOM_RAND_GENERATE_SEED` (the RNG is kept enabled in FIPS mode - the `HAVE_FIPS` block in `include/user_settings.h` undoes wolfBoot's `WC_NO_RNG`/`WC_NO_HASHDRBG`). The example wiring points `CUSTOM_RAND_GENERATE_SEED` at `wolfBoot_fips_seed()`, implemented per target: `/dev/urandom` on the simulator (`hal/sim.c`) and the BCM2711 RNG200 hardware TRNG on the CM4 (`hal/cm4.c`). Without a working seed, the ECDSA power-on self-test (which performs a sign) fails with `ECDSA_KAT_FIPS_E` because `wc_GenerateSeed()` returns `NOT_COMPILED_IN`.
+
+## Sealing note
+
+The in-core hash excludes `verifyCore[]`, but the placeholder-to-real-hash transition can perturb the computed hash, so sealing may take two or three passes. Repeat build -> capture reported hash -> update `verifyCore[]` -> rebuild until `wolfCrypt_GetStatus_fips()` returns 0.
+
+## Bare-metal targets
+
+The FIPS module is written for a hosted environment; a few things must be provided on bare-metal (e.g. the CM4):
+
+- **Power-on self-test entry.** The module registers its POST via a C constructor (`.init_array`), which a hosted C runtime runs before `main()`. wolfBoot's bare-metal startup does not run `.init_array`, so build with `NO_ATTRIBUTE_CONSTRUCTOR` and call `fipsEntry()` explicitly at startup (wolfBoot does this in `src/loader.c`).
+- **Aligned access.** wolfBoot runs with the MMU off, where AArch64 data accesses are Device memory and faulting on unaligned access; build with `-mstrict-align` so the in-core integrity HMAC over the code region does not fault.
+- **libc.** The module uses malloc/printf; provide a heap (`src/store_sbrk.c` + a linker `end` symbol) and stub the remaining newlib syscalls (`--specs=nosys.specs`).
+
+The simulator target (`config/examples/sim-fips.config`) is the recommended place to bring the module up first. The CM4 FIPS target (`config/examples/cm4-fips.config`) is a work in progress.
+
+## Verifying operation
+
+- POST/CASTs run at module initialization; `wc_RunAllCast_fips()` runs the
+  conditional algorithm self-tests and `wolfCrypt_GetStatus_fips()` reports the
+  module status (0 = operational).
+- wolfBoot must treat a non-zero FIPS status as a hard failure and refuse to
+  boot (no OS handoff).
+- A deliberately corrupted module boundary (flip a byte) must make the in-core
+  check fail and block the boot - the negative test for the integration.
+
+## See also
+
+- [Targets.md](Targets.md) - Raspberry Pi Compute Module 4 (BCM2711) target,
+  which uses `SIGN=ECC384 HASH=SHA384` and carries the on-target FIPS test
+  harness in `test-app/app_cm4.c`.

docs/Targets.md

@@ -6,6 +6,7 @@ This README describes configuration of supported targets.
 
 * [Simulated](#simulated)
 * [Cortex-A53 / Raspberry PI 3](#cortex-a53--raspberry-pi-3-experimental)
+* [Cortex-A72 / Raspberry Pi Compute Module 4](#cortex-a72--raspberry-pi-compute-module-4-bcm2711)
 * [Cypress PSoC-6](#cypress-psoc-6)
 * [Infineon AURIX TC3xx](#infineon-aurix-tc3xx)
 * [Intel x86-64 Intel FSP](#intel-x86_64-with-intel-fsp-support)
@@ -3694,6 +3695,79 @@ qemu-system-aarch64 -M raspi3b -m 1024 -serial stdio -kernel wolfboot_linux_rasp
 ```
 
 
+## Cortex-A72 / Raspberry Pi Compute Module 4 (BCM2711)
+
+wolfBoot runs on the Raspberry Pi Compute Module 4 (CM4), a Broadcom BCM2711 with a quad-core Cortex-A72 (AArch64). wolfBoot takes the place of the second-stage OS loader: the BCM2711 boot ROM loads the VideoCore firmware, the firmware loads `kernel8.img` from the boot partition, and that `kernel8.img` is wolfBoot. wolfBoot then verifies the signed application image and boots it, extending the platform root of trust into the OS.
+
+```
+BCM2711 boot ROM -> SPI EEPROM bootloader -> VideoCore firmware (start4.elf)
+   -> kernel8.img (wolfBoot) -> verify (ECDSA/SHA) -> application
+```
+
+On CM4 modules with onboard eMMC the boot files live on the eMMC FAT boot partition; on CM4 Lite they live on a microSD. Either way the medium hangs off the BCM2711 EMMC2 controller (a standard SDHCI v3.0 Arasan block at `0xFE340000`).
+
+### Building
+
+```
+cp config/examples/cm4.config .config
+make CROSS_COMPILE=aarch64-none-elf-
+```
+
+The example uses `SIGN=ECC384 HASH=SHA384` (both FIPS-approved). wolfBoot is entered by the firmware at `0x80000` at EL2, matching `hal/cm4.ld`. The image is loaded from RAM: wolfBoot reads the signed application at `kernel_addr` (`0x140000`), verifies it, copies it to `WOLFBOOT_LOAD_ADDRESS`, and boots.
+
+### Signing and assembling the boot image
+
+Sign the application, then concatenate wolfBoot and the signed image so the signed image lands at `kernel_addr` (`0x140000` = `0x80000` load + `0xC0000`):
+
+```
+make keytools tools/bin-assemble/bin-assemble
+IMAGE_HEADER_SIZE=1024 ./tools/keytools/sign --ecc384 --sha384 \
+    app.bin wolfboot_signing_private_key.der 1
+tools/bin-assemble/bin-assemble kernel8.img \
+    0x0     wolfboot.bin \
+    0xC0000 app_v1_signed.bin
+```
+
+### config.txt
+
+The CM4 UART on GPIO14/15 defaults to the mini-UART because the PL011 is used by Bluetooth. wolfBoot drives the PL011, so route it to the header and fix a known UART clock:
+
+```
+arm_64bit=1
+kernel=kernel8.img
+enable_uart=1
+uart_2ndstage=1
+dtoverlay=disable-bt
+init_uart_clock=48000000
+init_uart_baud=115200
+```
+
+### Flashing
+
+- CM4 Lite: write `kernel8.img` + the RPi firmware (`start4.elf`, `fixup4.dat`) + `config.txt` to the microSD FAT boot partition.
+- CM4 with eMMC: put the module in USB boot mode (nRPIBOOT), run `rpiboot` to expose the eMMC as USB mass storage, and write the same files to its FAT boot partition. See https://github.com/raspberrypi/usbboot .
+
+### Boot output
+
+With `DEBUG_UART=1`, a successful authenticated boot prints (115200 8N1):
+
+```
+wolfBoot CM4 (BCM2711 Cortex-A72) hal_init, EL2
+Trying partition 0 at 0x140000
+Checking integrity...done
+Verifying signature...done
+Firmware Valid
+Booting at 0x3080000
+```
+
+### Optional: eMMC/SD A/B updates
+
+`config/examples/cm4_sdcard.config` enables the disk updater (`DISK_SDCARD`/`DISK_EMMC`), driving the BCM2711 EMMC2 controller through the generic SDHCI driver (`src/sdhci.c`) for A/B image partitions on the boot medium. This path is provided as bring-up scaffolding and is not yet hardware-validated.
+
+### FIPS 140-3
+
+The CM4 target uses `SIGN=ECC384 HASH=SHA384` (FIPS-approved) and can perform its signature verification with the wolfCrypt FIPS 140-3 validated module. The on-target harness in `test-app/app_cm4.c` registers a FIPS callback and prints the runtime in-core integrity hash over the UART for the `verifyCore[]` bootstrap. See [FIPS.md](FIPS.md) for the full build and hash-sealing procedure.
+
 ## Xilinx Zynq UltraScale
 
 AMD Zynq UltraScale+ MPSoC ZCU102 Evaluation Kit - Quad-core ARM Cortex-A53 (plus dual Cortex-R5).