Skip to content
This repository has been archived by the owner on Apr 27, 2023. It is now read-only.

Toolchain

Jump to bottom
Daniel Page edited this page Mar 2, 2021 · 7 revisions

The XCrypto tool-chain is captured as a patch set against the official RISC-V repositories, namely for

There are two approaches:

  • use a native tool-chain, which requires you to build and install the tool-chain yourself, or
  • use a containerised tool-chain, removing that requirement and allowing quick(er) experimentation with XCrypto without the associated barrier to entry.

Using a native tool-chain

  • Building and installing the tool-chain is a 2-step process:

    • clone: for each component,

      1. clone the official RISC-V component repository,
      2. checkout a known-good commit, on a branch named scarv/xcrypto/v${REPO_VERSION}, relative to which the associated patch can then be applied.

    • build: for each component,

      1. patch the cloned component repository,
      2. configure the component,
      3. build and install the component.

  • Various types of script help to automate said process, and development of the XCrypto tool-chain more generally.
    For each component denoted by ${COMPONENT},

    • ${REPO_HOME}/src/toolchain/${COMPONENT}-apply.sh applies the patch to the component repository,

    • ${REPO_HOME}/src/toolchain/${COMPONENT}-revert.sh reverts the patch, i.e., resets the component repository to an initial, known-good state,

    • ${REPO_HOME}/src/toolchain/${COMPONENT}-update.sh updates the patch with staged modifications to the component repository,

    • ${REPO_HOME}/src/toolchain/${COMPONENT}-conf.sh configure the component,

    • ${REPO_HOME}/src/toolchain/${COMPONENT}-build.sh builds then installs the component into ${RISCV}, which defaults to ${REPO_HOME}/build/toolchain/install.

    In addition, the script ${REPO_HOME}/src/toolchain/share.sh captures various global configuration; for example, the tool-chain will be build for an architecture captured by TARGET_ARCH, ARCH_STRING, and ABI_STRING.

  • Based on the above, there are two options:

    1. higher-level, more automated:

      • clone:

        make -f ${REPO_HOME}/src/toolchain/Makefile clone

      • build:

        make -f ${REPO_HOME}/src/toolchain/Makefile build

    2. lower-level, less automated:

    • clone:

      ${REPO_HOME}/src/toolchain/clone.sh

    • build:

      • binutils:

        ${REPO_HOME}/src/toolchain/binutils-apply.sh
${REPO_HOME}/src/toolchain/binutils-conf.sh
${REPO_HOME}/src/toolchain/binutils-build.sh

      • gcc:

        ${REPO_HOME}/src/toolchain/gcc-apply.sh
${REPO_HOME}/src/toolchain/gcc-conf.sh
${REPO_HOME}/src/toolchain/gcc-build.sh

      • newlib:

        ${REPO_HOME}/src/toolchain/newlib-apply.sh
${REPO_HOME}/src/toolchain/newlib-conf.sh
${REPO_HOME}/src/toolchain/newlib-build.sh

      • pk (the spike proxy kernel):

        ${REPO_HOME}/src/toolchain/pk-apply.sh
${REPO_HOME}/src/toolchain/pk-conf.sh
${REPO_HOME}/src/toolchain/pk-build.sh

      • spike:

        ${REPO_HOME}/src/toolchain/spike-apply.sh
${REPO_HOME}/src/toolchain/spike-conf.sh
${REPO_HOME}/src/toolchain/spike-build.sh

  • To implement a change to the XCrypto tool-chain, the patch set must be updated. Doing so follows a fairly strict process: if the change is to a component denoted by ${COMPONENT},

    • perform a fresh clone of the component repository,
    • apply the existing patch to the cloned component repository,
    • implement the change in the cloned component repository,
    • stage the change via git add, but do not commit it, in the cloned component repository,
    • execute ${REPO_HOME}/src/toolchain/${COMPONENT}-update.sh to produce an updated patch,
    • optionally commit and push the updated patch.

Using a containerised tool-chain

  • ${REPO_HOME}/src/docker contains material related to a Docker-based, XCrypto container: it supports containerised use of make, by providing an environment in which the tool-chain (e.g., XCrypto-enabled riscv32-unknown-elf-gcc and spike) has been pre-built and installed.

  • An example of this approach is supplied in ${REPO_HOME}/src/helloworld which relates to a simple "hello world" program; the associated build system is in ${REPO_HOME}/src/helloworld/Makefile.

  • The idea is that for any target X in the Makefile, one could also use X-docker. For example, executing

    make all-docker

    will

    • mount the current working directory, i.e., ${REPO_HOME}/src/helloworld as /mnt/scarv/xcrypto within the container, then
    • execute make all in /mnt/scarv/xcrypto within the container, as a user whose UID and GID match ${USER},

    and, as such, do the same as executing

    make all

    except using the containerised tool-chain.

Clone this wiki locally