Skip to content

Flashing images on Qualcomm Snapdragon Ride SX 4 (QAM8775P/QAM8650P)

Obtain prebuilt or custom AutoSD images to flash onto your Qualcomm Snapdragon Ride SX4 (QAM8775P/QAM8650P) development board.

Obtain images

To flash AutoSD onto your Qualcomm development board, you need the following images:

aboot.img / boot_a.simg
An Android boot image containing the automotive kernel, the initial RAM file system (initramfs), Device Tree Blob (DTB), and the kernel command line. The boot loader reads the image to start the kernel. Flash aboot.img / boot_a.simg to both the boot_a and boot_b partitions. Because there is no way to predict from which partition newly provisioned boards will boot, flashing both boot partitions ensures a trouble-free boot.
rootfs.simg / system_a.simg
A sparse disk image that grows in size as required to accommodate data without storing empty space. rootfs.simg / system_a.simg contains the root file system partition with files installed from RPM packages and files generated for configuration purposes. Flash rootfs.simg / system_a.simg to the system_a partition.
qm_var.simg / system_b.simg

An optional sparse disk image for the quality-managed (QM) partition, a containerized environment at /usr/lib/qm/rootfs that isolates non-critical applications from the rest of the system and provides persistent, mutable storage at /var/qm.

A separate QM partition image is generated only when both the qm section and a separate QM data partition with a non-zero size or relative_size are configured under image.partitions.var_qm in the manifest. Without a dedicated partition size, QM data resides within the root file system (rootfs.simg / system_a.simg), so Automotive Image Builder does not produce a separate image.

Most prebuilt nightly images include a separate QM partition, so you must build a custom image without a qm section if you do not want QM, or omit the image.partitions.var_qm section if you want QM data embedded in the root file system instead. If your image has a separate QM partition, you must flash qm_var.simg / system_b.simg to the system_b partition to avoid boot errors.

vbmeta_a.simg / vbmeta_b.simg

Verified Boot Metadata (vbmeta) images ensure the bootloader only runs signed code when using Android Verified Boot (AVB) 2.0. The Qualcomm Android Boot Loader (ABL) reads these images to verify the integrity of the boot partitions before loading the kernel.

Prebuilt nightly images do not include a separate vbmeta file because the vbmeta placeholder is embedded in the disk image.

If you build a custom image and use the --separate-partitions option, Automotive Image Builder generates a placeholder vbmeta_a image that is sufficient for development boards with AVB disabled. You can flash it, but the board can boot without it. Depending on your manifest, the disk image might also contain a placeholder for a vbmeta_b partition. Automotive Image Builder leaves vbmeta_b empty by default, so the --separate-partitions option skips it and does not produce vbmeta_b.simg unless it contains data after you sign both slots with avbtool.

For production use with AVB enabled, you must sign the boot image and generate real vbmeta images by using avbtool. Flash vbmeta_a.simg to the vbmeta_a partition. Flash vbmeta_b.simg to the vbmeta_b partition.

You can obtain these images by using one of the following methods:

Qualcomm image targets and firmware

You must use a prebuilt nightly image or a custom image target that is compatible with your board and its firmware. Mismatches between your image and board cause flash and boot failures.

The following table lists the available Ride SX 4 image targets:

Target SoC Firmware Kernel Description
ride4_sa8775p_sx_legacy SA8775P ES13 kernel-automotive Legacy kernel, standard firmware, Rev 1 hardware with a patch kit, Rev 2, or Rev 2.5 hardware
ride4_sa8775p_sx_legacy_r3 SA8775P ES13 kernel-automotive Legacy kernel, Rev 3 hardware
ride4_sa8775p_sx SA8775P ES21 kernel-ivos-qualcomm System Control and Management Interface (SCMI)-enabled firmware, Rev 1 hardware with a patch kit, Rev 2, or Rev 2.5 hardware
ride4_sa8775p_sx_r3 SA8775P ES21 kernel-ivos-qualcomm SCMI-enabled firmware, Rev 3 hardware
ride4_sa8650p_sx_r3 SA8650P CS4 kernel-ivos-qualcomm SCMI-enabled firmware, Rev 3 SoC

Download a prebuilt Ride SX 4 nightly image

Download and uncompress a prebuilt nightly AutoSD image for Ride SX 4.

Each directory contains aboot.img.xz, rootfs.simg.xz, and qm_var.simg.xz files.

  1. List the available images:

    $ curl -s 'https://autosd.sig.centos.org/AutoSD-10/nightly/RideSX4/?C=M;O=D' | sed -n \
's|.*href="\(auto-osbuild-ride4[^"]*\)/".*|\1|p'

  2. Set latest to the name of the image you want to download:

    $ latest="<image_name>"

    where:

    • <image_name> is the directory name of the prebuilt nightly image, for example:
      • auto-osbuild-ride4_sa8650p_sx_r3-autosd10-qa-regular-aarch64-2357423933.c69ef138.aboot

  3. Download the images from the Automotive SIG nightly builds repository:

    $ wget -P "$latest" \
"https://download.autosd.sig.centos.org/AutoSD-10/nightly/RideSX4/$latest/aboot.img.xz" \
"https://download.autosd.sig.centos.org/AutoSD-10/nightly/RideSX4/$latest/rootfs.simg.xz" \
"https://download.autosd.sig.centos.org/AutoSD-10/nightly/RideSX4/$latest/qm_var.simg.xz"

  4. Uncompress the aboot.img.xz, rootfs.simg.xz, and qm_var.simg.xz files:

    $ xz -d "$latest/aboot.img.xz" "$latest/rootfs.simg.xz" "$latest/qm_var.simg.xz"

Next step

Flash the images onto your Ride SX 4 board.

Build a custom Ride SX 4 image

To build a custom AutoSD image, use Automotive Image Builder, which is available in the automotive-image-builder repository.

Prerequisites

Procedure

  1. Create the build container:

    $ aib build-builder --distro autosd10

  2. Build the AutoSD bootc container image and disk image files:

    $ aib build \
      --distro autosd10 \
      --target <ride4_variant> \
      --separate-partitions \
      --format simg \
      <path>/<manifest>.aib.yml \
      <container_name> \
      <output_directory>

    where:

    • <ride4_variant> is the ride4 target that is compatible with your board.
    • --separate-partitions is the flag that creates per-partition image files: boot_a.simg, system_a.simg, vbmeta_a.simg, and system_b.simg if you configured a separate QM data partition in your manifest. Without this flag Automotive Image Builder generates a single disk image. Automotive Image Builder does not build an image for a partition unless it contains data.
    • <path>/<manifest> is the path to your manifest file, for example:
      • demos/minimal-qm/minimal_qm.aib.yml
    • <container_name> is the name of your AutoSD bootc container image, not to be confused with the Automotive Image Builder build container, for example:
      • localhost/autosd-ride4_sa8775p_sx_r3:latest
    • <output_directory> is the name of the disk image output directory that stores the per-partition image files, for example:
      • autosd-ride4_sa8775p_sx_r3-minimal-qm

Next step

Flash the images onto your Ride SX 4 board.

Flash image

Flash the AutoSD images onto your board.

Support documentation for your board and firmware is available on the Qualcomm Createpoint portal. You must register for a Qualcomm ID to log in to this portal.

Prerequisites

  • A Qualcomm Snapdragon Ride SX 4 (QAM8775P/QAM8650P) development system
  • A USB cable
  • android-tools
  • A prebuilt or custom AutoSD image built for a Ride SX 4 target

Procedure

  1. Connect a USB cable from your workstation to the USB0 port on the board.

  2. From the workstation, identify the System on Chip (SoC) serial console device.

    $ R4SX_TTY="/dev/$(basename $(readlink /dev/serial/by-id/usb-FTDI_Qualcomm_AIR_8775_*-if01-port0))"

  3. From the workstation, use a TTY application to connect to the SoC device, and log in as the root user.

    The board’s Future Technology Devices International (FTDI) USB adapter exposes four serial ports as /dev/ttyUSB<x>:

        | Port | Interface | Console |
    | ---- | --------- | ------- |
    | `/dev/ttyUSB0` | `if00-port0` | Unused |
    | `/dev/ttyUSB1` | `if01-port0` | Main OS (Linux) |
    | `/dev/ttyUSB2` | `if02-port0` | TrustZone |
    | `/dev/ttyUSB3` | `if03-port0` | Safety Island (SAIL) |

    Note

    The workstation in this step must be connected to the SoC device through USB. The workstation must be configured to use fastboot.

  4. From the workstation, connect to the SoC serial console at 115200 baud, 8N1. For example, using picocom:

    $ picocom -baud 115200 "$R4SX_TTY"

  5. Reboot the SoC device and quickly press and hold the down arrow key until you see boot messages on the terminal window.

  6. From the workstation, verify that the SoC device is in a fastboot state:

    # fastboot devices
c2b86509    fastboot

    Note

    The command returns an ID that confirms the device is ready to flash. In this example, the ID is c2b86509.

  7. Flash the partitions with the images:

    # fastboot flash boot_a <boot_image_name>
# fastboot flash boot_b <boot_image_name>
# fastboot flash system_a <root_image_name>
# fastboot flash system_b <qm_image_name>

    where:

    • <boot_image_name> is aboot.img for a prebuilt AutoSD image or boot_a.simg for a custom AutoSD image.
    • <root_image_name> is rootfs.simg for a prebuilt AutoSD image or system_a.simg for a custom AutoSD image.
    • <qm_image_name> is qm_var.simg for a prebuilt AutoSD image or system_b.simg for a custom AutoSD image with a separate QM data partition configured in the manifest. Flash system_b only if your image includes a separate QM data partition. Most prebuilt nightly images include one; if yours does, you must flash it to avoid boot failures. If no separate QM partition is configured, QM data is embedded in the root file system and you can skip this command.

    Note

    If you have vbmeta_a.simg or vbmeta_.simg, you do not need to flash it until you want to sign your image for production, at which point you can run these additional commands:

    # fastboot flash vbmeta_a vbmeta_a.simg
# fastboot flash vbmeta_b vbmeta_b.simg

  8. Continue to boot the SoC device:

    # fastboot continue

    Note

    If fastboot continue does not work, perform a complete power cycle: power off the board, wait a few seconds, then power it back on.

  9. Log in to the operating system (OS) using root as the user ID and password as the password.

Additional resources

© Red Hat