Introduction

This Quickstart guide describes the tools and provides the know-how to install and work with the Linux Board Support Package (BSP) for the phyCORE-STM32MP15x Alpha Kit. This guide shows you how to do everything including installing the appropriate tools and sources, building custom kernels, and deploying the OS in order to operate the software and hardware.

This kit is currently in Alpha Status. There are several topics to keep in mind while working with this kit and guide:

• The phyCORE-STM32MP15x will go through several functional changes during the Alpha Stage of development. Due to this, this Quickstart guide may change without any prior notice.
• The phyCORE-STM32MP15x has some functionality that is not currently operational. Please be aware of this when working with the Alpha Kit.
• This Quickstart guide is only for booting and starting the basic functionality of the phyCORE-STM32MP15x. This guide does not qualify as a Hardware manual for the phyCORE-STM32MP15x. The following manuals will be available in future releases of the phyCORE-STM32MP15x:

* Hardware Manual - provides a detailed description of all components and functions of the phyCORE-STM32MP15x and carrier board
* Yocto Reference Manual - provides information on Yocto, which is used with most PHYTEC products
* Board Support Package (BSP) Manual - provides detailed instructions on running the tools which are used to build various software
* Development Environment Guide - provides instructions to prepare and start the programs Eclipse and QT Creator, as well as setting up a Linux host system

• For more information or details regarding the phyCORE-STM32MP15x, please contact the PHYTEC Sales department.

phyCORE-STM32MP15x development KIT architecture

Requirements

The following components and system requirements are necessary to successfully complete this Quickstart. Deviations from these requirements are possible but may require workarounds.

Hardware and Equipment

Equipment already installed when receiving the KIT

• phyCORE-STM32MP15x (PCM-068) plugged onto carrier board (PCM-939)
• uSD Card inserted into X14 carrier board connector
• 2x5 header to DB-sub 9 male inserted on X36 carrier board connector (CAN)
• 2x5 header to DB-sub 9 male on X35 carrier board connector (RS232/RS485)

Additional Equipment not included in the KIT

• Additional Serial null modem cable (RS-232)
• Display HDMI interface Add-on Kit (PEB-AV-01)
• Display Parallel Add-on Kit (PEB-AV-02 with 7''capacitive screen)

Connecting the phyCORE-STM32MP15x Carrier Board

There are a few manual connections that you will need to make before using the phyCORE-STM32MP15x carrier board.

Carrier Board - Connectors

Carrier Board - Buttons, LED, and Jumpers

Connecting the USB Debug

For the following steps, a console connection via USB connection is required. You can use the included USB Cable.

Connect your PC's USB port with the micro USB connector of the carrier board (X13). Two COM-Ports will show up.

1. UART4 is the default debug UART (Cortex-A7)
2. UART7 is an additional debug UART (Cortex-M4)

When the Debug USB Cable is not plugged in, UART4 and UART7 are available on the Expansion Connector (X33).

UART7 can be forced to be exclusively available on X33 putting a jumper on JP16.

Connecting to the Ethernet (optional)

Connect the Ethernet cable to the Ethernet port on the carrier board (X47). Connect the other end to a suitable Ethernet source, as the development host will need to communicate with the phyCORE-STM32MP15x.

Connecting the RS-232 or RS-485 (optional)

RS-232 or RS-485 interfaces are available on X35 connectors (with 2x5 header to DB-sub 9 male cable plugged on it).

Both interfaces are connected to the USART3 of the CPU. RS232 is the default interface but RS-485 can be used instead by changing the jumpers JP4 and JP5 to position 2+3.

Connecting the FDCAN (optional)

CAN FD (CAN with Flexible Data-Rate) interface is available at X36 connector (with 2x5 header to DB-sub 9 male cable plugged on it).

CAN devices can be connected direclty to this connector. This interface is connected to the FDCAN1 of the CPU.

Powering the Board

Connect the power adapter to the Power-In component (X9).

phyCORE-STM32MP15x Carrier Board Power Schematic

Software

• A modern Linux operating host system either natively or via a virtual machine.
• Ubuntu 16.04 LTS 64-bit recommended. Other distributions will likely work but note that some setup information, as well as OS-specific commands and paths, may differ.
• VMWare Workstation, VMWare Player, and VirtualBox are possible solutions if you want to use a virtual machine.
• Root access to your Linux host PC. Some commands in this guide will not work if you do not have sudo access (e.g. package installation, formatting an SD card).
• At least 8GB of RAM (16GB or more is recommended)
• At least 100 GB of free space on the build partition of the host PC.
• An SD card reader operational under Linux.
• An active internet connection.

For more details concerning Linux PC configuration, please refer to : https://wiki.st.com/stm32mpu/wiki/PC_prerequisites

Getting Started with the Included SD Card

This section is designed to get the board up and running with the SD Card included in the kit, which has been prepared with pre-built images.

Booting from the SD Card

This section describes how to boot the KIT with the pre-built images on the included SD card.

• Insert the micro SD card into the SD card slot of the board.
• Check that the S7 DIP switch is in the default position (boot from SD) : POS1=> OFF, POS2 => ON, POS3 => OFF
• Plug the USB debug between the board and your PC Host. You should see two new devices appear : /dev/ttyUSB0 and /devttyUSB1. Linux terminal  will be accessible on /dev/ttyUSB0. 
• Start your favorite terminal software (e.g. Minicom or Tera Term) on your host PC and configure it for 115200 baud, 8 data bits, no parity, and 1 stop bit (8n1) with no handshake.
• Example to launch minicom on /dev/ttyUSB0 :

host:~$sudo minicom -D /dev/ttyUSB0 

• Connect the power supply to the power connector (please note the polarity shown in the picture phyCORE-STM32MP15x Carrier Board Power Schematic).

The RGB LED D11 will begin blinking in BLUE as the board begins booting into Linux. The console output can be viewed in your terminal window. If everything was done correctly, the login prompt will be shown at the end of the booting process:

ST OpenSTLinux - Weston - (A Yocto Project Based Distro) 2.6-snapshot phycore-stm32mp1-1 ttySTM0
phycore-stm32mp1-1 login: root (automatic login)
root@phycore-stm32mp1-1:~#

Log in is done automatically as root (no password is required)

Building the BSP

This section will guide you through the general build process of the STM32MP15x BSP using the Repo tool .

Our BSP is based on OpenSTLinux Distribution : https://wiki.st.com/stm32mpu/wiki/STM32MP15_OpenSTLinux_release_note

To adapt the OpenSTLinux distribution to our board, we add our own yocto layer "meta-phytec"

You can find our specific meta-phytec layer for stm32mp on :

https://git.phytec.de/meta-phytec/tree/dynamic-layers/stm-st-stm32mp

In this meta-phytec yocto layer, we added some extra features and patches to U-boot and Linux Kernel.

Get the BSP

• Create a fresh project directory:

host:~$ mkdir ~/PHYTEC_STM32MP1_BSP

• Initialize repo in the current directory:

host:~$ cd ~/PHYTEC_STM32MP1_BSP
host:~/PHYTEC_STM32MP1_BSPx$ repo init -u git://git.phytec.de/phy2octo -b stm32mp1 -m PD-BSP-Yocto-OpenSTLinux-STM32MP1-ALPHA1.xml --reference=/home/share/repo_reference

• Synchronize the local project directories with the remote repositories specified in the manifest:

host:~/PHYTEC_STM32MP1_BSP$ repo sync

Basic Set Up

There are a few important steps which have to be done before the main build process.

• Setting up the host:  refer to OpenSTLinux documentation : https://wiki.st.com/stm32mpu/wiki/PC_prerequisites

Finding the Right Software Platform

The STM32MP15x BSP is planned as a unified BSP, which means in the future it will support a set of different PHYTEC carrier boards (CB) with different Systems on Module (SOMs). However, this ALPHA BSP supports only one PHYTEC machine: <MACHINE>=phycore-stm32mp1-1

OpenEmbedded Environment Setup

• Select the correct MACHINE and DISTRIBUTION and initialize the OpenEmbedded build environment :

host:~/PHYTEC_STM32MP1_BSP$ DISTRO=openstlinux-weston MACHINE=phycore-stm32mp1-1 BSP_DEPENDENCY=layers/meta-phytec source layers/meta-phytec/scripts/envsetup.sh

Available Distributions (DISTRO) : please refer to https://wiki.st.com/stm32mpu/index.php/OpenSTLinux_distribution#Distros
By default, our BSP image loaded in the uSD-card that we deliver is based on "openstlinux-weston" Distribution.

Available Hardware configuration (MACHINE ) :"phycore-stm32mp1-1" (only this Hardware configuration is available in Alpha KIT)
The BSP for STM32MP1 depends on packages and firmware which are covered by a software license agreement (SLA). You will be asked to read and to accept this EULA :

• After accepting the EULA, you should now be in a sub-folder named '~/PHYTEC_STM32MP1_BSP/build-<DISTRO>-<MACHINE>'

host:~/PHYTEC_STM32MP1_BSP$ source layers/meta-phytec/scripts/envsetup.sh

Build Process

Now you should be in a sub-folder named '~/PHYTEC_STM32MP1_BSP/build-<DISTRO>-<MACHINE>' and can start the first build process:

host:~/PHYTEC_STM32MP1_BSP/build-openstlinuxweston-phycore-stm32mp1-1$ bitbake st-image-weston

"st-image-westion" is the default image that we deliver with our BSP. This image supports the Weston Display server protocol with basic Wayland support. It comes with a graphical application demo that will show up on a screen (if one display is connected to the carrier board: see Displays section of this Quick Start).

To check all other available images, please refer to : https://wiki.st.com/stm32mpu/index.php/OpenSTLinux_distribution#Images

BSP Images

All images generated by Bitbake are deployed to ~/PHYTEC_STM32MP1_BSP/build-<DISTRO>-<MACHINE>/tmp-glibc/deploy/images/<MACHINE>.

The following list shows the generated files are used for flashing the phycore-stm32mp1-1 machine :

System Booting

The phyCORE STM32MP15x can boot from the following devices :

• eMMC
• NOR
• NAND (when populated instead of eMMC)
• UART 
• USB
• SD-Card

For the Alpha release, the available boot sources are SD Card or SPI NOR(*)

The boot source is chosen by setting the S7 DIP switch:

• Boot from SPI NOR : POS1=> OFF,  POS2 => ON,  POS3 => ON 
• Boot from SD-card :  POS1=> OFF,  POS2 => ON,  POS3 => OFF 

(*)In this case, NOR and eMMC has to be flashed first: see How to flash BSP with STM32CubeProgrammer tool

Booting from SD Card

Booting from the SD Card is useful in several situations (for example when bootloader in Flash memory has crashed).

To boot from SD Card, set the S7 DIP switch as follows: POS1=> OFF,  POS2=> ON,  POS3 => OFF 

There are two ways to create a bootable SD card. You can either:

• use a single prebuilt SD card image (see Create a SD card image (with PC Host SD card reader))
• use STM32MPCubeprogrammer to flash the SD card from target (see How to flash BSP with STM32CubeProgrammer tool)

Create a SD card image (with PC Host SD card reader)

To boot from SD, the first possibility is to create a SD card image that contains all BSP binary files in correctly preformatted partitions. This image can be copied to the SD card easily using the single Linux command dd.

To do this, use the script create_sdcard_from_flashlayout.sh with the <FlashLayout file> = FlashLayout_sdcard_phycore-stm32mp1-1-trusted.tsv:

host:~$ cd build-<DISTRO>-<MACHINE>/tmp-glibc/deploy/images/<MACHINE>/scripts
host:~$ ./create_sdcard_from_flashlayout.sh ../flashlayout_<built-image>/<FlashLayout file>

Example:

host:~$ cd build-openstlinuxweston-phycore-stm32mp1-1/tmp-glibc/deploy/images/phycore-stm32mp1-1/scripts
host:~$ ./create_sdcard_from_flashlayout.sh ../flashlayout_st-image-weston/FlashLayout_sdcard_phycore-stm32mp1-1-trusted.tsv 

The script will generate the following SD card image (raw file): ../flashlayout_st-image-weston/../flashlayout_st-image-weston_FlashLayout_sdcard_phycore-stm32mp1-1-trusted.raw

Use this raw file to populate the SD card with dd command, as follows:

• Insert the uSD-card in the PC Host
• Unmount all the partitions associated to uSD card
• Populate microSD card with dd command:

host:~$ cd build-openstlinuxweston-phycore-stm32mp1-1/tmp-glibc/deploy/images/phycore-stm32mp1-1
host:~$ sudo dd if=flashlayout_st-image-weston_FlashLayout_sdcard_phycore-stm32mp1-1-trusted.raw of=/dev/mmcblk0 bs=8MB conv=fdatasync

More details can be found here: https://wiki.st.com/stm32mpu/wiki/How_to_populate_the_SD_card_with_dd_command

Booting from NOR Flash

With our Alpha KIT, it is not possible too boot from eMMC yet. But you can boot from NOR flash and then Linux is running on eMMC.

To do that you first have to follow the procedure to flash the eMMC and NAND: How to flash BSP with STM32CubeProgrammer tool

After flashing, power off the board, then set the S7 DIP switch to the correct positions: POS1=> OFF, POS2 => ON,  POS3 => ON

When powering the board again, the system will boot from NOR.

How to flash BSP with STM32CubeProgrammer tool

In this section, we explain how to use the STM32MPCubeProgrammer tool that can be use to flash the NOR, eMMC, NAND or SD-Card.

Install STM32CubeProgrammer tool

Refer to : https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer

Connecting the board via USB DFU Link

To download the BSP via DFU link, change the BOOT mode to UART/USB boot mode

• Switch OFF the board
• Change the S7 DIP switch to UART/USB boot mode: POS1=> ON, POS2 => ON,  POS3 => ON
• Switch ON the board => The RED LED on the SOM must start blink RED.

• Connect a USB micro-AB (OTG) on X12 to the host PC that contains the downloaded image. => The RED led should stop blinking.

How to flash NOR and eMMC

• Go to the directory that contains the binaries and the Flash layout files: 

host:~$ cd ~/PHYTEC_STM32MP1_BSP/build-openstlinuxweston-stm32mp1/tmp-glibc/deploy/images/phycore-stm32mp1-1

• Get the device port location for the USB link:

$ STM32_Programmer_CLI -l usb
      -------------------------------------------------------------------
                        STM32CubeProgrammer <tool version>                  
      -------------------------------------------------------------------

=====  DFU Interface   =====

Total number of available STM32 device in DFU mode: 1

  Device Index           : USB1
  USB Bus Number         : 001
  USB Address Number     : 001
  Product ID             : DFU in HS Mode @Device ID /0x500, @Revision ID /0x0000
  Serial number          : 003C00283338510C34383330
  Firmware version       : 0x0110
  Device ID              : 0x0500

• Use the flashing command below:

$ STM32_Programmer_CLI -c port=<DEVICE_PORT_LOCATION> -w [<file.tsv>]
where 
 w:
     Write
 <file.tsv>:PathToFlashlayout/flashlayout.tsv file
         if Flashlayout and binaries are not in the same directory, then the path to the Flashlayout files must be precised.
 <DEVICE_PORT_LOCATION>:
         e.g. usb1 (case sensitive)

How to Flash SD Card

To flash the SD Card with STM32CubeProgrammer process:

• If not already done, insert a SD Card in the SD Card slot (X14).
• Use the flashing command with the following Flashlayout file: /flashlayout_st-image-weston/FlashLayout_sdcard_phycore-stm32mp1-1-trusted.tsv

$ STM32_Programmer_CLI -c port=usb1 -w flashlayout_st-image-weston/FlashLayout_sdcard_phycore-stm32mp1-1-trusted.tsv

This operation takes several minutes (mainly depending of the rootfs size). A successful flashing outputs the following log:

How to flash NOR and eMMC (boot from NOR)

To flash the NOR and eMMC process:

• Use the flashing command with the following Flashlayout file: /flashlayout_st-image-weston/FlashLayout_nor-emmc_phycore-stm32mp1-1-trusted.tsv

$ STM32_Programmer_CLI -c port=usb1 -w flashlayout_st-image-weston/FlashLayout_nor-emmc_phycore-stm32mp1-1-trusted.tsv

This operation takes several minutes (mainly depending of the rootfs size). A successful flashing outputs the following log:

To Be Determined

Using Peripherals (in Linux userspace)

STM32MP15x BSP Device Tree Concept

All Device tree documentation can be found under:

host:~/PHYTEC_STM32MP1_BSP/build-<DISTRO>-<MACHINE>/tmp-glibc/work/<MACHINE>-<DISTRO>-linux-gnueabi/linux-stm32mp/4.19.9-phy1-r0/linux-4.19.9-phy1/Documentation/devicetree/bindings

An introduction of the Device Tree usage can be found in the Linux kernel : linux/Documentation/devicetree/usage-model.txt

STM32MP documentation about the STM32MP15x Device Tree can be found at:

• https://wiki.st.com/stm32mpu/wiki/Device_tree
• https://wiki.st.com/stm32mpu/wiki/STM32MP15_device_tree

Note that in this ST documentation, the device tree files name concerning the boards do not correspond to our PHYTEC boards but the concept is exactly the same. The device tree files for our boards start with "phycore".

STM32MP15x Pin Muxing

The STM32MP15x SoC contains many peripheral interfaces. In order to reduce package size and lower overall system cost while maintaining maximum functionality, many of the STM32MP15x terminals can multiplex up to 16 signal functions. The STM32MP15x BSP is based on the pin controller Linux kernel framework (pinctrl) with specific pinctrl-stm32 driver. The configuration is performed in the device tree.

Please refer to ST documentations to know about pinctrl and how to configure it in the device tree:

• https://wiki.st.com/stm32mpu/wiki/Pinctrl_overview
• https://wiki.st.com/stm32mpu/wiki/Pinctrl_device_tree_configuration

UARTs (stty)

The STM32MP15x SoC provides up to 4 x UART and 4 x USART. phyCORE-STM32MP15x and carrier board is configured by default with 4 UARTs:

Below are some Linux userspace commands to test the UART on target:

• Command to send a message on UART7:

target$ echo "test" > /dev/sttySTM1

• Command to receive a message on UART7:

target$ cat /dev/sttySTM1

• Be sure that the baud rate is set correctly on host and target. In order to get the currently configured baud rate, you can use the command stty on the target.

Command to get stty help:

target$ stty --help

FD CAN bus

For an overview of the Linux Controller Area Network (CAN) framework, please refer to https://wiki.st.com/stm32mpu/wiki/CAN_overview

Below are some example on how to send or receive data on a SocketCAN interface using the can-utils package with the cansend and candumpcommand:

Prerequisite: At least two nodes are required to communicate on a CAN network.

• Initialize CAN0 Link with 1Mbit/s:

target$ ip link set can0 up type can bitrate 1000000

• The command below gets details on the created link:

target$ ip -details link show can0
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0 
    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 
          bitrate 992063 sample-point 0.761
          tq 48 prop-seg 7 phase-seg1 8 phase-seg2 5 sjw 1
          m_can: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..512 brp-inc 1
          m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp-inc 1
          clock 62500000numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

• To send a single frame, use the cansend utility (cansend <device> <can_frame>):

target$ cansend can0 123#1122334455667788                                                                                                                                                   

• To receive CAN message, use the candumputility:

target$ candump can0                                                                                                                                                     
  can0  123   [8]  00 11 22 33 44 55 66 77
  can0  123   [8]  00 11 22 33 44 55 66 77

• To print help on candump utility use: "candump -h"

Network

A gigabit Ethernet is provided by our module and board. All interfaces offer a standard Linux network port which can be programmed using theBSD socket interface. The BSP contains different Network tools which allow for the configuration and testing of the Ethernet connection.

For information about these different tools and how to use it, please refer to: https://wiki.st.com/stm32mpu/wiki/Network_tools

Example on how to assign an a given IP address to a Ethernet ETH0 interface:

ifconfig eth0 10.48.1.324

SD Card

The STM32MP15x ALPHA release kit supports a slot for Secure Digital Cards to be used as general purpose block devices. These devices can be used in the same way as any other block device.

After inserting an SD/MMC card, the kernel will generate new device nodes in /dev. The full device can be reached via its /dev/mmcblk0 device node. SD/MMC card partitions will show up in the following way:

/dev/mmcblk0p<Y>

<Y> counts as the partition number starting from 1 to the max count of partitions on this device. The partitions can be formatted with any kind of file system and also handled in a standard manner, e.g. the mount and umount command work as expected.

GPIOs

The PCM-939 carrier board has a set of pins specially dedicated as user I/Os. Those pins are connected directly to STM32MP15x balls and are muxed as GPIOs. Accessing GPIOs from user space can be done using the libgpiod.

To know how to access the GPIOs, please refer to: https://wiki.st.com/stm32mpu/wiki/How_to_control_a_GPIO_in_userspace 

Keys

With gpio-keys driver, the Linux kernel can interpret GPIO signals as virtual keyboard events. The carrier board have 2 buttons (S4 and S5), which can be used with the gpio-keys driver. 

To display the key events in ASCII format use evtest.

• To show the available input devices, run:

target$ evtest

• You will get, for example:

No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      pmic_onkey
/dev/input/event1:      gpio-keys
Select the device event number [0-1]:

• Select input device event number 1 for gpio-keys

Select the device event number [0-1]: 1
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "gpio-keys"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 28 (KEY_ENTER)
    Event code 102 (KEY_HOME)
Properties:
Testing ... (interrupt to exit)

• Now you will see every hit on push buttons S4 (KEY_HOME) or S5 (KEY_ENTER):

Event: time 1570639195.409061, type 1 (EV_KEY), code 102 (KEY_HOME), value 1
Event: time 1570639195.409061, -------------- SYN_REPORT ------------
Event: time 1570639195.569047, type 1 (EV_KEY), code 102 (KEY_HOME), value 0
Event: time 1570639195.569047, -------------- SYN_REPORT ------------
Event: time 1570639196.809052, type 1 (EV_KEY), code 28 (KEY_ENTER), value 1
Event: time 1570639196.809052, -------------- SYN_REPORT ------------
Event: time 1570639197.009031, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1570639197.009031, -------------- SYN_REPORT ------------

• You can exit evtest with Ctrl+C
• Listening to the device with cat will print the raw output:

target$ cat /dev/input/event1
root@phycore-stm32mp1-1:/sys/class# cat /dev/input/event1 
F
�]��fF
�]��F
�]BfF
�]B

LEDs

If any LEDs are connected to GPIOs, you have the possibility to access them by a special LED driver interface instead of the general GPIO interface (section GPIOs). You will then access them using /sys/class/leds/ instead of /sys/class/gpio/. The maximum brightness of the LEDs can be read from the max_brightness file. The brightness file will set the brightness of the LED (taking a value from 0 up to max_brightness). Most LEDs do not have hardware brightness support and therefore, will just be turned on by all non-zero brightness settings.

Here is a simple example:

• To get all LEDs available, type:

target$ ls /sys/class/leds
blue-power  pca:green:power  pca:red:power

Here the LEDs are the tree possible color from RGB LED driven by a LED dimmer present on carrier board. By default, the RGB LED is blinking blue (it is the "Linux Heartbeat" that show that the Linux Kernel is running). But this RGB LED can also be used as a "user LED".

• Example to toggle the RGB LED Blue color OFF :

target$ echo 0 >  blue-power/brightness

• Example to toggle RGB LED Blue color ON with a brightness=10 :

target$ echo 10 >  blue-power/brightness

• Example to toggle RGB LED Green color ON with a brightness=20 :

target$ echo 20 >  pca\:green\:power/brightness

I²C Bus

The STM32MP15x SoC provides up to 6 I²C FM (Fast-Mode). The phyCORE-STM32MP15x is configured to features two Fast-Mode I²C modules called I2C4 and I2C1.

• I²C4 is reserved for the I²C devices on the Module (PMIC, RTC, EEPROM)
• I²C1 is reserved for the carrier board which provides plenty of different I²C devices connected I²C1 bus of the STM32MP15x. This chapter will describe the basic device usage.

EEPROM

It is possible to read and write directly to the device:

/sys/class/i2c-dev/i2c-1/device/1-0050/eeprom

• To read and print the first 1024 bytes of the EEPROM as hex number, execute:

target$ dd if=/sys/class/i2c-dev/i2c-1/device/1-0050/eeprom bs=1 count=1024  | od -x

• To fill the whole EEPROM with zeros, use:

target$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-1/device/1-0050/eeprom bs=4096 count=1

This operation takes some time because the EEPROM is relatively slow.

RTC

RTCs can be accessed via /dev/rtc*. 

• Check the available RTC :

target$ ls /sys/class/rtc
target$ rtc0  rtc1

• To find the name of the RTC devices, you can read its sysfs entry with:

target$ cat /sys/class/rtc/rtc*/name
rtc-rv3028 1-0052
stm32_rtc 5c004000.rtc

As the time is set according to the value of rtc0 during system boot, rtc0 should always be the RTC that is being backed up. 

• Date and time can be manipulated with the date command and the hwclock tool. Example to set the date on /dev/RTC0:

target$ date 1010123119
Thu Oct 10 12:31:00 UTC 2019
target$ hwclock -w

USB HOST and OTG

To know about the Linux USB framework and how to use it, please refer to the the USB framework: https://wiki.st.com/stm32mpu/wiki/USB_overview

Both OTG and Host use the same framework. 

For more software details about the OTG internal peripheral, please refer to : https://wiki.st.com/stm32mpu/wiki/OTG_internal_peripheral

For more software details about the USBH internal peripheral, please refere to : https://wiki.st.com/stm32mpu/wiki/USBH_internal_peripheral

Create a SSH connection with USB OTG

When the target is running on Linux, you can create a SSH connection with Ethernet or USB OTG.

To create a SSH connection over USB OTG, proceed as folllow : 

• On the PC host, use "ifconfig" on a terminal
• Plug a USB-A male to USB Micro B betwen the carrier board (X12) and the PC Host.
• On the PC host, use "ifconfig" on a terminal, and check that there is a new network interface 
• Check the IP address of the USB OTG device :

target$ ifconfig 
eth0      Link encap:Ethernet  HWaddr 8E:C5:2C:68:CF:75  
          inet6 addr: fe80::8cc5:2cff:fe68:cf75/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:7597 (7.4 KiB)
          Interrupt:61 Base address:0x2000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:264 errors:0 dropped:0 overruns:0 frame:0
          TX packets:264 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:16800 (16.4 KiB)  TX bytes:16800 (16.4 KiB)

usb0      Link encap:Ethernet  HWaddr BA:15:19:D5:BC:01  
          inet addr:192.168.7.2  Bcast:192.168.7.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

• On the PC host, use "ifconfig" to set the new Network interface IP that match with the usb0 target interface. Example :

host:~$ sudo ifconfig enp0s20f0u2u3 192.168.7.1

• Connect to the target :

host:~$ ssh root@192.168.7.2

The same procedure can be apply with an Ethernet connection.

Audio

On the phyCORE-STM32MP15x , we use the TI TLV320AIC3007 audio codec. Audio support is done via the I²S interface and controlled via I²C.

• To check if your sound card driver is loaded correctly and to check which Audio output device is available:

target$ aplay -L

• You will get output similar toː

null
      Discard all samples (playback) or generate zero samples (capture)
pulse
      PulseAudio Sound Server
default
      Default ALSA Output (currently PulseAudio Sound Server)
sysdefault:CARD=STM32MP1PHYCORE
      STM32MP1-PHYCORE, 
       Default Audio Device

• To test Audio Playback:

target$ aplay -D plughw:CARD=STM32MP1PHYCORE /usr/share/sounds/alsa/Front_Center.wav

• To list Audio capture devices :

target$ arecord -l
**** List of CAPTURE Hardware Devices ****card 0: STM32MP1PHYCORE [STM32MP1-PHYCORE], device 1: 4400b004.audio-controller-tlv320aic3x-hifi tlv320aic3x-hifi-1 [] 
Subdevices: 1/1 Subdevice #0: subdevice #0

• Run speaker-test to identify channel numbers (Left, Right...). Example to chek right and left channel (2 channels):

target$ speaker-test -c 2 -t wav

• You may have to select the audio device:

target$ speaker-test -c 2 -t wav -D plughw:CARD=STM32MP1PHYCORE

• To inspect your sound cards capabilities, call:

target$ alsamixer

You should see a lot of options as the audio-ICs has many features you can play with. It might be better to open alsamixer via ssh (see Create a SSH connection with USB OTG) instead of the serial console, as the console graphical effects are better. You have either mono or stereo gain controls for all mix points. "MM" means the feature is muted (both output, left & right), which can be toggled by hitting m. You can also toggle by hitting '<' for left and ''>' for right output. => TO BE CHECKED

Audio Sources and Sinks

Playback

To playback simple audio streams, you can use aplay. For example:

target$ aplay /usr/share/sounds/alsa/Front_Center.wav
#OR you may have to select the audio device:
target$ aplay -D plughw:CARD=STM32MP1PHYCORE /usr/share/sounds/alsa/Front_Center.wav

Capture

arecord is a command line tool for capturing audio streams which uses Line In as the default input source. 

The following example captures the current stereo input source with a sample rate of 48000 Hz and creates an audio file in WAV format (signed 16 bit per channel, 32 bit per sample):

target$ arecord -t wav -c 2 -r 48000 -f S16_LE test.wav
#OR :
target$ arecord -t wav -c 2 -f dat test.wav
#OR you may have to select the audio device:
target$ arecord -t wav -c 2 -f dat test.wav -D hw:0,1

Capturing can be stopped using CTRL-C. You can also specify the capture duration with the -d option.

To play the record file: 

target$ aplay test.wav

Texas Instruments TLV320AIC3007

The TI chip has a lot of mixing features as you will notice when opening alsamixer. To get an idea of the possibilities, refer to the datasheet from TI. One important feature is the analog mixing capability. You can route input channels to output channels, either active or passive, without transferring data back and forth to the SoC. This is usually known as zero-latency monitoring in terms of PC Audio cards. To control this feature, open alsamixer and go to Playback section (F3). There will be one group of selectors for each output channel, e.g. Right Line Mixer. For most of the input paths, you can select between "passive through" or you can activate a programmable gain signal path. To route the line input to the line output, activate both "Right Line Mixer PGAR Bypass" and "Left Line Mixer PGAL Bypass". You should now hear the input signal at the line-out.

As an example application, we can route the audio stream through the whole system. First, we deactivate the direct loop from line-in to line-out in alsamixer and activate the ADC for the analog input mixer and the DAC for the analog output mixer. We can now close the signal path in the user space by using a pipe and the ALSA tools:

target$ arecord -c 2 -r 48000 -f S16_LE | aplay
#OR
target$ arecord -c 2 -r 48000 -f S16_LE -D hw:0,1 | aplay -D plughw:CARD=STM32MP1PHYCORE

We created the following audio routing path:

analog in -> ADC -> i.MX8M -> kernel -> (userspace -> kernel -> )* DAC -> analog out

* actually twice for the pipe

You should now hear the input signal at the line output again. But this time, the routing through the entire system added a latency of 750 ms to the signal. The line mixer on the other side will only add about 4 μs delay.

This pipe routing is a crude example of how to use audio. If you need good audio performance, you should use an audio server. There are two prominent choices available, pulseaudio and jack.

As a third option, you can route the audio from line-in to the internal ADC. But instead of taking the signal path through the complete system, you can use the internal digital mixer of the TLV to directly route the signal back to the DAC and then to the output analog mixer and line-out. This signal path is record only. You do not have the option of full-duplex playback in this mode. You can, however, use all the available DSP features of the TLV, the automatic gain, the high-pass filter, EQ, and de-emphasis filters for the record path. To activate this mode, you have to use the TI Windows tool to look up the specific I²C commands. The software can be found on the TI webpage and is called TLV320AIC3107EVM-K - GUI software. The 3107 is register compatible with all available features to the 3007. The software is used for both chips.

Displays

Three different kind of displays are currently supported :

• HDMI monitor => with PEB-AV-01 PHYTEC addon connected on Audio/Video connectors X24/X25
• AC158 7" EDT capacitive LCD screen => with PEB-AV-02 PHYTEC addon connected on Audio/Video connectors X24/X25
• MB1407 MIPI DSI screen (from STMicroelectronics : https://wiki.st.com/stm32mpu/wiki/MB1407) => connected on MIPI DSI connector X41

By default the PHYTEC BSP is configured for the AC158 display.

To switch between the 3 different configurations the device tree has to be rebuilt.

How to change the BSP Display configuration

Prerequisite : Building the BSP must have been done.

Build a new image enabling/disabling the following device tree files :

• phycore-stm32mp1-dsi-lcd-mb1407.dtsi
• phycore-stm32mp1-peb-av01-hdmi.dtsi
• phycore-stm32mp1-peb-av02-lcd.dtsi

By default, only phycore-stm32mp1xx-peb-av02-lcd.dtsi is enable (for AC158 parallel display screen configuration)

To enable/disable those extensions, comment/uncomment the corresponding line in the phycore-stm32mp1-1.dtsi device tree file.

Expansion board connectors

The expansion board pinout can be configured in the device tree in the following device tree files :

• phycore-stm32mp1-pi-hat-extension.dtsi
• phycore-stm32mp1-uno-r3-extension.dtsi
• phycore-stm32mp1-motor-control.dtsi

By default those device tree files are not enabled. To enable/disable it, comment/uncomment the corresponding line in the phycore-stm32mp1-1.dtsi device tree file

Prerequisite : Building the BSP must have been done.

Rapsberry PI HAT connector

This connector is compatible with the pinout of Raspberry HAT (https://pinout.xyz/)

The pinout can be configured by pin muxing in the following device tree file: phycore-stm32mp1-pi-hat-extension.dtsi

Arduino connector

TBC

Motor Control connector

TBC

Expansion connector

TBC