SweRV is a family of RISC-V cores developed by Western Digital and open-sourced through CHIPS Alliance.

SweRV EH1 RISC-V Core TM is a high-performance embedded RISC-V processor core (RV32IMC).
SweRV EH2 RISC-V Core TM is based on EH1 and adds dual threaded capability.
SweRV EL2 RISC-V Core TM is a small, ultra-low-power core with moderate performance.

The RTL code of all SweRV cores is available free of charge on GitHub in the respective CHIPSAlliance repositories:

• EH1

• EH2

• EL2

Core SweRV Support Package (SSP) is a collection of RTL code, software, tools, documentation and other resources that are needed to implement designs for SweRV-based SoCs, test them and write software that will run on them.

SSP is maintained by Codasip who provides also professional long-term support for the SweRV Core family. SSP is delivered in the form of a Docker image to ensure portability across various platforms and reliable execution of the provided tools. Step-by-step instructions how to install and run SSP can be found in the chapter following the introduction. The initial download and start of the SSP Docker image is accomplished through a ssp script which is available in this repository.

If you need help, advice, or want to report a bug related to the Support Package or the SweRV cores, please refer to the respective CHIPS Alliance repository and check the existing issues. If none covers your concerns, feel free to open a new one.

Read changelog.md for short release notes.

Docker is a containerization tool that allows to execute programs in isolated environments. It uses OS-level virtualization to run specific system and application configuration in form of a container running on the host.

There are Docker management utilities allowing to start/stop containers, to save and reuse customized container image, etc.

The main terms related to Docker are:

• Docker container – an isolated Docker environment that can be perceived as a lightweight virtual machine. It is a running instance of Docker image. It has its own file system and processes executed in container that run in isolation from the rest of the host operating system.

• Docker image – a template used to create a Docker container.

Typical user’s requirements:

• Run "clasic" benchmarks (coremark,dhrystone,embench)

• Run own benchmarks

• Run own sw cases

• Run sw on ISS or FPGA

There are comprehensive guides on how to run specific benchmarks in pre-defined SSP environment, including the code. Similarly there are SW examples and pre-set SDK defaults allowing to write, build, run and debug software on SweRV Core, either using Instruction Set Simulator (ISS) or FPGA development board.

Working directories for storing user code and data may be kept on a shared NFS rather than inside of the SSP Docker container.

Typical user’s requirements:

• SoC examples using SweRV Core

• Run own RTL simulations using SweRV Core instance(s)

• Run own RTL synthesis using SweRV Core instance(s)

• Getting support in case of unexpected results or design problems

There are SweRV Core SoC application examples including a user guide describing how to use them. There is a set of tailored scripts allowing to build a SweRV-based SoC with peripherals, to synthesise and simulate it. The SSP part supporting free available tools is free of charge. Professional EDA tool integration with documentation and examples is available only as a part of the professional support service.

SSH access with X11 tunneling as well as using of shared NFS drives allow collaborative team work in one common or more individual containers.

Typical user’s requirements: * SoC examples using SweRV Core * Including own modified SweRV Core in SSP tool flow * (optional) Adding verification flow * Run own RTL simulations using own modified SweRV Core instance(s) * Run own RTL synthesis using own modified SweRV Core instance(s) * Getting support in case of extending/restricting the core functions

There are SweRV Core SoC application examples including a user guide describing how to use them, which may be used for the reference. There is a set of tailored scripts allowing to build a SweRV based SoC with peripherals, which may be used to build more complex SoCs. Professional support service provides help with adding a RISC-V extension (e.g. B,F etc) to existing cores.

SSH access with X11 tunneling as well as use of shared NFS drives allow for collaborative team work in one shared or mutliple individual containers.

97-Olimex-tiny-h.rules      # for ARM USB Tiny-H JTAG interface
99-nexys-a7.rules           # for Digilent Nexys A7 or Nexys4 DDR FPGA boards

$ cd ./usb-rules
$ sudo cp 97-Olimex-tiny-h.rules /etc/udev/rules.d
$ sudo cp 99-nexys-a7.rules      /etc/udev/rules.d
# reload and activate the rules without rebooting your machine
$ sudo udevadm control --reload-rules
$ sudo udevadm trigger

$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC
Bus 001 Device 005: ID 15ba:002a Olimex Ltd. ARM-USB-TINY-H JTAG interface
.
.
$ ls -l /dev/bus/usb/001/006
crw-rw-rw- 1 root root 189, 5 Oct 20 16:49 /dev/bus/usb/001/006
$ ls -l /dev/bus/usb/001/005
crw-rw-rw- 1 root plugdev 189, 4 Oct 20 15:56 /dev/bus/usb/001/005

$ sudo systemctl status docker
docker.service - Docker Application Container
Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled)
Active: active (running) since Thu 2020-09-17 09:25:07 CEST; 8h ago
.
.

$ sudo systemctl start docker

$ sudo groupadd docker
$ sudo usermod -aG docker <username>

$ docker images
REPOSITORY                                                 TAG                 IMAGE ID            CREATED             SIZE

$docker --help
$docker run --help       # run is used to start docker container
$docker ps --help        # ps is used to find which containers are running
$docker images --help    # images is used to see available local images
$docker image --help     # image may be used to remove desired image

$python3 --version
Python 3.6.8

$git clone https://github.com/Codasip/SweRV-Support-Package-free.git
$cd SweRV-Support-Package-free
# install SSP launcher to default python install dir tree
# if you prefer user based installation or do not have permissions to write to python3 installation tree, use --user option
$python3 -m pip install -r requirements.txt .
# or
$python3 -m pip install -r requirements.txt . --user

## for bash
$export PATH=$PATH:<YOUR_PYTHON3.6-INSTALL-ROOT>/bin
# or if installed using --user option
$export PATH=$PATH:/home/<YOUR_USERNAME>/.local/bin/
## for csh,tcsh
setenv PATH $PATH\:<YOUR_PYTHON3.6-INSTALL-ROOT>/bin
# or if installed using --user option
setenv PATH $PATH\:<YOUR_USERNAME>/.local/bin/

$ ssp --help
Usage: ssp [OPTIONS] COMMAND [ARGS]...

  Codasip Launcher for SSP.

Options:
  --help  Show this message and exit.

Commands:
  download
  run
  version

$ ssp run --help
Usage: ssp run [OPTIONS]

Options:
  -x, -X         Launches Docker in detached mode and connets to Docker via
                 ssh with xserver.

  -d, --dry-run  Only creates Dockerfile and builds Docker image.
  --skip-config  During cpm init, doesnt ask to configure each package and
                 skips all questions.

  --help         Show this message and exit.

There is a keyword users: denoting user definition section. Here you can define all users who will be using this customized SSP Docker container.

IMPORTANT You have to define at least your actual user name in ssp.yaml. Otherwise ssp run will exit with an error message that your user name is not on the list of user names. Remember ssp run starts at the end the customized SSP with your login name. Therefore the name in ssp.yaml and your login name must match.

name: denotes login name
uid: is user ID
gid: is primary group ID
groups: user’s group membership (e.g. dialout group to use USB interface)
shell: terminal shell selection (bash,sh,ksh,csh,tcsh)

NOTE:

• SSP setup uses by default .bashrc. In case you select another shell, you have to modify the respective rc file accordingly to initialize e.g. environment modules.

• ssp run starts SSP Docker container with user’s login. Therefore it is important to define all container users with their login names.

• It is recommended to use NFS drives for user work spaces within SSP Docker container. Therefore it is important that all users have their unique UID which is, if possible, identical with the UID available on hosts using the same NFS drive.

• ssp run creates user accounts with trivial passwords (identical to user names) in the customized Docker image. It is recommended for each user to change his/her password after the container starts.

• There is always default user sspuser (UID==1000,GID==1000) with default password sspuser in the base SSP Docker container.

• IMPORTANT Membership in a dial-out group is mandatory for users who want to access a FPGA board over USB as non-root users. Note that dial-out group is 18 on CentOS but 20 on Debian machines. Therefore it is a good idea to have both groups defined to cover different hostOS/SSP installations.

It is recomended to use network drive(s) for your design data. ssp.yaml allows to define disk drives and mount points in docker container as desired.

storage.mydomain.com:/eda disk in the example above will be mounted in customized ssp docker container on mountpoint /import/eda. Keyword drives: denotes the mount drives section.

In case it is desired to have symbolic links in customized ssp Docker container, these can be defined in ssp.yaml as follows:

seh1 symbolic link to /import/prj/seh1 directory will be created in /prj directory. symlinks: keyword denotes section dedicated for symbolic link definition. In case the section is empty or symlinks: keyword is missing, no symbolic links will be created in customized ssp Docker image.

SSP uses environment modules to set the environment variables and search paths to tool binaries. As SSP installation does not know which EDA or other supplementary tools are available on the host system, the information may be given in an interactive dialog during SSP initialization. The gained data are used to generate modulefile for each of the tools. The following environment variables may be used to bypass interactive dialog and automate SSP initialization process. Note that free tools do not need any MGEN__LICENSE_SERVER variable.

Back to 1. Step by Step SSP Installation Guide TOC.

If you have successfully completed all 3 previous steps, you can start ssp. You can either go to the SweRV Support Package Free directory where your customized ssp.yaml file already is, or you can set SSP_CONFIG_PATH environment variable to point to the directory containing your customized ssp.yaml and start ssp run in any of your work directories.

NOTE: The SSP configuration file name MUST BE ssp.yaml.

There are several options how to use ssp run. * ssp run –skip-config Use this run option to get the SSP console without any configured environment module for external EDA tools. In case of ssp free it is vivado, its installation is needed to run benchmarks and test examples in FPGA. You can configure environment modules within SSP later using cpm config command. * ssp run You get main Docker console access. SSP container will be closed by exiting the console. Note that the running container has no specific SSH port allowing SSH access from other hosts. Read <<26-connect-via-ssh[2.6. Connect via SSH] section for SSH terminal access. * ssp run -X You get terminal access to SSP container running in detached mode. Docker container will be not stopped when you exit the terminal. There is an explicit ssp port for ssh access from other hosts. If you use ssp run -X for the first time to build and run ssp, it may happen that you see message: ssh connection refused and you do not get your prompt in terminal window. Start the same command again to get the ssp prompt in terminal as expected. * ssp run –dry-run Docker file and Docker image will be created, but not started.

The following actions are executed during the first ssp run: * source SSP image is pulled from the repository and stored on local host * new Docker file is generated from ssp.yaml * new Docker image is generated using new Docker file * new Docker container is started with your user name identity

Depending of your filesystem, network access and your computer performance, it may take couple of minutes. SSP run using Docker image generated from the first run should be up within less than 1 second.

Back to 1. Step by Step SSP Installation Guide TOC.

$ docker images
REPOSITORY              TAG                    IMAGE ID            CREATED             SIZE
ssp-free-pva            latest                 b126298f8593        4 weeks ago         4.57GB
ssp-dev-group           3.0.3                  bd012f0dbb74        7 days ago          4.79GB

$ docker ps -a
  CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS            PORTS                   NAMES
60e4d14db476        ssp-free-pva          "/bin/sh -c 'sudo mo…"   2 minutes ago       Exited (0) About a minute ago               ssp_pva
8619a9bf168c        ssp-dev-group:3.0.3   "/bin/sh -c 'sudo mo…"   4 minutes ago       Up 4 minutes                                elated_cori
04fdc29b4aab        f73f33c844a1          "/bin/sh -c 'sudo mo…"   4 weeks ago         Up 4 weeks          0.0.0.0:32810->22/tcp   pv_ssp

$ docker stop 04fdc29b4aab
04fdc29b4aab

$ docker ps
  CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS              PORTS                   NAMES
8619a9bf168c        ssp-dev-group:3.0.3   "/bin/sh -c 'sudo mo…"   4 minutes ago       Up 4 minutes                                elated_cori

# Downloads and starts ssp-free in interactive terminal. When exited, no data is lost. Container can be started to continue with the work. This corresponds with "ssp run" script command.
$ docker run -it --privileged -p 22 --name ssp_my -h ssp_my ssp-docker-registry.codasip.com/distrib-ssp-seh1-free:latest

# Downloads and starts ssp-free in interactive terminal. When exited, the container is killed and volatile data lost.
$ docker run -it --rm --privileged -p 22 --name ssp_my -h ssp_my ssp-docker-registry.codasip.com/distrib-ssp-seh1-free:latest

# Downloads and starts ssp-free in background mode. You have to connect via `ssh` or to an interactive session using e.g. `docker exec -it <container id> /bin/bash` This is similar to "ssp run -X" script command.
$ docker run -d --privileged -p 22 --name ssp_my -h ssp_my ssp-docker-registry.codasip.com/distrib-ssp-seh1-free:latest

# get running container name
$ docker ps
  CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS              PORTS                   NAMES
60e4d14db476        ssp-free-pva          "/bin/sh -c 'sudo mo…"   About an hour ago   Up 56 minutes       0.0.0.0:32860->22/tcp   ssp_pva
8619a9bf168c        ssp-dev-group:3.0.3   "/bin/sh -c 'sudo mo…"   3 hours ago         Up 3 hours                                  elated_cori

# save image
$ docker commit  ssp_pva my_new_ssp_pva
sha256:40b18c1e4dbf92b79a75adf0639a81f2db516499d2ac791505228e2ff1b44b21

# check available images
$ docker images
REPOSITORY          TAG                    IMAGE ID            CREATED             SIZE
my_new_ssp_pva      latest                 40b18c1e4dbf        55 seconds ago      4.57GB
ssp-dev-group       3.0.3                  bd012f0dbb74        7 days ago          4.79GB

If you do not see any port when applying docker ps, you have to identify the IP address of the running container and then use it to connect.

If you see a port when applying docker ps, you can simply use localhost to connect to the container SSH port mapped to local host (see docker ps listing).

You can directly connect through the host that is running the Docker container. Note that the container must be started with -p 22 option to get SSH port mapping.

Back to 2 Using SSP with Docker client management tools

# to get container name or ID
$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                   NAMES
a49217a73fa8        56de7a1ed283        "/bin/sh -c 'sudo mo…"   18 hours ago        Up 18 hours         0.0.0.0:32772->22/tcp   ssp_305

# to open docker container shell console in your terminal
$ docker exec -it ssp_305 /bin/bash

# check which containers are stopped
$ docker ps -a --filter "status=exited"
CONTAINER ID        IMAGE            COMMAND                  CREATED             STATUS                      PORTS    NAMES
83163520d86f        15989fe1fa19     "/bin/sh -c 'sudo /u…"   2 months ago        Exited (137) 2 months ago            OPe_jtag_example

# start stopped docker and attach to it
$ docker start -a -i OPe_jtag_example
[sspuser@83163520d86f ~]$

# check which containers are stopped
$ docker ps -a --filter "status=exited"
CONTAINER ID        IMAGE            COMMAND                  CREATED             STATUS                      PORTS    NAMES
83163520d86f        15989fe1fa19     "/bin/sh -c 'sudo /u…"   2 months ago        Exited (137) 2 months ago            OPe_jtag_example

# remove exited docker
$ docker rm OPe_jtag_example
OPe_jtag_example

yourlogin@ssp_305 ssp]$ cpm --help
Usage: cpm [OPTIONS] COMMAND [ARGS]...

  Codasip Package Manager for SSP.

Options:
  --help  Show this message and exit.

Commands:
  add      Install one or more packages into SSP project.
  avail    Show all available packages or edalize tools.
  check    Check diff between installed pkg and original pkg.
  clean    Remove all installed packages.
  compose  Script for build of testing or production SSP Docker image.
  config   Configure package.
  init     Initialize SSP structure and install available packages.
  list     List currently installed packages.
  purge    Clear local package cache by removing .tgz files of package(s).
  remove   Uninstall one or more packages from SSP project.
  reset    Resets changes in installed packages to former state.
  version  Print CPM version.

 yourlogin@ssp_305 ssp]$  cpm list --help
 Usage: cpm list [OPTIONS]

  List currently installed packages.

Options:
  --old    Deprecated. Uses old method to list installed packages. Takes
           longer.

  --count  Displays number of installed packages.
  --help   Show this message and exit.

yourlogin@ssp_305 ssp]$  cpm list
eclipse-mcu-ide:2.3.2
espresso-logic:2.0.0
gnu-toolchain-config:2.0.1
infra-tools-doc:2.0.1
openocd:4.0.0
riscv-gnu-toolchain:2.0.1
seh1-verilator:2.0.1
seh1:2.2.1
seh2-verilator:2.0.2
seh2:1.0.0
sel2-verilator:2.0.1
sel2:1.2.0
swervolf-coremark:1.1.1
swervolf-demo-freertos:2.2.0
swervolf-demo-leds-uart:2.2.0
swervolf-dhrystone:1.1.1
swervolf-eh1-lib:1.1.3
swervolf-embench:2.1.0
swervolf:2.0.3
vivado-config:2.0.1
whisper-iss:3.0.0

yourlogin@ssp_305 ssp]$ module avail
---------------------------------------------------------------------------------- /prj/ssp/modules -----------------------------------
eclipse-mcu-ide         gnu-toolchain_7.3.1     openocd                 riscv-gnu-toolchain_9.2 vivado_2017.4           whisper-iss_1.549

yourlogin@ssp_305 ssp]$ riscv32-unknown-elf-gcc --version
bash: riscv32-unknown-elf-gcc: command not found

# use module to set the environment
yourlogin@ssp_305 ssp]$ module load riscv-gnu-toolchain_9.2
module riscv-gnu-toolchain: version: 9.2 host: ssp_305
# the tool is now available:
yourlogin@ssp_305 ssp]$ riscv32-unknown-elf-gcc --version
riscv32-unknown-elf-gcc (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# add whisper
yourlogin@ssp_305 ssp]$ module load whisper-iss_1.549
module whisper-iss: version: 1.549 host: ssp_305
yourlogin@ssp_305 ssp]$ whisper --version
Version 1.549 compiled on Aug  5 2020 at 11:53:04
No program file specified.

yourlogin@ssp_305 ssp]$ module --help
  Modules Release 3.2.10 2012-12-21 (Copyright GNU GPL v2 1991):

  Usage: module [ switches ] [ subcommand ] [subcommand-args ]

Switches:
    -H|--help       this usage info
    -V|--version        modules version & configuration options
    -f|--force      force active dependency resolution
    -t|--terse      terse    format avail and list format
    -l|--long       long     format avail and list format
    -h|--human      readable format avail and list format
    -v|--verbose        enable  verbose messages
    -s|--silent     disable verbose messages
    -c|--create     create caches for avail and apropos
    -i|--icase      case insensitive
    -u|--userlvl <lvl>  set user level to (nov[ice],exp[ert],adv[anced])
  Available SubCommands and Args:
    + add|load      modulefile [modulefile ...]
    + rm|unload     modulefile [modulefile ...]
    + switch|swap       [modulefile1] modulefile2
    + display|show      modulefile [modulefile ...]
    + avail         [modulefile [modulefile ...]]
    + use [-a|--append] dir [dir ...]
    + unuse         dir [dir ...]
    + update
    + refresh
    + purge
    + list
    + clear
    + help          [modulefile [modulefile ...]]
    + whatis        [modulefile [modulefile ...]]
    + apropos|keyword   string
    + initadd       modulefile [modulefile ...]
    + initprepend       modulefile [modulefile ...]
    + initrm        modulefile [modulefile ...]
    + initswitch        modulefile1 modulefile2
    + initlist
    + initclear

If you have started SSP using ssp run --skip-config, you will need to configure modules manually. First you need to know which packages are available for configuration as described in 3.1. Check cpm and packages section. Note that you have to have -config:<version> to be able to configure it.

IMPORTANT If you have already included Vivado specific environment variables in ssp.yaml and started using ssp run, your Vivado module will be already configured after the Docker container start. For more details about the SSP environment variables see SSP specific environment variables for EDA tool support] section

Back to 3. First steps within running SSP

yourlogin@ssp_305 ssp]$ cd /prj/ssp
yourlogin@ssp_305 ssp]$ ls
common  config  doc  infrastructure  ip  modules  package.json  soc  sw  tool

yourlogin@ssp_305 ssp]$ cd /prj/ssp/doc
yourlogin@ssp_305 ssp]$ ls
eclipse-mcu-ide.pdf      seh1.pdf                              seh1_SweRV core roadmap white paper.pdf  seh2-verilator.pdf             swervolf.pdf
espresso-logic.pdf       seh1_README.md                        seh1-verilator.pdf                       sel2_README.md                 swervolf-software-demos.pdf
openocd.pdf              seh1_RISC-V_SweRV_EH1_PRM.pdf         seh2_README.md                           sel2_RISC-V_SweRV_EL2_PRM.pdf  whisper-iss.pdf

yourlogin@ssp_305 ssp]$ evince swervolf-software-demos.pdf

yourlogin@ssp_305 ssp]$ cd /prj/ssp
yourlogin@ssp_305 ssp]$ chmod g+w *

As of 1.1, loader requires both curl and jq packages to be installed in order to work correctly. 1. Centos7:
* sudo yum -y update
* sudo yum -y install epel-release
* sudo yum -y install curl jq

1. Ubuntu 14+/Debian:

   • sudo apt-get update
     

   • sudo apt-get -y install curl jq

2. Fedora:

   • sudo dnf update
     

   • sudo dnf install curl jq

In case you will be running SSP on your local computer and root permissions are available, no further configuration of Docker is necessary.

However, if you want to make your Docker host available on your network, you will need to modify the Docker daemon service configuration:

1. Open the service configuration file /lib/systemd/system/docker.service.

2. Find the key ExecStart.

3. Add argument:

   • --host 0.0.0.0:2376 for encrypted communication using TLS, or

   • --host 0.0.0.0:2375 for un-encrypted communication (not recommended).

4. Save the configuration file and restart the Docker service.

Now, all clients wanting to use this machine as a Docker Host must define the environmental variable DOCKER_HOST so Docker can connect to the specified host. For example, if the host’s hostname is dockerhost and it was configured to use TLS communication, the clients would need to run:

$ export DOCKER_HOST=dockerhost:2376

One can also specify host’s IP address instead of hostname.

Running GUI applications directly in the SSP terminal is not possible as Docker container does not have any display attached. However, GUI applications can be run using the combination of SSH and X server. To enable X server within SSH connection, you need to pass the -X argument to the ssh command:

$ ssh -X -p <forwarded_port> sspuser@localhost

After connecting to SSP this way, you can open any graphical application and it will use the Window System of your host.

There are multiple reasons why the SSH connection is not working properly:

1. Your firewall is blocking the connection. Try to check your firewall settings.

2. SSP container does not have the TCP port 22 forwarded from the container to the host. To forward the port, please see the <<connect-via-ssh[Connect via SSH] section in this README.

3. The port you used for the forwarding on the host may already be used by another service. Use nmap, ss or a similar utility to see the ports that are already in use.

4. There is another SSP container running on your host with the same port specified.

5. SSH daemon is not running in the SSP container. Run the command ps aux | grep sshd to check if the daemon is running. If you cannot see the daemon running, you can start it manually by executing $ /usr/sbin/sshd -D &. The reason why it is not started may be that you have overridden the startup command of the SSP container.

Yes! Docker is prepared for these situations. There are three options how to share your SSP workspace with others.

The first option is to connect to the SSP container via SSH, so all the changes you make will be immediately available to other people connected to the same container. This option is best for sharing you workspace with colleagues.

The second way is to connect to the running container via docker command. However this is only possible if other people have access to the host where the Docker container is running. You will need to provide them with the name of the running container that you want to share. Specifying the Docker container name is described in the Starting SSP section. Then all they need to do is to run this command:

$ docker exec -it <container_name> /bin/bash

The third option is to export your SSP container and send it to people you want to share it with, and they import it on their side. Note that when using this approach, they will only see the changes you made to SSP before the export. To export the container, run the following commands:

This exports the SSP container to the <destination> you specify. Then you can send the generated file to anyone you choose to share the SSP content; all they need to do on their side is:

$ docker load --input <destination>

To mount a network drive, you will need to install drivers for the filesystem which is used on your network drive. SSP Docker already supports NFS network drives. However, to be able to mount these drives, you will need to leverage the Docker privileges, as by default the SSP container is isolated from the outer environment. To leverage the privileges, you need to start the SSP container by adding the --privileged argument to the docker run command. ssp run scripts starts docker container with --privileged argument automatically.

Unfortunately, SSP Docker cannot run services as it does not have access to D-Bus. Any daemons you want running in the SSP must be started manually. Or you can initiate daemons start withind dockerfile while building your custom SSP docker image.