Copilot review follow-up: ?= considers a defined-but-empty LSCRIPT_IN
(stale LSCRIPT_IN?= line in .config, exported empty env var) already
set, so it skipped every target-specific default and fell through to
the last-resort hal/$(TARGET).ld - e.g. TARGET=stm32l5 TZEN=0 lost its
hal/stm32l5-ns.ld layout. The strip-based last-resort check only fixed
that one line, not the 32 target sites.
Add the LSCRIPT_IN_DEFAULT helper in tools/config.mk (assigns only when
LSCRIPT_IN is undefined or empty) and convert all 29 arch.mk, 2
board.mk and 1 stage1/Makefile sites to it.
Copilot review follow-ups:
- config/Makefile: skip emitting a variable whose value is empty, so
'make config' with a blank LSCRIPT_IN prompt no longer persists a
defined-but-empty 'LSCRIPT_IN?=' (quoted test -n: unquoted, bash's
test returns true for a missing operand)
- Makefile: the last-resort hal/$(TARGET).ld default now keys on
strip(LSCRIPT_IN) being empty, so a persisted empty value falls
back correctly
- stage1/x86_fsp.mk: the .ld.in generation rule only applies to the
target-derived script; a user-provided LSCRIPT_IN is used as-is
(it previously produced a bogus hal/<abs path>.in prerequisite)
Copilot review follow-ups:
- tools/config.mk: add LSCRIPT_IN to CONFIG_VARS so 'make config'
persists it; it was documented as a .config option but the
regeneration silently dropped it
- Makefile: pass a user-provided LSCRIPT_IN to the recursive stage1
build as an absolute path (abspath), since the sub-make resolves
relative paths from stage1/ while the top-level link resolves them
from the repo root; target-derived stage1 defaults are untouched
Target-specific assignments in arch.mk/options.mk/board.mk used hard
'=', silently clobbering values the user set via command line,
environment, or a sourced .config (e.g. LSCRIPT_IN from PR #958 was
defeated on every target with a dedicated script).
Convert the target-default assignments to '?=' (first-set wins) and,
for LSCRIPT_IN, capture the user value before the target files are
parsed so the last-resort default (hal/$(TARGET).ld) and the ARMClang
.sct default only apply when the user provided nothing.
CMake: WOLFBOOT_LSCRIPT_TEMPLATE had the same flaw (plain set() over a
user -D value); guard it with NOT DEFINED and let test-app use an
absolute user template as-is.
Document LSCRIPT_IN as a user option in docs/compile.md.
The x86 FSP TGL boards (kontron_vx3060_s2, nai_68int6) share
hal/x86_fsp_tgl_stage1.ld; arch.mk selects it via 'LSCRIPT_IN ?=', but
the hard default here ran first, so the stage1 build of those boards
looked for a non-existent hal/kontron_vx3060_s2_stage1.ld (CI:
'kontron_vx3060_s2 build test', red on master).
We're doing some oddities in our linker script that differ from what is
done by default. To that end, we'd like to provide our own linker script
so we don't have to carry patches forward
- hal/renesas-rx.c builds the RX71M flash driver with CC-RX: the
driver runs from RAM through #pragma section FRAM and copyfuncs(),
and FPCKAR follows the BSP clock settings.
- IDE/Renesas/e2studio/RX71M holds the wolfBoot and app_RenesasRX01
CC-RX projects, their headers, make_images.sh and a Readme.
- docs/Renesas.md and docs/Targets.md point to the new projects, and
.gitignore lists their build and generated folders.
- test-configs.yml: RX71M build jobs, little endian and
BIG_ENDIAN=1 with WOLFBOOT_RENESAS_OSM.
- test-build-renesas-rx.yml: check that ROMCODE in wolfboot.bin is
0xFFFFFFFF for rx71m.
- Targets.md: Renesas RX71M section; Renesas.md and the CI image
README list RX71M.
- app_renesas_rx.c: printPart() takes the partition id and reads the
state through wolfBoot_get_partition_state(); the trailer line
prints BOOT or none.
- main() calls hal_init() before printing.
- hal_clk_init(): rx71m runs the main crystal (RX_MAIN_XTAL_HZ,
default 24MHz) through the PLL to 240MHz.
- hal_prepare_boot(): under WOLFBOOT_RESTORE_CLOCK, switch to the
LOCO and stop the PLL and main oscillator on rx71m.
- uart_init(): SCI7 on P90/P92 by default; uart_write() waits for
TEND. hal_led_on()/hal_led_off(): LED0 on P03.
- renesas-rx.c: TARGET_rx71m flash driver run from RAM, with #error
unless RAM_CODE and __WOLFBOOT are defined. It copies the FCU
firmware at init, programs 256-byte units at most once per erase,
and masks interrupts with timeouts and FSTATR checks for each
program and erase.
- renesas-rx.h: PSW, FASTAT and FAEINT bits and the new flash
error codes.
- renesas-rx71m.config: commented RX_MAIN_XTAL_HZ line.
- test-app: link .ramcode into RAM and build renesas-rx.o with
RAM_CODE and __WOLFBOOT for rx71m.
- renesas-rx71m.config, rx71m.ld, rx71m.c: RSK+ RX71M layout with
NVM_FLASH_WRITEONCE=1, .romcode at 0xFFFFFF80 and .ofs_rx71m at
0x00120040.
- arch.mk: reject PKA, DELTA_UPDATES and NVM_FLASH_WRITEONCE other
than 1 for rx71m; build with -misa=v2; drop .ofs_rx71m from
wolfboot.bin and fill gaps with 0xFF.
- renesas-rx.h: rx71m clock, flash, FACI and MPC values;
hal_clk_init() sets SYS_MEMWAIT.
- boot_renesas.c: INT_Fault for the rx71m fault vectors,
RomCodeArea[] with ROMCODE 0xFFFFFFFF, and the option-setting
array under WOLFBOOT_RENESAS_OSM.
wolfSSL's SHA-256 C transform now takes a caller-owned scratch struct
(message schedule plus working variables) allocated once per
Update/Final call under WOLFSSL_SMALL_STACK, sized
WC_SHA256_TSCRATCH_SIZE (288 bytes) rather than one 256-byte block of
schedule per transform. The static sha_block slot, pinned at
HASH_BLOCK_SIZE words, no longer fits the request, so XMALLOC() returns
NULL and image hashing fails with MEMORY_E (observed as
"Failure -1: Hdr 1, Hash 0, Sig 0" in the library smoke test).
Size sha_block by WC_SHA256_TSCRATCH_SIZE when the included wolfSSL
defines it, falling back to the historical HASH_BLOCK_SIZE words for
older wolfSSL and FIPS bundles that predate the constant; gate the
ED25519 pool's sha512_block on WC_SHA512_TSCRATCH_SIZE the same way
(same value today), including sha512.h for ED25519 builds, since the
hash-selection chain otherwise pulls in only the image hash's header
and would leave the constant invisible. Every slot entry now advertises sizeof() of its
backing array, so a slot can never claim more than its storage.
SHA-384 and SHA3-384 slots keep the fallback sizing unchanged.
David Garske
Daniele Lacamera
Thomas Cook
Dirk Van Haerenborgh
Brett Nicholas
Mattia Moffa
Yosuke Shimizu
Daniele Lacamera
Daniel Pouzzner