Repository for manufacturing the SPIRS board

This repository contains the sources and tools used to manufacture and provision the SPIRS development board (SPIRS). It includes the board application, boot ROM changes, and a host-side server and flashing scripts used to prepare an SD card for a device under test.

Project overview

• Purpose: provide a minimal, reproducible manufacturing flow for SPIRS boards. The repository holds the firmware component that runs on the board, the bootrom changes required, and a host-side server that communicates with the board and produces artifacts to be written to the SD card.
• High level workflow:
  1. Cross-compile the board application and place it on the target (Keystone) image.
  2. Build/run the server on the host to receive data from the board, produce certificates/signatures and additional payloads.
  3. Run flash.sh to partition the SD card and copy the produced rootfs, fw_payload and additional data.

Repository structure

• board/ — board-side application and libraries

  • cfile.c — application that runs on the device. It obtains values from the PUF, configures the network connection, connects to the host server and transfers files.
  • lib/ — dependencies required by the board application (for example RoT_SPIRS.h). These are used when cross-compiling.

• bootrom/ — boot ROM modifications

  • main.c — modified main.c for the boot ROM. Replace the existing main.c in the bootrom project with this file when rebuilding the boot ROM.

• server/ — host-side server, keys and flashing utilities

  • server.c — host server that listens for a connection from the board, receives data, and generates certificates and signing data (secure module and kernel signatures).
  • liball.c — dependency archive used when compiling server.c (or a library built from it).
  • flash.sh — script that prepares and flashes an SD card: creates partitions and copies rootfs, fw_payload, and the additional data generated by server.
  • cert_manifacturer.der, ed25519.h, x509custom.h — certificate and crypto headers used by the server.

Build and usage

Below are the original instructions preserved and reorganized. Replace environment variables and paths (like ${COMPILER} and ${EXE}) with values from your toolchain.

• Build the board application (cross-compile):

  Use your cross-compiler and link against the board libraries. Example:

  ${COMPILER} cfile.c -L./lib -lrotspirs -lm -o ${EXE} --static

  After building, move the produced executable (${EXE}) onto the Keystone image for the board.

• Bootrom

  Replace the existing main.c in your bootrom project with bootrom/main.c from this repository when rebuilding the boot ROM.

• Server (host)

  Build the host server with liball.c available in the same folder. Example compile command (run in server/):

  gcc -o server server.c -L. -lall

  The server program configures networking, opens a socket and waits for the board to connect. When the board sends its data, the server creates certificates and additional data (secure module and kernel signatures) required by the device. The server expects rootfs and fw_payload to be present in the same directory when creating the additional data.

• Flashing the SD card

  The script server/flash.sh formats and partitions the SD card, then copies rootfs, fw_payload and the additional data produced by the server into the SD image. Ensure those files are present in the same directory as flash.sh before running it.

Goals and assumptions

• Goal: provide a reproducible minimal manufacturing flow for SPIRS boards: produce device-side binary, host-side artifacts, and prepare an SD card for flashing.
• Assumptions:
  • You have a suitable cross-compiler for the target platform (Keystone board).
  • rootfs and fw_payload artifacts are produced/available alongside the server before generating additional data.
  • The host running server has the required crypto libraries and tools to build and run the code.

Notes, troubleshooting and tips

• The board application (board/cfile.c) reads PUF values — ensure hardware support and drivers are available when running on the device.
• If you see network issues between the board and the host server, check firewall rules and that both endpoints are on the correct interfaces.
• Keep manufacturer keys and certificates safe; do not commit additional private keys to the repository.

Contacts & license

For questions about this manufacturing flow, contact the project maintainers (see repository metadata) or open an issue. This repository does not include an explicit license file; if you need one, add a LICENSE describing permitted uses.

Repository for manifacturing the SPIRS board

folder "board" contains the application that must be cross compiled and runned on the board

• lib folder has all the dependencies
• cfile.c is the application, it obtain the values from the puf, configure the network connection and connect to the socket created by the server and passes the files on the socket. to compile use${COMPILER} cfile.c -L./lib -lrotspirs -lm -o ${EXE} --static and then move the executable on keystone.

folder "bootrom" contains the modification necessary to the bootrom.

• "main.c" needs to be inserted in the bootrom project instead on the old "main.c"

folder "server" contains the data necessary to run the server on the pc

• all required certificates and keys
• the dependency archive "liball.c"
• the file "server.c" requires to be compiled with the library "liball.c" and is in charge of communicating with the board: configure the network, opens the socket, wait for the board data, creates certificate and additional data (sm and kernel signatures). requires to have the rootfs and fw_payload in the same folder. compiled with gcc -o server server.c -L. -lall. it creates the additional data that are required to flash in the SD.
• the script "flash.sh" flashes the values in the SD, creates the partitions and copies the rootfs, fwpayload and the additional data in the SD. requires to have them in the same folder.