Add Zephyr-based test platform for QEMU MPS boards#1750
Conversation
ec37866 to
fdf2d86
Compare
CBMC Results (ML-KEM-768)Full Results (191 proofs)
|
CBMC Results (ML-KEM-512)Full Results (191 proofs)
|
CBMC Results (ML-KEM-1024)Full Results (191 proofs)
|
| $$(Q)cp $(ZEPHYR_BUILD_DIR)/$(2)/zephyr/zephyr.elf $$@ | ||
| endef | ||
|
|
||
| $(eval $(call ZEPHYR_BIN,512,test_mlkem512,test/src/test_mlkem.c)) |
There was a problem hiding this comment.
Why do we need those per-target recipes here? This wasn't needed in previous baremetal platforms, and doesn't scale well as new make targets are added.
hanno-becker
left a comment
There was a problem hiding this comment.
I very much like the consolidation of targets and am generally in favor of introducing Zephyr.
However, I'm not yet happy with how all make targets have to be manually adjusted in the new platform.mk. Can we do better and keep building the test sources in the same way as for other baremetal platforms, but merely add some configurable 'finalize-build' step which bundles the compiled .o files and the Zephyr sources into a Zephyr binary? So rather than having only an EXTRA_SOURCES for a baremetal platform, we generalize this to a more elaborate custom build finalization step -- while still keeping the way the test sources themselves are compiled? Just thinking out loud.
ebf9764 to
f5160ba
Compare
Build the mlkem-native tests as Zephyr applications so they run on QEMU-emulated Arm MPS boards spanning Cortex-M3/M4/M7/M33/M55. This greatly simplifies supporting more hardware without the need for dedicated hardware abstraction layers. Signed-off-by: Matthias J. Kannwischer <matthias@zerorisc.com>
The Zephyr platform now covers the QEMU MPS boards, so the baremetal m55-an547 and m33-an524 platforms and the pqmx package they used are no longer needed. Also drops the cross-arm-embedded dev shell and the two baremetal.yml jobs. Signed-off-by: Matthias J. Kannwischer <matthias@zerorisc.com>
Ordinarily, `main` is exempt from -Wmissing-prototypes. However, if it's re-#define'd, it isn't. To allow -Wmissing-prototypes in baremetal platforms wrapping `main`, this commit adds an explicit prototype for `main` in all test applications. Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>
Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>
The generic test build links each binary from prebuilt objects and the per-scheme library. A platform that builds its binaries differently (e.g. the Zephyr platform, which hands the sources to its own CMake build) had no way to hook into this without per-binary recipes. This commit introduces a CUSTOM_BUILD hook in test/mk/rules.mk: when set, it replaces the default link step, and test/mk/components.mk attaches each binary's sources -- via the new per-binary TEST_SRCS variable -- as its prerequisites rather than prebuilt objects and libraries. TEST_SRCS is the single source of truth for a binary's test sources, so a custom platform needs no per-binary wiring. As part of this, the ADD_SOURCE_UNIT / ADD_SOURCE_ALLOC special cases are folded into ADD_SOURCE (parameterized by a library suffix), and the per-test defines (MLK_STATIC_TESTABLE=, MLK_CONFIG_FILE=...) move from the test object to the test binary. Target-specific CFLAGS propagate to a target's prerequisites, so the object still gets them; attaching to the binary lets a custom build read them off CFLAGS too. No change to the default build: with CUSTOM_BUILD unset, the link step and prerequisites are as before. Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>
The Zephyr platform previously hand-enumerated every test binary with a per-binary ZEPHYR_BIN recipe. This commit rewrites it on top of the generic CUSTOM_BUILD hook: a single CUSTOM_BUILD recipe drives the CMake build for whichever binary is being made, taking its test sources from the per-binary TEST_SRCS. Adding a test binary now needs no change here. The test binary's full CFLAGS are forwarded to the CMake build and applied to the mlkem amalgamation and the test sources alike, so the firmware is built with the project's own warning/optimization/standard policy and feature defines (including the parameter set) rather than a divergent Zephyr default. Two flags are rewritten for the CMake build dir: -Imlkem is made absolute, and the embedded quotes of -DMLK_CONFIG_FILE="..." are escaped so they survive the recipe shell and CMake's separate_arguments. The QEMU test-tuning defines (smaller iteration counts) are amended onto CFLAGS and forwarded the same way, replacing the separate ZEPHYR_TEST_DEFS / ZEPHYR_LEVEL parameters. The app CMakeLists consumes a ZEPHYR_TEST_SRCS list (entrypoint plus support sources) instead of a single ZEPHYR_TEST_SRC. Also adds a README documenting the platform. Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>
The Zephyr platform forwards the test binary's full CFLAGS -- including the project's strict, -Werror'd warning set -- to the CMake build. Our own sources are clean under it, but the benchmark cycle HAL (test/hal/hal.c) is the one test source that includes Zephyr SDK headers (<zephyr/kernel.h>), and those are not -Werror-clean (-Wconversion, -Wsign-conversion, -pedantic). This broke the benchmark build on all boards. Drop -Werror for hal.c only, via a per-source COMPILE_OPTIONS property, so the SDK-header warnings no longer fail the build while our own sources stay strict. Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>
f5160ba to
c147080
Compare
No description provided.