Installing OpenCPI on Development Hosts

The basic installation on (Linux) development host systems enables the development and execution of OpenCPI components and applications on the development host itself (called native execution). It also establishes the host platform for the tools that enable development for other target platforms, including embedded CPUs, real or simulated FPGAs, and GPUs. The installation process takes these steps, in three phases:

Phase 1: Hardware and OS installation (only for installing Rocky from scratch)

  1. Installing the hardware or creating a bare virtual machine.

  2. Installing and configuring the operating system from CD or CD image file.

  3. Updating the operating system to the latest patch level and enabling “sudo”.

    At this this point we have a basic up-to-date OS installation. There are many ways to get here, but we outline a basic approach that works on Rocky9. If your system is already installed, this phase is skipped.

Phase 2: Download OpenCPI sources, and install prerequisite software packages.

  1. Install the git software package, and use it to download the OpenCPI source distribution.

  2. Install standard required packages using the package update and installation tools of the operating system distribution.

  3. Install and build some prerequisite packages that need special OpenCPI-supplied installation scripts.

    At this point, we have installed all prerequisites and have a clone/copy of the OpenCPI code tree ready to build on the OS installation.

Phase 3: Build and test OpenCPI

  1. Build OpenCPI’s core tools, libraries, components and example applications.

  2. Execute some tests to verify that the installation is working.

These steps result in a development system with tools and runtime software ready to support development and native execution (on the development system) of OpenCPI components and applications. Steps 5 through 8 are done with a single command:

./scripts/install-opencpi.sh

This installation process is based on source code that is downloaded and built on the development host.

The Preparing the Hardware and OS for OpenCPI Development topic describes Phase 1 in detail. The Download OpenCPI using git, Installing Required Standard Software Packages for OpenCPI, and Installing Prerequisite Packages for OpenCPI topics describe Phase 2. The Building the OpenCPI Framework and its Built-in Projects and Testing the Software Aspects of the Installation topics describe Phase 3 in detail. For other target systems and platforms, see the sections on FPGA simulators, embedded systems and FPGA platforms.

Preparing the Hardware and OS for OpenCPI Development

The quick description of this OS installation section is: install the development host OS, including the “git” software and enable your user ID for “sudo”.

This step is only necessary if you are installing the OS from scratch. If your OS is already installed and up to date, your account is already sudo-enabled, and the git command is available on your system, you can skip to the Installing OpenCPI from Source topic.

To just deal with the sudo and git issues on an installed OS, skip to the topic: Enabling Your User for “sudo” and Installing “git”.

Since a development host has no special hardware requirements, it must simply support the recommended and supported development host operating system (e.g. Rocky9 64-bit). Some development tools (especially those for FPGAs) require large memories and exploit multiple CPU cores and thus the minimum memory should be at least 8GB, with 16GB or more preferred. For test purposes, VMs with 2GB have been successful, but slow.

If the development host system will also host other embedded CPU or FPGA cards acting as OpenCPI target platforms, the appropriate slots, cooling and power supplies should be considered.

If the development host will also be the runtime host for Ethernet-attached devices (such as the Ettus N310), it is sometimes useful to use dedicated Ethernet ports for such devices. In this case, a host system with multiple Ethernet ports/interfaces should be considered. This minimizes interference between Ethernet traffic to the locally-attached platforms, and general LAN or WAN/internet traffic.

OpenCPI development is commonly hosted on laptops, server machines with card slots, and virtual machines hosted on other operating systems. One example system is a Rocky9 64-bit virtual machine running under the “VMWare Workstation” virtual machine system on Microsoft Windows laptop. Another is a Dell server with well-powered PCI Express slots for hosting a number of FPGA and/or GPU boards.

Obtaining the CD Image File for the OS Installation

The normal operating system installation starts with a CD image downloaded for the development host OS. For Rocky9, this is from rockylinux.org (or one of its mirrors). An example of a “minimal” Rocky9 installation is described here. Many installation scenarios are possible.

For a physical system, you can create a bootable USB flash drive, and then boot from that USB device. For a virtual machine, you can usually designate that the CD/DVD image file be mounted to the virtual machine as a virtual CD/DVD device.

Creating a virtual machine usually involves answering a few questions about the to-be-created VM, and then booting it from the Installation CD/DVD image file. For most VM systems, the most import questions to answer are the amount of memory to give to the VM, and the number of cores to provide. Each VM system does it slightly differently.

Booting the development host system from the USB flash drive or CD image file proceeds the same whether it is a physical system or a VM.

For the case of using the VMWare Workstation system on Windows, we select “customize settings before installation”, and set memory at 4GB and 2 cores/CPUs.

The CD image for the minimal Rocky9 installation is available from mirrors at:

The actual file name to download is:

Rocky-9.5-x86_64-minimal.iso

This installation is suitable for command-line only (no GUI) headless systems, and booting from the CD (image) immediately runs the installer. Other Rocky9 installation images are available with more packages preinstalled on the image.

Booting from and Running the Installation CD/Image

When using Rocky9 with minimal CD image boots, it immediately runs an installer that asks for things like language and root password. It is better not to create users at this point, but to simply run the installer instead. When the installed system boots, it is in command line (shell) mode. At this point, you must at least enable the network interface, if not done during the installer, using the nmtui tool (the default network interface is eth0), and then update your system using the command:

# yum update

To ensure that you are up to date, you must reboot (using the reboot command) after yum update, and then, after the reboot, run yum update again, and repeat this process until “Dependencies resolved. Nothing to do.” is displayed.

On the command line you can add users, using the simple adduser command. An example would be:

# adduser -m -N -r -u 501 -g 20 user1

You only need to specify the user and group ids if you are trying to match them to an existing installation for convenient NFS mounting. Otherwise you can simply use:

# adduser -m user1

This would use default behavior to create the account and home directory.

Enabling Your User for “sudo” and Installing “git”

A number of scripts supplied by OpenCPI require that the user be enabled for the “sudo” command. You should add your user account to the list of accounts that are allowed to use “sudo”. On the Rocky9 minimal installation, you are already at the command line. With <RootPasswd> and <User> being replaced by your root password and your user name, do:

% su
Password: <RootPasswd>
# echo <User> ALL = ALL >> /etc/sudoers
# exit
%

The “% ” and “# ” are just command prompts: you don’t type them. Be careful to use the two “>>” characters to append the line to the file. Of course if you are experienced with Linux, you may do this many other ways.

OpenCPI has several software prerequisites, but only one of them is required to be installed before the OpenCPI code base is installed: git. The git program is used to download a local copy of the code base, and after that, a script in the code base is used to finish the installation of OpenCPI. To obtain git, the following command should be issued at the command prompt in the terminal window:

% sudo yum -y install git

This ensures that you have the git package installed on your system so that you can use the git command. Git is the distributed revision control system used by OpenCPI. We will only use a few git features and commands for installation.

Summary of Installation Steps Prior to Installing OpenCPI

  • Download the development host OS CD image file, and check the md5 digest.

  • For physical systems, burn a CD from that file.

  • Boot the physical or VM system from the CD or CD image file.

  • Run the OS installer using the “Install to HardDrive” icon and answer questions. Note: be sure to select manual partitioning so that you can allocate most of the disk space to the root (/) partition.

  • Boot your newly installed system and answer more questions.

  • Upgrade the software repeatedly until there are no more updates available.

  • Enable your user ID for the sudo command.

  • Install the git configuration management software.

Note

You now have an installed, up-to-date operating system, with a user account that is sudo-enabled and the git software configuration management package is available.

Installing OpenCPI from Source

We assume you are in a shell window, in the directory where the codebase should go, into a subdirectory, which the following commands will create.

The source installation procedure downloads, builds and uses the software in a directory of the user’s choosing (for example, ~/opencpi). As a result, multiple versions can be downloaded and coexist, but not execute simultaneously.

OpenCPI source installations make no global changes to the user’s system other than:

  • Installing or updating some required standard packages using the yum install or equivalent command.

  • Dynamically/temporarily loading and using the OpenCPI kernel driver in order to test it.

Both these steps require sudo privileges.

Download OpenCPI using git

To download OpenCPI via cloning the entire OpenCPI code base with history, issue the following command:

git clone https://gitlab.com/opencpi/opencpi.git

The above command creates an opencpi subdirectory and populates it with the current OpenCPI code base: i.e., a “git clone” of the code base that can be easily updated in the future. Change into the created subdirectory.

cd opencpi

By default, the git clone operation downloads the “latest stable” release (called the master branch). This may or may not be what you want. After downloading, if you want a specific, perhaps earlier release, you use the git tag command to list the tagged releases available, then set the code base to the one you want, using git checkout, with the release tag (as listed by git tag) as an argument.

The OpenCPI source code releases are tagged with the following format:

v<major>.<minor>.<patch>

For example, a recent release was:

v2.4.8

List the available tagged releases with the command:

git tag

Check out the tagged release you want with the command:

git checkout <release-tag>

Whenever you check out a different tag after any building activity, or want to return this tree to its downloaded and checked-out state, you can perform a clean operation on the code base:

% make cleaneverything

Now you can install, build and test OpenCPI.

Summary of Steps to Prepare the OpenCPI Code Base using git

% git clone https://gitlab.com/opencpi/opencpi.git
% cd opencpi
% git tag
% git checkout v2.4.8 # use tag from git tag output

Note

You now have an OpenCPI source tree configured for a specific tagged version of OpenCPI.

Install, Build and Test OpenCPI

After performing the above steps to obtain the code base (using git clone and cd to the opencpi subdirectory), you are in the top-level directory of the source distribution. At this point, you can use one command to perform the rest of the installation, including running some tests to ensure that the installation is working. This command is:

./scripts/install-opencpi.sh

This command may take a while to complete and will require you to provide the sudo password twice for the two global actions described earlier. It is not recommended nor supported to perform the whole installation under sudo or as root.

If you are not present to provide the password, it may fail, but it can be rerun.

It will require internet access to download and build software it needs. Occasionally some download sites are unavailable and the command must be repeated when they are available.

The testing done by this script only executes software-based components and applications. After this command completes and succeeds, OpenCPI is ready for use on the development host for OpenCPI software components and applications. At this point you can take the next installation step by installing an FPGA simulator.

After running the install-opencpi.sh script:

Note

You now have an OpenCPI installation built and tested, ready to be used. This does not include FPGA tools, code, or bitstreams, or support for embedded systems, which are separate installation steps.

The last step before actually using OpenCPI is to establish the OpenCPI environment using:

source <where-is-opencpi>/cdk/opencpi-setup.sh -s

A user may wish to put this command in their ~/.bash_profile (after any PATH settings) if every shell/terminal window should automatically have the OpenCPI environment established. The string <where-is-opencpi> is the directory where OpenCPI is installed. This is explained further in the OpenCPI User Guide. Since in this case we are actually in the OpenCPI source installation directory, we can simply do:

source cdk/opencpi-setup.sh -s

Details of the Installation Process for Troubleshooting

The following description is for the curious or when the above install-opencpi.sh script fails. If it succeeds, the rest of this section is just a detailed description of what the script does. This script performs these functions, in order, with each depending on the previous ones:

  1. Install standard packages required for OpenCPI development, globally on the system, from the OS’s repository. This is accomplished using the underlying install-packages.sh script described below. Important examples of such required packages are make and python. For Rocky or Redhat Linux, this script uses the yum install command.

  2. Build and/or install prerequisite packages for OpenCPI, in an area only used by this installation of OpenCPI (i.e. sandboxed). This will compile these packages as necessary for the development host. The install-prerequisites.sh script performs this function and is described below. This usually involves downloading source tarballs for the package and building them.

  3. Build the OpenCPI framework (libraries and executables) itself. This step and the following one are accomplished using the build-opencpi.sh script described below.

  4. Build the built-in projects that are part of the OpenCPI source distribution, for all software assets (RCC workers and ACI applications).

  5. Run a number of tests to verify the installation. This step uses the ocpitest command.

These underlying steps can be run individually for troubleshooting purposes, but are otherwise unnecessary. The rest of this section describes them in more detail, but can be skipped if the install-opencpi.sh script succeeds.

Installing Required Standard Software Packages for OpenCPI

This step (#1 above) uses the underlying script:

scripts/install-packages.sh

Most OS distributions are associated with an internet-based repository of software packages, and have a way to install packages from that repository. For Redhat and Rocky Linux systems, the yum command is used to access software packages in the repository for that OS. Most embedded/cross-compiled OSs do not have such a repository, but might. When this yum/rpm type of package is installed on your system, it is globally visible and usable and is not removed when the OpenCPI directory you created for the installation is removed. In this way, this script simply adds standard software to your system if it is not already there.

Since different OSs use different package management systems, this script uses the appropriate commands for the OS you are running on and adds the packages required for OpenCPI development.

Since installing packages on to your system typically requires sudo privileges, a password prompt usually happens when this script is run. Do not run the command using sudo directly.

Installing Prerequisite Packages for OpenCPI

This step (#2 above) uses the script:

scripts/install-prerequisites.sh [-f]

We use the term prerequisite to mean software required by OpenCPI framework software or its built-in projects that must be compiled specifically for OpenCPI for all software platforms whether cross-compiled or not. These are built and used specifically for OpenCPI, in directories inside the OpenCPI installation’s file hierarchy and are thus not used nor visible to other software on the system.

When this script is used for a cross-compiled platform, it first ensures that the prerequisites are also installed for the development system you are running on. It also checks whether the targeted software platform has any platform-specific prerequisites (such as a cross-compiler not otherwise needed), and builds/installs those before installing the generic prerequisites required for all software platforms.

This script checks for a timestamp indicating that all the prerequisites for a platform have been built/installed and does not do it again unless the force option (-f) is specified. It also recognizes when the download for each prerequisite has been done before and does not re-download software, even if the force option (-f) causes it to be built/installed again.

Prerequisites are usually downloaded from the internet based on URLs for each prerequisite. If your organization does not allow this (or is not connected to the internet), and has a staging server or file share for vetted downloads, the following environment variables can be used to redirect the download process to an alternative local server or file share instead of the server indicated by the internet URL associated with the prerequisite.

OCPI_PREREQUISITES_LOCAL_SERVER replaces the host part of the URLs, and assumes that all the prerequisite downloads will be found at that server.

OCPI_PREREQUISITES_LOCAL_PATHNAME replaces the host part of the URL with a local directory path.

If you set both, both will be tried.

Building the OpenCPI Framework and its Built-in Projects

This step (#3 and #4 above) uses the script:

scripts/build-opencpi.sh

This building script will build:

  • The core software infrastructure libraries, and utility command executables.

  • The OpenCPI Linux kernel/device driver

  • The software components in libraries in the built-in projects.

  • Some example applications in the built-in projects.

This script first builds the OpenCPI framework executables, libraries and drivers, and then builds the software aspects of the built-in projects for the targeted software platform. It does not do any HDL (FPGA) building in the built-in projects since that depends on what FPGA tools may be available, and is thus done separately after this development host OpenCPI installation.

Testing the Software Aspects of the Installation

This step (#5 above) uses the script:

scripts/test-opencpi.sh

A variety of tests are run. One is to test loading the kernel driver, which requires sudo privileges and typically prompts for a password. The last message displayed by the test script should be like this:

All tests passed: driver os datatype load-plugins container assets swig python project ocpidev core

Installing FPGA Simulation Platforms

For OpenCPI to be used as a heterogeneous development framework for FPGAs, it is necessary to install one or more FPGA simulators. This is highly recommended and is a requirement for most of the tutorials for learning OpenCPI. OpenCPI considers an FPGA simulator as “just another FPGA platform”. This is done separate from any setup necessary for actual FPGA hardware platforms. Setting up an FPGA simulator for use as an OpenCPI platform usually consists of:

  1. Installing the simulation software according to the FPGA tool vendor’s instructions, which in some cases requires a purchased license.

  2. Perhaps setting some simulator-specific environment variables in the <where-opencpi-is-installed>/user-env.sh file (normally unnecessary).

  3. Building the built-in projects for the simulation platform using the script (this can take 10-15 minutes):

Installing an OpenCPI Platform

ocpiadmin install platform

Prepare the OpenCPI installation for using the specified RCC or HDL platform.

Usage:

$ ocpiadmin install platform [OPTIONS] Platform

Arguments:

  • Platform: [required]

Options:

  • --install-target / --no-install-target: Whether to also install the platform’s HDL target. [default: install-target]

  • -w, --workers: Whether to build workers for the installation target.

  • -t, --tests: Whether to build unit tests for the installation target.

  • -a, --assemblies: Whether to build assemblies for the installation target.

  • -r, --artifacts-only: Whether to clean intermediate build files.

  • -s, --streamline-build: Whether to skip checkpoints when building assemblies.

  • -o, --optimize: For RCC platforms only. Install platform and workers with optimization enabled.

  • -j, --n-jobs INTEGER: Max number of parallel builds [default: 1]

  • -p, --package-id TEXT: Package ID of platform/target to install.

  • -u, --project-url TEXT: URL to the platform/target’s project.

  • -g, --git-revision TEXT: Git revision to checkout before installation.

  • --report-format [junit]: Format of report(s). [default: junit]

  • --report-path FILE: Path of file to write report(s) to.

  • --builder [make]: Specify the Builder to use to run the asset(s). [default: make]

  • --help: Show this message and exit.

OpenCPI currently supports the following third-party FPGA simulators:

  • xsim, which comes with the AMD Vitus™ Unified Software Platform tool set. The AMD Vitis for Simulation and for Small, Recent FPGA Parts topic in this guide provides instructions on how to download and install the free, unlicensed variant of this simulator and its tool set.

  • modelsim, offered by Mentor, a Siemens business. The Installing Modelsim topic in this guide provides more information about how to set up this simulator.

  • isim, which comes with the Xilinx ISE® Design Suite tool set.

Installing AMD Vitis™ version of xsim is the recommended first step for all installations. The modelsim simulator is considerably faster, but also is expensive.

Preparing a Development Host to Support Embedded Systems

There are several optional setup tasks on development hosts to prepare using attached embedded systems. The two “attachments” are serial consoles and NFS mounts. Most embedded systems boot from SD cards, and the development host typically needs a drive for writing such cards.

Attaching Serial Port Consoles of Embedded Systems to Development Hosts

When embedded systems have serial consoles, it is common and helpful to attach them to the development systems so that console input and output are in a window on the development system. In the common case where this connection is actually a USB cable that is emulating a serial port, this requires that the development host be prepared to recognize these USB connections as serial ports.

On most systems this recognition is automatic, so when the cable is plugged in, there is a Linux/UNIX tty device dynamically created in the /dev directory. Thus a terminal emulator application can be directed to connect this tty device and its window will be a console for the embedded system. Two problems arise from this situation:

  • The name of the tty device is arbitrary and unpredictable, and if there is more than one attached embedded system, it is hard to know which is which.

  • The permissions of the device are commonly set to read-only.

Using udev Rules Files on Linux

Linux has files that help with the auto-recognition process (called udev rules files), which can fix the naming and permission problems as long as there is only one USB-based serial cable with the vendor and part of that embedded system. Each supported OpenCPI embedded system with a USB serial console port and cable provides one of these files that can be symbolically linked into the system directory where such files live, namely:

/etc/udev/rules.d

So for OpenCPI hardware platform <pf>, you would issue this command to tell the system how to connect it to the development system:

sudo ln -s $OCPI_CDK_DIR/<pf>/udev_rules/.rules /etc/udev/rules.d

Of course this modifies the development host system outside of this OpenCPI installation and could potentially conflict with other installations or software packages. These udev rules files that are specific to a given platform usually result in the tty device with the name:

/dev/tty<pf>_0

that can be provided to the terminal emulator application.

The udev rules files are typically examined by the system at boot time, and if the symbolic links created above point to file systems that are not mounted early in the boot process, you may need to tell the system to re-examine the udev rules files later. This is done using the command:

sudo udevadm control --reload

Using Console tty Ports without udev Rules

If there is no udev rules file for a platform or there are multiple platforms of the same type with console serial cables, the tty device can be determined manually by looking in the /dev directory and seeing which devices appear when the cable is plugged in. Then to fix the permission problem you need to issue the following command every time the cable is plugged in or the embedded system is reset or the development host is reset:

sudo chmod 666 /dev/<new-tty-device-appearing-when-cable-plugged-in>

Using a Terminal Emulator Program to Access the Console Port

The most common terminal emulator application on Linux systems is screen, where the command to run that application with a window connected to that serial port would be:

screen /dev/<tty-device-name> <baudrate>

Where <baudrate> is the speed of the serial port.

For Emacs users, you can use the serial terminal emulator built in to Emacs, by simply doing: M-x serial-term in a window, and providing the /dev/tty<xxx> name and baud rate when prompted. There are two modes in this window, char and line. The default is char mode, where every character typed is immediately sent without any interpretation at all. This means no Emacs keyboard commands work in that Emacs window and you have to use the mouse to switch to another Emacs window. The line mode is more line buffered, like Emacs shell mode, and all line editing and other Emacs commands work fine. But the display can get confused in this line mode so you have sometimes switch back and forth: control-c control-j switches to line mode, control-c control-k switches to char mode, and control-c control-c sends a control C in char mode.

With a good terminal emulator connection, hit return a few times in the serial console window to see the console prompt, or, if the system was previously logged in and running, you might already see the prompt.

Sometimes if the screen or terminal emulator is confused, or if, after hitting “return”, the prompt stays on the same line, try typing the command “clear”, to clear the state of the terminal emulator.

Enabling the Development Host to be an NFS Server for the Embedded System

It is frequently useful to be able to mount and access the file systems on the development system where the OpenCPI codebase is built and cross-built. This requires that the development system be enabled as a file server, and any associated firewall issues are addressed between the embedded system and the development host. This configuration typically uses nfs, with the embedded system acting as an nfs client and the development system acting as the nfs server.

The NFS server needs to be enabled on the development host in order to run the embedded systems in Network Mode. If Network Mode is not being used, it is not necessary. The following instructions have been tested for Ubuntu22_04 and Rocky9. Many development systems are already enabled as NFS servers, but not all.

Install NFS server tools for your development host.

Ubuntu:

% sudo apt install nfs-kernel-server

Rocky9:

% sudo dnf install nfs-utils -y

From the host, allow NFS past SELinux 1:

% sudo setsebool -P nfs_export_all_rw 1
% sudo setsebool -P use_nfs_home_dirs 1

From the host, allow NFS past the firewall:

% sudo firewall-cmd --permanent --zone=public --add-service=nfs
% sudo firewall-cmd --permanent --zone=public --add-port=2049/udp
% sudo firewall-cmd --permanent --zone=public --add-service=mountd
% sudo firewall-cmd --permanent --zone=public --add-service=rpc-bind
% sudo firewall-cmd --reload

Define the export(s) by creating a new file in the /etc/exports.d directory,

/etc/exports.d/user_ocpi.exports

It must have the extension .exports, otherwise, it will be ignored.

Add the following line to that file and replace XX.XX.XX.XX/MM with a valid netmask for the DHCP range that the SDR will be set to for your network, e.g. 192.168.0.0/16. This should be as “tight” as possible for security reasons. Do not share out your top-level directory! This would allow theft of your private ssh keys, etc!

<opencpi> XX.XX.XX.XX/MM(rw,sync,no_root_squash,crossmnt)

Where <opencpi> is your OpenCPI installation (git repo). Any other projects or files outside that installation would require additional, separate exported mount points.

In the below example, the opencpi directory is available to only 10.100.1.1, while the my_project directory is available to all IPs in the range 10.100.1.X

/home/user/opencpi/ 10.100.1.1(rw,sync,no_root_squash,crossmnt)
/home/user/my_project/ 10.100.1.0/24(rw,sync,no_root_squash,crossmnt)

If the file system that you are mounting is XFS, then each mount needs to have a unique fsid defined. Instead, use:

<opencpi> XX.XX.XX.XX/MM(rw,sync,no_root_squash)

After creating this file, run these commands to have the changes take effect:

Ubuntu:

% sudo systemctl enable --now rpcbind
% sudo systemctl enable --now nfs-server

Rocky9:

% sudo systemctl enable --now rpcbind
% sudo systemctl enable --now nfs-server
% sudo systemctl enable --now nfs-lock
% sudo systemctl enable --now nfs-idmap

Some of the enable commands may fail based on your system configuration, but usually does not cause any problems.

Using SD Card Reader/Writer Devices

SD card reader/writer devices are required when the embedded systems use such cards and it is required to make changes to them. Reading an SD card is sometimes necessary to “patch” it to add new files while leaving some of its contents and formatting untouched. Most such devices are pluggable USB devices.

The first step when using an SD card is to discover its device name, which is usually something like /dev/sdb or /dev/mmcblk0. After inserting a card, the following command usually has output that identifies the device name:

dmesg | tail -n 15

To make a backup copy of a card, into a file called backup.image, use this command:

dd if=<device-name> of=backup.image

To write the image file back onto an SD card, use:

dd of=<device-name> if=backup.image

To actually use or change the contents of file systems on an SD card, it must be mounted such that its partitions are accessible as file systems. In most cases the file systems on an SD card are automatically mounted upon insertion, and the mount point (root directory of the partition’s file system) can be discovered using the df -h command that lists mounted file systems and their capacities.

If the desired partition is not automatically mounted, you must 1) discover the device’s name (as above), 2) the partition’s name, 3) possibly create a mount point, and 4) mount it. Search the internet for “how to mount an SD card” for many approaches to this on many systems.

Information about preparing SD cards for enabling embedded systems for OpenCPI is in the Preparing the SD Card Contents topic.

1

You can use getsebool to see if these values are already set before attempting to set them. Some security tools may interpret the change attempt as a system attack.