Linaro Releases

The Linaro Qualcomm Landing Team is pleased to announce the new release of the Linaro Linux release for Qualcomm™ Snapdragon® 410 processor. The Linaro Linux release 20.02 is a Debian-based Linaro Build that provides developers with a desktop like environment using Debian and the LXQt desktop, as well as a console-only image.

What’s new in this release

• Major kernel upgrade to Linux kernel 5.4.17.
• MESA upgrade to 19.1.8.

Important note(s) about this release

A firmware/bootloader upgrade is required for this release, you must ensure you are using the most recent firmware version. If you install using the SD card method, then the bootloaders are flashed automatically, if you install with the fastboot images, then you need to install the latest bootloader package.

Known issues

For a list of all known issues, please check our Bugzilla

Features

The Linaro Linux version 20.02 for the Snapdragon 410 supports the following features:

• Provides a working Debian environment with access to Debian repositories (apt-get) and updates. It is based on Debian 10.0 (aka buster).
• It is based on Linux kernel 5.4.17.
• It is based on proprietary firmware available on Qualcomm Developer Network or 96boards.org.
• The following images are released:
  • boot image that includes prebuilt kernel and initrd
  • developer image that includes core packages as well as typical development packages (headless)
  • alip image that includes a minimal desktop environment GUI using LXQt
• All images have a pre-configured user called linaro, and the password for this user is set to linaro
• The root file system should be flashed in the onboard eMMC.
• The following features are supported on the DragonBoard 410c:
  • Quad Core ARMv8 A53 CPU (@1.0GHz)
  • PSCI with support for cpuidle, SMP, hotplug and restart.
  • Adreno 306 GPU, powered by freedreno Mesa/Gallium GPU driver, version 19.1.8
    • OpenGL 3.1, OpenGLES 3.0, GLX, EGL
    • X11 -modesetting video driver
  • Cpufreq, using ondemand governor by default
  • CPU thermal sensors, and thermal management using the step wise governor
  • HDMI display and audio using the onboard ADV7533 MIPI/DSI Receiver with HDMI Transmitter from Analog Devices
  • UART, SD, eMMC
  • USB2.0 (Mouse, Keyboard, Storage, Ethernet)
  • Wifi and Bluetooth using integrated WCN3620, using proprietary firmware and wcn36xx driver
  • Hardware accelerated video codecs using dedicated Snapdragon coprocessor
  • Onboard GPS using Qualcomm GNSS subsystem
  • CSI interface with external ISP only, sample driver included for OV5640, with support for the following features:
    • CSI0 and/or CSI1 on the high speed expansion connector
    • streaming from the camera sensor or CSID test generator
    • raw dump to memory: 8bit packed UYVY format from OV5640 and resolutions of 2592×1944, 1920×1080 or 1280×960
    • format conversion from 8bit packed UYVY to NV12
    • input image downscaling (up to 16x)
    • input image cropping

Information about the DragonBoard 410c

For more information about the DragonBoard 410c, please check the following website and wiki:

• http://www.96boards.org/dragonboard410c
• http://www.96boards.org/dragonboard410c/documentation
• http://www.96boards.org/dragonboard410c/gettingstarted
• https://www.96boards.org/documentation/consumer
• https://developer.qualcomm.com/hardware/dragonboard-410c

How to install and use this release

To install this release please follow the instructions from the DragonBoard 410c installation guide.

Proprietary firmware

This release contains proprietary firmware. You can download the proprietary firmware separately, from here. All the required firmware files are pre-installed, and our images are bound to the Qualcomm Linux BSP license agreement. A copy of the LICENSE can be found in the image as /etc/QCOM-LINUX-BOARD-SUPPORT-LICENSE.

WLAN and BT MAC addresses

There is no dedicated flash memory on the board to store persistent data such as WLAN and BT MAC addresses. A solution is being designed to store them in an eMMC partition, so that reel MAC addresses can be used across reboots. This solution will be implemented in an upcoming release. For the time being, the MAC addresses are computed in the bootloader (in LK), such that:

• they are different from each other
• they are pseudo random, but unique for each board
• they are persistent across reboot (e.g. they are always the same)
• they are set in LK and dynamically added to the device tree blob (DTB) so that they are available to the kernel

The WLAN and BT drivers will read the MAC addresses set by the bootloader into the DTB, and configure the hardware accordingly.

Running the ALIP Desktop image

The ALIP/LXQt image is expected to provide a desktop-like experience, as such it is recommended to use an HDMI monitor, as well as USB keyboard and mouse. The default image will directly boot to the login screen by default. However a root console login will also be started on the serial console.

Note: The default bootargs enable the kernel messages to be displayed on the serial console.

Running the Developer based image

If you have flashed the developer image, when booting the board you will end up in a root login on the serial console. If you have an HDMI monitor connected, you will also have login terminals on the display

Running the Developer image from SD card

It is possible boot the system completely from SD card. There are instructions to create an bootable SD Card available here. A sample image for SD card is also included in the release. The sample image includes the same developer image (described above), but unlike the default image which is meant to be flashed into on board eMMC, the SD card image must be flashed onto an empty SD card on your PC. Then it will boot entirely from SD card on the Dragonboard 410c. The image file is dragonboard410c_sdcard_developer_debian-<BUILD-NUMBER>.zip. To setup the SD card using the sample image, please follow the instructions available here.

How to get and customize the kernel source code

Building the Linux kernel from source

The Linux kernel used in this release is available via tags in the Linaro Qualcomm Landing Team git repository:

git: http://git.linaro.org/landing-teams/working/qualcomm/kernel.git
tag: debian-qcom-dragonboard410c-20.02
defconfig: arch/arm64/defconfig kernel/configs/distro.config

The kernel image (Image.gz) is located in the boot image and partition and the kernel modules are installed in the root file system. It is possible for a user to rebuild the kernel and run a custom kernel image instead of the released kernel. You can build the kernel using any recent GCC release using the git tree, tag and defconfig mentioned above. This release only supports booting with device tree, as such both the device tree blobs need to be built as well.

The DragonBoard 410c is an ARMv8 platform, and the kernel is compiled for the Aarch64 target. Even though it is possible to build natively, on the target board, It is recommended to build the Linux kernel on a PC development host. In which case you need to install a cross compiler for the ARM architecture. It is recommended to download the Linaro GCC cross compiler.

To build the Linux kernel, you can use the following instructions:

git clone -n http://git.linaro.org/landing-teams/working/qualcomm/kernel.git
cd kernel
git checkout -b kernel-20.02 debian-qcom-dragonboard410c-20.02
export ARCH=arm64
export CROSS_COMPILE=<path to your GCC cross compiler>/aarch64-linux-gnu-
make defconfig distro.config
make -j4 Image.gz dtbs KERNELRELEASE=5.4.0-qcomlt-arm64

Additionally, you might want or need to compile the kernel modules:

make -j4 modules KERNELRELEASE=5.4.0-qcomlt-arm64

The kernel modules need to be put in the root file system, under /lib/modules folder. To export the built modules, please run:

make modules_install KERNELRELEASE=5.4.0-qcomlt-arm64 INSTALL_MOD_STRIP=1 INSTALL_MOD_PATH=<folder>

You will then need to transfer the content of <folder> onto the target root file system.

Building a boot image

You now need to create a valid boot image with your own kernel build.

The boot image consists of the kernel image, appended with the proper device tree blob (Image.gz) and an init ramdisk image. We used to include a device tree table generated with a custom tool (@dtbTool) but it is no longer needed, assuming you are running the most recent bootloader package. A new feature was implemented in the bootloader to allow using an unmodified device tree blob to be appended to the compressed kernel image.

cat arch/arm64/boot/Image.gz arch/arm64/boot/dts/qcom/apq8016-sbc.dtb > Image.gz+dtb

To create the boot image, you also need a ramdisk image, and you can use the one from the release:

wget http://releases.linaro.org/96boards/dragonboard410c/linaro/debian/20.02/initrd.img-5.4.0-qcomlt-arm64 -O initrd.img

The tool mkbootimg is a standalone application that will process all files and create the boot image that can then be booted on the target board, or flash into the on-board eMMC. On Debian/Ubuntu systems, mkbootimg can be installed with:

sudo apt install android-tools-mkbootimg

The boot image also contains the kernel bootargs, which can be changed as needed in the next command:

mkbootimg --kernel Image.gz+dtb \
              --ramdisk initrd.img \
              --output boot-db410c.img \
              --pagesize 2048 \
              --base 0x80000000 \
              --cmdline "root=PARTLABEL=rootfs console=ttyMSM0,115200n8"

Booting a custom boot image

Assuming you have now built a valid boot image called boot-db410c.img, you can run the following fastboot command to boot it on the board:

sudo fastboot boot boot-db410c.img

If you want to permanently use a custom kernel image, you can update the boot image and reflash it into the boot partition:

sudo fastboot flash boot boot-db410c.img

How to get and customize the bootloader

While the first stage bootloader is proprietary and released as firmware blob available on Qualcomm Developer Network or 96boards.org, the second stage bootloader is LK and is open source.

The original LK source code is available on CodeAurora.org, and the source code which is used in this release can be found in the Linaro Qualcomm Landing Team git repository:

git: http://git.linaro.org/landing-teams/working/qualcomm/lk.git
tag: dragonboard410c-LA.BR.1.2.7-03810-8x16.0-linaro3

Since release 17.04, the first stage bootloader expects the second stage bootloader to include a signature. The signature is typically used for secure boot. On Dragonboard 410c, since no private keys are available, the signature is not checked for integrity however the signature section, even if empty, must exist. To build the LK bootloader and add the signature section, you can use the following instructions:

git clone git://codeaurora.org/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8.git -b LA.BR.1.1.3.c4-01000-8x16.0
git clone http://git.linaro.org/landing-teams/working/qualcomm/lk.git -b dragonboard410c-LA.BR.1.2.7-03810-8x16.0-linaro3
git clone https://git.linaro.org/landing-teams/working/qualcomm/signlk.git
cd lk
make -j4 msm8916 EMMC_BOOT=1 TOOLCHAIN_PREFIX=<path to arm-eabi-4.8 tree>/bin/arm-eabi-
mv ./build-msm8916/emmc_appsboot.mbn ./build-msm8916/emmc_appsboot_unsigned.mbn
../signlk/signlk.sh -i=./build-msm8916/emmc_appsboot_unsigned.mbn -o=./build-msm8916/emmc_appsboot.mbn -d

The second stage bootloader is flashed on the aboot partition, you can now flash your board with:

sudo fastboot flash aboot ./build-msm8916/emmc_appsboot.mbn

How to get and customize Debian/Ubuntu packages source code

This release is based on Debian 10.0 (aka buster), and it is not possible to use a different Debian release (e.g. it is not possible to downgrade to an older Debian release, nor is it possible to use a newer release, such as the one being currently developed).

Since all packages installed in Linaro Debian-based images are maintained either in Debian archives or in Linaro repositories, it is possible for users to update their environment with commands such as:

sudo apt-get update
sudo apt-get upgrade

All user space software is packaged using Ubuntu or Debian packaging process. As such you can find extensive information about using, patching and building packages in the Ubuntu packaging guide or The Debian New Maintainers Guide. If you quickly want to rebuild any package, you can run the following commands to fetch the package source code and install all build dependencies:

sudo apt-get update
sudo apt-get build-dep <pkg>
apt-get source <pkg>

Then you can rebuild the package locally with:

cd <pkg-version>
dpkg-buildpackage -b -us -uc

Notes:

• you can drop patches in debian/patches/ and update debian/patches/series before building with dpkg-buildpackage to customize the source code.
• all associated .deb files will be located in the root folder, and can be installed in the system with dpkg -i .deb.
• all these commands should be executed on the target directly, not on the development host. It is generally enough to build packages natively, on the target platform. For some packages, it is possible to cross compile Ubuntu/Debian packages however this goes beyond the scope of this wiki page.

Using the onboard GPS

The GPS software stack mostly runs on the DSP subsystem. The communication between the main CPU and the DSP is done with a specific IPC driver called QRTR (see ./net/qrtr/ in the kernel source tree). The DSP is started automatically at boot, any gpsd client can be started and will be able to retrieve GPS data.

Please note that the sensitivity of the onboard antenna is quite low, so getting a FIX will take several minutes. Please refer to the dedicated application note to install an external antenna for better GPS performance.

You first need to initialize gpsd and register the custom protocol used by Qualcomm GNSS:

sudo systemctl start gpsd
sudo /usr/sbin/gpsdctl add pds://any

From now on, you can use any gpsd client, such as gpsmon, cgps or xgps.

cgps

or

gpsmon

Using CSI camera

For detailed information about using CSI camera, please refer to this page.

Important changes in release 20.02:

• The CPU is working at (@1.0GHz) because of the lack of support for QCOM CPR in 5.4.17.

Important changes in release 18.01:

• An incorrect handling of the i2c address in the CCI driver is fixed. For any new camera sensor driver the i2c address in DT must be the 7bit i2c address (without read/write bit). For any present camera sensor this equals a right shift by one of the i2c address in DT (e.g. for OV5645 i2c address is changed from 0×76 to 0×3b).

Important changes in release 17.09:

• The CAMSS driver now calculates the settle count value (based on the CSI2 Ths-settle parameter). This is done using the CSI2 pixel clock frequency reported by the CSI2 transmitter driver (camera sensor driver). The CSI2 transmitter driver must support the V4L2 control V4L2_CID_PIXEL_RATE otherwise the CAMSS driver will refuse to continue;
• The CAMSS driver now does not keep in sync the pixel format on the video device nodes and the media bus format on the VFE subdev nodes. The userspace must take care to set compatible format and frame size.
• The CCI driver is replaced by a new i2c adapter driver.

Video record pipeline

It is possible to create a video recording GStreamer pipeline involving the camera and video encoder.

Configure the pipeline:

sudo media-ctl -d /dev/media0 -l '"msm_csiphy0":1->"msm_csid0":0[1],"msm_csid0":1->"msm_ispif0":0[1],"msm_ispif0":1->"msm_vfe0_pix":0[1]'
sudo media-ctl -d /dev/media0 -V '"ov5645 4-003b":0[fmt:UYVY8_2X8/1280x960 field:none],"msm_csiphy0":0[fmt:UYVY8_2X8/1280x960 field:none],"msm_csid0":0[fmt:UYVY8_2X8/1280x960 field:none],"msm_ispif0":0[fmt:UYVY8_2X8/1280x960 field:none],"msm_vfe0_pix":0[fmt:UYVY8_2X8/1280x960 field:none],"msm_vfe0_pix":1[fmt:UYVY8_1_5X8/1280x960 field:none]'

And do video recording:

gst-launch-1.0 -e v4l2src device=/dev/video3 ! video/x-raw,format=NV12,width=1280,height=960 ! v4l2h264enc extra-controls="controls,h264_profile=4,video_bitrate=2000000;" ! h264parse ! mp4mux ! filesink location=video.mp4

When using the above command make sure that video device node numbers are correct or check and use the correct ones:

• examine the output of media-ctl -d /dev/media0 -p and check that /dev/video3 is connected to msm_vfe0_pix

Optimized video pipeline

In order to exercise a fully optimized video pipeline some specific settings need to be applied throughout the pipeline elements. With the fully optimized video use case there is no extra buffer copy, and the various drivers involved are sharing all video buffers using dmabuf.

To exercise the opimized video pipeline, you can use for example the following gstreamer command:

GST_GL_PLATFORM=egl gst-launch-1.0 filesrc location=<path to file> ! qtdemux name=m m.video_0 ! h264parse ! v4l2h264dec capture-io-mode=dmabuf ! glimagesink

FFmpeg support

As of FFmpeg 3.4, support for v4l2 hardware assisted codecs was added. As a consequence, FFmpeg can now use the Venus codecs, using the v4l2 APIs. FFmpeg is not included by default in the Linaro images, however FFmpeg 3.4.1 (at least) is available from Debian archives:

sudo apt install ffmpeg

Here is a sample command line that would decode a video file using hardware acceleration on Dragonboard 410c:

ffplay -sync video -an -autoexit -vcodec h264_v4l2m2m -i <an h264 video clip>

Audio configuration settings

The release has support for both analog and digital audio (HDMI). When using the ALIP desktop image, to switch back and forth you can use PulseAudio volume control application, and in the configuration tab, you will be able to chose which profile to use. Note that by default, PulseAudio will use the analog output, and you need to switch to HDMI at first boot if your HDMI monitor supports HDMI audio.

Feedback and Support

For general question or support request, please go to 96boards.org Community forum.

For any bug related to this release, please submit issues to the 96Board.org Bug tracking system. To submit a bug, follow this link.

Bugs will be reviewed and prioritized by the team. For any bug report it is recommended to provide as much information as possible, and at the very list please include the name of the release you are using, the output of dpkg -l to list all packages installed, as well, as the boot log (output of dmesg).

How to contribute

We very much encourage developers to use and contribute to our releases, using the following instructions.

---

Qualcomm Snapdragon is product of Qualcomm Technologies, Inc.