mirror of https://github.com/wolfSSL/wolfBoot.git
184 lines
7.5 KiB
Plaintext
184 lines
7.5 KiB
Plaintext
# wolfBoot configuration for AMD ZynqMP ZCU102 - SD Card Boot
|
|
# Zynq UltraScale+ MPSoC ZU9EG - Quad-core ARM Cortex-A53
|
|
#
|
|
# This configuration enables SD card boot for the ZynqMP:
|
|
# FSBL -> PMUFW -> BL31 (EL3) -> wolfBoot (EL2) -> Linux (EL1)
|
|
#
|
|
# wolfBoot loads firmware images from MBR partitions on SD card.
|
|
# Uses the generic SDHCI driver with SD1 controller (external SD slot on ZCU102).
|
|
|
|
ARCH?=AARCH64
|
|
TARGET?=zynq
|
|
|
|
WOLFBOOT_VERSION?=0
|
|
|
|
# RSA 4096-bit with SHA3-384 (matching existing zynqmp.config)
|
|
SIGN?=RSA4096
|
|
HASH?=SHA3
|
|
IMAGE_HEADER_SIZE?=1024
|
|
|
|
# Debug options
|
|
DEBUG?=0
|
|
DEBUG_SYMBOLS=1
|
|
DEBUG_UART=1
|
|
CFLAGS_EXTRA+=-DDEBUG_ZYNQ=1
|
|
|
|
# Display boot timing data
|
|
#BOOT_BENCHMARK?=1
|
|
|
|
# SD card support - use SDHCI driver
|
|
DISK_SDCARD?=1
|
|
DISK_EMMC?=0
|
|
# ZynqMP Arasan SDHCI does not support CDSS/CDTL card detect test level.
|
|
# Since FSBL booted from the same SD card, we know it is present.
|
|
CFLAGS_EXTRA+=-DSDHCI_FORCE_CARD_DETECT
|
|
# Note: Arasan SDHCI v3.0 does not support HV4E mode. The platform layer
|
|
# in hal/zynq.c transparently redirects SRS22/SRS23 to SRS00 for legacy SDMA.
|
|
|
|
# Disable QSPI flash when using SD card
|
|
EXT_FLASH?=0
|
|
NO_XIP=1
|
|
|
|
# ELF loading support
|
|
ELF?=1
|
|
#DEBUG_ELF?=1
|
|
|
|
# Native gzip decompression for FIT subimages (set GZIP=0 to disable)
|
|
GZIP?=1
|
|
|
|
# Boot Exception Level: leave wolfBoot at EL2 for handoff to Linux (matches
|
|
# the standard PetaLinux U-Boot flow and preserves KVM/hypervisor use of
|
|
# EL2). The EL2 Linux-cleanup path in do_boot() will clean dcache/disable
|
|
# MMU before jumping to the kernel. To drop to EL1 via ERET instead, set
|
|
# BOOT_EL1?=1 (requires EL2_HYPERVISOR=1, which is the hal/zynq.h default).
|
|
#BOOT_EL1?=1
|
|
|
|
# General options
|
|
VTOR?=1
|
|
CORTEX_M0?=0
|
|
NO_ASM?=0
|
|
ALLOW_DOWNGRADE?=0
|
|
NVM_FLASH_WRITEONCE?=0
|
|
V?=0
|
|
SPMATH?=1
|
|
RAM_CODE?=0
|
|
DUALBANK_SWAP?=0
|
|
PKA?=0
|
|
WOLFTPM?=0
|
|
|
|
# Toolchain
|
|
USE_GCC=1
|
|
CROSS_COMPILE=aarch64-none-elf-
|
|
|
|
# ============================================================================
|
|
# Partition Layout - MBR
|
|
# ============================================================================
|
|
# SD Card partition layout (MBR):
|
|
# Partition 1: boot (128MB, FAT32 LBA, bootable) - BOOT.BIN
|
|
# Partition 2: OFP_A (200MB, Linux) - Primary signed image
|
|
# Partition 3: OFP_B (200MB, Linux) - Update signed image
|
|
# Partition 4: rootfs (remainder) - Linux root filesystem
|
|
#
|
|
# Use partition numbers instead of flash addresses
|
|
# These are 0-based indices into the parsed partition array:
|
|
# part[0]=boot, part[1]=OFP_A, part[2]=OFP_B, part[3]=rootfs
|
|
WOLFBOOT_NO_PARTITIONS=1
|
|
CFLAGS_EXTRA+=-DBOOT_PART_A=1
|
|
CFLAGS_EXTRA+=-DBOOT_PART_B=2
|
|
|
|
# Disk read chunk size for firmware loading (update_disk.c). 512KB gives the
|
|
# best throughput (~1.4s for 32MB). The SDMA engine handles SDMA buffer
|
|
# boundary crossings within each 512KB chunk; this boundary is 4KB by default
|
|
# (auto-derived from SDHCI_DMA_THRESHOLD). To reduce boundary IRQs, override
|
|
# SDHCI_DMA_BUFF_BOUNDARY independently using the raw register value so the
|
|
# override is safe to use in preprocessor #if expressions, e.g.:
|
|
# CFLAGS_EXTRA+=-DSDHCI_DMA_BUFF_BOUNDARY=0x7000 # 512KB (SDHCI_SRS01_DMA_BUFF_512KB)
|
|
CFLAGS_EXTRA+=-DDISK_BLOCK_SIZE=0x80000
|
|
|
|
# Linux rootfs is on partition 4. Device naming depends on whether both
|
|
# ZynqMP SDHCI controllers are enabled in the XSA / device tree:
|
|
# * both sdhci0 + sdhci1 enabled -> SD1 = /dev/mmcblk1
|
|
# * only sdhci1 enabled (ZCU102 default -> only external SD populated)
|
|
# -> SD1 = /dev/mmcblk0
|
|
# Check `ls /sys/class/mmc_host/` on your running target to confirm.
|
|
CFLAGS_EXTRA+=-DLINUX_BOOTARGS_ROOT=\"/dev/mmcblk0p4\"
|
|
|
|
# ============================================================================
|
|
# Optional: FIT-bundled initramfs (ramdisk) instead of an on-disk rootfs
|
|
# ============================================================================
|
|
# Expects the PetaLinux INITRAMFS_IMAGE_BUNDLE=0 layout (FIT contains kernel
|
|
# + DTB + ramdisk). wolfBoot extracts the ramdisk to
|
|
# WOLFBOOT_LOAD_RAMDISK_ADDRESS and patches the loaded DTB with
|
|
# /chosen/linux,initrd-{start,end} so the kernel can find it. Compressed
|
|
# (gzip) ramdisks decompress automatically when GZIP=1.
|
|
#
|
|
# To enable: uncomment the three lines below and comment out the
|
|
# LINUX_BOOTARGS_ROOT line above (root= is supplied by the cpio's /init).
|
|
#FIT_RAMDISK?=1
|
|
#WOLFBOOT_LOAD_RAMDISK_ADDRESS?=0x40000000
|
|
#CFLAGS_EXTRA+=-DLINUX_BOOTARGS='"earlycon console=ttyPS0,115200 init_fatal_sh=1"'
|
|
|
|
# ============================================================================
|
|
# Boot Memory Layout
|
|
# ============================================================================
|
|
# wolfBoot runs from DDR at 0x8000000 (128MB, same as U-Boot, loaded via BL31).
|
|
# Must match the ORIGIN in hal/zynq.ld. WOLFBOOT_LOAD_ADDRESS must be above
|
|
# this region (wolfBoot is ~2MB) to avoid self-overwrite during firmware load.
|
|
WOLFBOOT_ORIGIN=0x8000000
|
|
|
|
# Load Partition to RAM Address (Linux kernel loads here)
|
|
WOLFBOOT_LOAD_ADDRESS?=0x10000000
|
|
|
|
# Cap on the RAM load region. The disk image payload is copied to
|
|
# WOLFBOOT_LOAD_ADDRESS before its header is authenticated, so the on-disk
|
|
# fw_size must be bounded first (see src/update_disk.c). This is an example
|
|
# config not tied to a real board, so the cap is just a sane sanity bound:
|
|
# 700 MB is far larger than any realistic FIT image yet keeps the load well
|
|
# clear of a 32-bit wrap back onto wolfBoot. Size it to your board's DDR
|
|
# (top_of_DDR - WOLFBOOT_LOAD_ADDRESS) for a real target.
|
|
WOLFBOOT_RAMBOOT_MAX_SIZE=0x2BC00000
|
|
|
|
# DTS (Device Tree) load address
|
|
WOLFBOOT_LOAD_DTS_ADDRESS?=0x1000
|
|
|
|
# ============================================================================
|
|
# Required for test-app (even with WOLFBOOT_NO_PARTITIONS=1)
|
|
# ============================================================================
|
|
WOLFBOOT_PARTITION_BOOT_ADDRESS=0x80200000
|
|
WOLFBOOT_PARTITION_SIZE=0x4000000
|
|
WOLFBOOT_SECTOR_SIZE=0x1000
|
|
|
|
# ============================================================================
|
|
# Optional Debug Options (uncomment to enable)
|
|
# ============================================================================
|
|
# SDHCI driver debug logs
|
|
#CFLAGS_EXTRA+=-DDEBUG_SDHCI
|
|
# Disk layer debug logs
|
|
#CFLAGS_EXTRA+=-DDEBUG_DISK
|
|
# GPT partition debug logs
|
|
#CFLAGS_EXTRA+=-DDEBUG_GPT
|
|
# Disk read/write test at boot
|
|
#CFLAGS_EXTRA+=-DDISK_TEST
|
|
|
|
# ============================================================================
|
|
# Optional: Ethernet PHY init over GEM MDIO
|
|
# ============================================================================
|
|
# Replays a board-specific "mii"/"mw" register sequence (normally run from
|
|
# U-Boot) so the PHY is configured before the OS starts. wolfBoot has no
|
|
# network stack; this drives only the MDIO management plane.
|
|
#CFLAGS_EXTRA+=-DWOLFBOOT_ZYNQMP_PHY_INIT
|
|
# Defaults (hal/zynq.h) target the ZCU102 PHY (DP83867 at MDIO 0x0C on GEM3)
|
|
# and just read the PHY ID. For another board, keep its values in a small
|
|
# header and select it with one line (this keeps the efficient step array):
|
|
#CFLAGS_EXTRA+=-DZYNQMP_PHY_INIT_HEADER='"myboard_phy.h"'
|
|
# where myboard_phy.h #defines any of:
|
|
# ZYNQMP_GEM_BASE GEM register base (default 0xFF0E0000 = GEM3)
|
|
# ZYNQMP_PHY_ADDR PHY MDIO address (default 0x0C)
|
|
# ZYNQMP_PHY_GPIO_ADDR PL register poked by a GPIO step; 0 disables it
|
|
# ZYNQMP_GEM_MDC_DIV NWCFG MDC divisor selector (default 5 = pclk/96)
|
|
# ZYNQMP_PHY_INIT_STEPS the {op,arg0,arg1} sequence rows
|
|
# Simple scalars can also be set directly, e.g.:
|
|
#CFLAGS_EXTRA+=-DZYNQMP_GEM_BASE=0xFF0B0000UL
|
|
# A PHY behind the PL only responds once the FPGA bitstream is loaded, so the
|
|
# boot image (BOOT.BIN) must include it (bootgen [destination_device=pl]).
|