L-1011e.A0 i.MX 8 phyGATE-Tauri-L Alpha Kit BSP Guide

Table of Contents

L-1011e.A0 i.MX 8 phyGATE-Tauri-L Alpha Kit BSP Guide
Document Title

L-1011e.A0 i.MX 8 phyGATE-Tauri-L Alpha BSP Guide

Document TypeBSP Reference Manual
Yocto PageL-813e_6 Yocto Reference Manual
Article NumberL-1011e.A0
Release Date25.02.2021
Is Branch of

L-1011e.Ax i.MX 8 phyGATE-Tauri-L Alpha Kit BSP Guide Head

Copyrighted products are not explicitly indicated in this manual. The absence of the trademark (TM or ®) and copyright (©) symbols does not imply that a product is not protected. Additionally, registered patents and trademarks are similarly not expressly indicated in this manual.

The information in this document has been carefully checked and is considered to be entirely reliable. However, PHYTEC Messtechnik GmbH assumes no responsibility for any inaccuracies. PHYTEC Messtechnik GmbH neither gives any guarantee nor accepts any liability whatsoever for consequential damages resulting from the use of this manual or its associated product. PHYTEC Messtechnik GmbH reserves the right to alter the information contained herein without prior notification and accepts no responsibility for any damages that might result.

Additionally, PHYTEC Messtechnik GmbH offers no guarantee nor accepts any liability for damages arising from the improper usage or improper installation of the hardware or software. PHYTEC Messtechnik GmbH further reserves the right to alter the layout and/or design of the hardware without prior notification and accepts no liability for doing so.

@ Copyright 2021 PHYTEC Messtechnik GmbH, D-55129 Mainz.

Rights - including those of translation, reprint, broadcast, photomechanical or similar reproduction and storage or processing in computer systems, in whole or in part - are reserved. No reproduction may occur without the express written consent from PHYTEC Messtechnik GmbH.

 

EUROPE

NORTH AMERICA

FRANCE

INDIACHINA

Address:

PHYTEC Messtechnik GmbH
Robert-Koch-Str. 39
D-55129 Mainz
GERMANY

PHYTEC America LLC
203 Parfitt Way SW
Bainbridge Island, WA 98110
USA

PHYTEC France
17, place Saint-Etienne
F-72140 Sillé-le-Guillaume
FRANCE

PHYTEC Embedded Pvt. Ltd
No. 1688, 25th A Cross
27th Main, 2nd Sector, Opp. PEP School
V2, HRS Layout
Bangalore 560102
INDIA

PHYTEC Information Technology (Shenzhen) Co. Ltd.
2106A, Block A, Tianxia Jinniu Square,
Taoyuan Road, Nanshan District,
518052 Shenzhen, Guangdong, 
CHINA

Ordering Information:

+49 6131 9221-32
sales@phytec.de

+1 800 278-9913
sales@phytec.com

+33 2 43 29 22 33
info@phytec.fr

+91-80-4086 7046/48
sales@phytec.in
+86-755-3395-5875
sales@phytec.cn

Technical Support:

+49 6131 9221-31
support@phytec.de

+1 206 780-9047
support@phytec.com


support@phytec.fr

+91-80-4086 7047
support@phytec.in

support@phytec.cn

Fax:

+49 6131 9221-33

+1 206 780-9135

+33 2 43 29 22 34


+86-755-3395-5999

Web Site:

http://www.phytec.de
http://www.phytec.eu

http://www.phytec.com

http://www.phytec.fr

http://phytec.inhttp://www.phytec.cn

Notes about this Manual

Usage

The information in this manual is valid for all standard variants of the phyGATE Tauri-L industrial gateway from PHYTEC Messtechnik GmbH. An overview of all devices and variants to which the descriptions apply can be found in Chapter 3 - "Product Information".

Before using the document, please check whether it also corresponds to the latest version. The latest version of the manual and other technical documents can be found on the product page for the device at www.phytec.de.

Warning

For proper installation and safe operation of the device, the operating instructions and in particular the safety instructions contained therein must be carefully read and observed.

Symbols

The manual uses various symbols to indicate helpful and safety-critical notes. Below you will find an explanation of each symbol's meaning.

Warning

This symbol indicates safety-critical information. The warnings must be observed!


Tip

This symbol indicates general notes and helpful information in handling the device.

Safety Instructions and Liability

Intended Use

The and phyGATE Tauri-L gateway is designed for monitoring, processing, and communicating machine and sensor data in industrial environments. For data communication, the devices provide various typical industrial interfaces for connection to surrounding devices.

This PHYTEC standard gateway is supplied exclusively as an OEM device by PHYTEC Messtechnik GmbH and requires an adaptation of the operating software for the intended application by the distributor of the device.

General Safety Instructions

For commissioning, development work, and assembly, the operating instructions for the device must be used. Knowledge in the following areas is required:

  • Electronic circuitry
  • Working in electrostatically protected areas
  • Accident prevention regulations
  • On-site valid rules and regulations for occupational safety

These devices may only be commissioned and installed by adequately qualified personnel with basic electrical knowledge! The device must be handled with care in every phase of its life cycle, in order to prevent destruction by electrostatic discharge or mechanical stress, for example.

Improper modifications and repairs may impair the integrated protective functions and the electromagnetic behavior of the device. This can cause malfunction of the device, interference with connected and surrounding devices, or personal injury. Therefore, work on this device may only be carried out by the manufacturer.

The gateway must be mounted on a top-hat rail in a control cabinet for permanent use.

Disposal

The operator of these devices must ensure that there is no danger to persons or property in the event of a defect or malfunction of the device. In case of non-repairable defects and device malfunctions, the devices must be taken out of operation and disposed of properly.

Warning

The device must not be disposed of in household waste!
 

Liability

Improper use and connection of these devices, as well as subsequent processing of these devices (e.g. soldering work on the printed circuit board), lead to exclusion of liability on the part of the manufacturer. Please observe the corresponding information in the operating instructions for proper installation.

Product Information

Product Names and Variants

The phyGATE-Tauri gateway is available in different variants and expansion stages, which differ in the scope of performance and functions. The following table gives an overview of available variants of the gateway and an explanation for the identification of the article number.

Note

The article numbers have an index ".Ax" where x determines the product revision.


Parent ProductArticle NumberTechnical Features














phyGATE Tauri-L Gateway


standalone PCB
PB-03420-0140.Ax
Device with housing
PB-03420-001.Ax

  • 2x Ethernet
  • 1x USB
  • 1x MicroSD Card
  • Temp-Sensor
  • TPM
  • (25mm housing)



standalone PCB
PB-03420-0130.Ax
Device with housing
PB-03420-002.Ax

  • 2x Ethernet
  • 1x USB
  • 1x MicroSD Card
  • Temp-Sensor
  • TPM
  • CAN
  • RS485
  • RS232
  • (25mm housing)




standalone PCB
PB-03420-0330.Ax
Device with housing
PB-03420-003.Ax

  • 2x Ethernet
  • 1x USB
  • 1x MicroSD Card
  • Temp-Sensor
  • TPM
  • CAN
  • RS485
  • RS232
  • mPCIe slot (USB only) with 1x SMA antenna connector
  • (50mm housing)

Product Overview

The phyGATE-Tauri-L has several interfaces and controls/displays which are shown in the following figure.



PB-03420-001.Ax
(25mm housing)

PB-03420-002.Ax
(25mm housing)

PB-03420-003.Ax
(50mm housing)


XXX

1. Power-LED green

XXX

2. User-LED yellow (freely configurable)

XXX

3. User-LED red (freely configurable)

XXX

4. Button (freely configurable)

XXX

5. USB interface (Typ A)

XXX

6. Ethernet interface (RJ45)

XXX

7. Micro-SD Slot


XX

8. RS232, RS485, CAN interface (configurable)

XXX

9. Supply connection

XXX

10. Boot-Switch (Concealed, on opposite housing side)

XXX

11. Air vents

XXX

12. Extension interface under a top-hat rail and top-hat rail clip (35mm)



X(13.) SMA antenna connector


X(14.) internal miniPCIe slot (USB only)


X(15.) SIM card socket

Nameplate

The nameplate of the phyGATE Tauri-L gateway is located on the side of the housing. Here you will find essential information about your device.

Technical Data

Electrical Data


Power supply voltage

min. 12 VDC (-10 %)
typ. 24 VDC
max. 36 VDC (+10 %)

Power consumption

min. 3 W
max. 24 W


Hardware Specification

CPU type

NXP i.MX 8M mini Quad-Core Cortex-A53 + Cortex-M4
max. 1,8 GHz (A53 core) / 400 MHz (M4 core)

RAM

2 GB

eMMC

8 GB

Ethernet

2x 10/100/1000 Mbit/s

USB

USB 2.0

CAN (optional)

1 Mbit/s, CAN FD, isolated


Serial (optional)

  1. 1x RS232+RTS/CTS isolated or
  2. 2x RS232 (RxD/TxD) isolated or
  3. 1x RS232+ 1x RS485 isolated
Mass storage

microSD card slot
storage size max 16 GB (evaluated), class10

Additional featuresTPM chip, Temperature sensor

RTC

GoldCap for real-time functionality


User control elements

1x user button
2x configurable user LED
1x power status LED


Software Specification
Operating system

Linux (Yocto)

Security Features

Device-Management / Cloud-Update concept


Mechanical Data

Housing typePhoenix ICS

Housing material

Polyamid

Mounting type

Top-hat rail mounting according to DIN EN 60715

IP protection class

max. IP20





Dimensions (Height / Width / Depth)

100 mm / 25 mm / 110 mm

PB-03420-001.Ax
PB-03420-002.Ax
100 mm / 50 mm / 110 mm
PB-03420-003.Ax
with customer adapter PCB

Weight (depending on variant)

max. 250 g (depending on variant)


Environmental Data

Storage temperature

-20 °C - +70 °C

Operating temperature

-20 °C - +60 °C

Humidity

10% - 95% non condensing

IP protection class control cabinet

min. IP44


Package Contents/Accessories

phyGATE-Tauri-L Stand-alone device

phyGATE-Tauri-L Kit Upgrade

You'll find the following content within your stand alone phyGATE-Tauri-L packaging:

  • 1x phyGATE-Tauri-L device of your choice
  • 1x instruction insert with general information and safety hints


The phyGATE-Tauri-L Kit upgrade for the easy start of development:

  • 1x MicroSD Card with prepared prebuilt images
  • 1x 24 VDC Mains-Adapter with a mating connector to device supply connector
  • 1x Serial and CAN interface mating connector with screw connectors
  • 1x LAN cable 2m

   Ethernet CableSD Card

Certification

The phyGATE-Tauri has been approved for sale and use on the European market and meets the criteria for CE marking according to:

  • DIN EN 61000-6-2:2019-11 EMV Interference immunity for industrial areas
  • DIN EN 61000-6-3:2020-09 EMV Interference emissions for living area

The CE declaration of conformity for the device can be found online on the product page at www.phytec.de.

Warning

Modification of the device, such as adjustments to the software or the use of additional devices in conjunction with the phyGATE-Tauri Gateway, can influence the electrical properties of the device. In this case, the validity of the CE declaration of conformity is void. For a valid CE marking, a renewed approval by the operator must be carried out in this case.

Technical Documentation and Support

Technical documentation for the product can be found on our product page online at www.phytec.de. If you have any questions or suggestions regarding the product, we look forward to hearing from you.

Technical Product Information

Block Diagram

Electrical Connection

The phyGATE Tauri-L gateway has various interfaces for connection to the surrounding infrastructure. The following table lists the connections with the matching mating connectors.


phyGATE Tauri-L Interfaces

Reference

Connection

Device Socket

Mating Connector

X28

DC supply

Phoenix MC 1,5/ 2-GF-3,81

Phoenix MC 1,5/ 2-STF-3,81

X29

Ethernet 1

RJ45

RJ45

X30

Ethernet 0

RJ45

RJ45

X8

USB

USB-A

USB-A

X5

SD Karte

microSD-Slot

MicroSD-Karte

X27

RS232 / RS485 / CAN

Phoenix MC 1,5/10G-3,5

Phoenix MC1,5/10-ST-3,5

S1

User Input Button

---

---

S2

Boot-Switch

---

---

(X23)AntennaSMA (female)SMA (male)


Pinout of non-standard interfaces

Reference

Connection

Pin

Function


X28



DC supply


1

+24 VDC

2

Device GND









X27









RS232 / RS485 / CAN








1

RS232_0_TX

2

RS232_0_RX

3

GND_ISO

4

RS232_1_TX

5

RS232_1_RX

6

GND_ISO

7

RS485_A

8

RS485_B

9

CANH

10

CANL


Tip

For the phyGATE Tauri-L variants with RS232 / CAN / RS485, the function of the pins can be configured by the application software.


Warning

All signals at connector X27 are galvanically decoupled from the GND reference potential of the board and the supply voltage of the phyGATE Tauri-L.

Mechanical Connection

The phyGATE-Tauri gateway housing is designed to be mounted on a top-hat rail in the control cabinet. For mounting on the top-hat rail, there is a mounting device on the housing which allows a tool-free and safe mounting on a 35 mm top-hat rail according to DIN EN 60715.

Warning

The installation environment, such as the control cabinet in which the device is installed, must meet, as a minimum, the IP44 specifications.


Warning

To prevent malfunction or destruction of the device due to overheating, it is essential to ensure that the ventilation slots are not covered by surrounding components, cables, and other objects. The air must be able to circulate freely around the housing to dissipate heat.

Getting Started with the phyGATE-Tauri-L Gateway

Introduction

To easily get started with your phyGATE Tauri-L device, you'll find a description with the necessary tools and provision of the know-how to work with the Linux Board Support Package (BSP) for the phyCORE-i.MX 8M Mini below. It shows you step by step, how to set up the device for an easy start in development, including:

  • essential connection of the device and getting access to the OS
  • installing and use the appropriate tools and sources
  • building custom kernels
  • deploying the OS in order to operate the software and hardware

Tip

All necessary information, software, and other downloads for quick commissioning can be found on the phyGATE Tauri-L product page online at www.phytec.de.

Requirements

You'll need the following components to get started quickly with this installation guide:

  • phyGATE-Tauri-L device
  • 1x MicroSD Card with prepared prebuilt image
  • 1x 24 VDC Mains-Adapter with a mating connector to device supply connector
  • 1x LAN cable

   Ethernet CableSD Card


Tip

The phyGATE-Tauri-L kit upgrade contains all the necessary components to easily start installing the device.

Prepare the SD Card for device boot

To prepare the microSD card for the device boot, please follow the steps mentioned below.

Tip

If you have a prepared SD card for a phyGATE Tauri Kit, this section can be skipped.

If you are using your own SD Card, you'll have to download the prebuilt image file and burn it to the SD card first:

  1. Choose the right pre-built image from the phytec-ftp-server. There are two different versions, depending on the interfaces which you want to use. Machine phygate-tauri-l-imx8mm-2 is for RS232 and RS485 and machine phygate-tauri-l-imx8mm-1 for RS232 Handshakes optimized. The following links will take you to the download pages:                                                                                                                                                     
  2. Download the Image file
  3. Burn the Image to the SD Card (see the descriptions below).

If you are using Windows:

To burn the Image to the SD Card, you'll have to use an image burner tool of your choice. The description below is based on the WIN32 Disk Imager Tool. 

Please follow the steps below to get your SD card ready with WIN32 Disk Imager:

  1. Choose the Image File and your microSD device
  2. Press 'Write' to burn image on your microSD card

Warning

Be sure the right Device is selected to avoid damage to other storage devices connected to your computer.

If you are using Linux:

  1. Open Terminal on Host-System and type the following command to burn the Image:
Host$ sudo dd if=<IMAGENAME>-<MACHINE>.sdcard of=/dev/<your_device> bs=1M conv=fsync status=progress

Booting the Board

Insert the microSD card

To use an SD card, it's necessary to put the card in its slot., located in the front.

Set Boot Switch

The phyGATE-Tauri-L provides a boot switch to choose the boot source of the device. You can choose either eMMC (DIP at position '1') or SD Card (DIP at position 'ON') as a boot source. 

The red switch is located at the opposite side of the housing referenced to the supply connector X28. You can reach the switch between the vent slots of the housing with help of a small item e.g. a screwdriver to switch the position of the DIP switch.

Powering the Board

The phyGATE-Tauri-L has a 2 pin Phoenix Contact MINI COMBICON power connector (counterpart Phoenix Contact MC 1,5/ 2-STF-3,5 or MC 1,5/ 2-ST-3,5). The permissible input voltage is 12 VDC to 36 VDC. A 24 VDC adapter with a minimum current rating of 1A is recommended to supply the board.

After turning the power supply on, the green LED on the top side will light up and the boards will start booting.

Warning

Please note the polarity of the power connector X28. Make sure that your power adapter is correctly set up to use the polarity as shown in the picture above!

Do not make any electrical changes with the interfaces and cables while the board is connected to power. This is to avoid damage to the device!

Tip

Be aware that as soon as the phyGATE-Tauri is supplied with power, the SD Card boot sequence will begin. Ensure that all cables are connected on the board!

Tip

With help of the red user LED in the front of the device housing, you can see if the boot process is running. The LED is flickering during the boot process.

Connecting the OS via SSH

Once the board is done booting, you can connect to the board via Ethernet and SSH. Therefore, you need to connect an RJ45 Ethernet cable between the phyGATE and your computer. Make sure that the IP configuration of your computer is configured as follows:

  • IP address: 192.168.3.10
  • Netmask: 255.255.255.0

Now you are able to log in via SSH. Therefore, please use the following login data:

  • IP Adress: 192.168.3.11
  • Port: 22
  • User: root
  • Password: no password

Warning

Login via SSH should only be used for the purpose of development. Otherwise, there will be a security risk.

If you are using Linux:

host$ ifconfig <eth-interface> 192.168.3.10 up
host$ ssh root@192.168.3.11
host$ 
host$ yes
Yogurt Vendor (Phytec Vendor Distribution) 2.6.2 phygate-tauri-l-imx8mm-2 ttymxc2  phygate-tauri-l-imx8mm-2 login: 

If you are using Windows:

For the SSH-connection under Windows, you can use an SSH client of your choice. The description below is based on PuTTY: 


  1. Type Host Name "root@192.168.3.11" in
  2. Press Open

Setup Device Interfaces

Connecting to RS232

The phyGATE-Tauri-L provides up to two RS232 interfaces (RS232_0, RS232_1). From the command line prompt of Linux userspace, you can easily send and receive data over the RS232 interface.

Send:

target$ echo test > /dev/ttymxc1

Receive:

target$ cat /dev/ttymxc1

Connecting to RS485

To use the RS485 interface, it has to be configured beforehand, as the used UART can also be used as a second RS232.

To configure the UART (ttymxc3) as RS485, use the following commands:

target$ echo 89 > /sys/class/gpio/export
target$ echo out > /sys/class/gpio/gpio89/direction
target$ echo 84 > /sys/class/gpio/export
target$ echo out > /sys/class/gpio/gpio84/direction
target$ echo high > /sys/class/gpio/gpio89/value 
target$ echo high > /sys/class/gpio/gpio84/value 

After that, you are able to configure the interface itself:

target$ stty -F /dev/ttymxc3 115200 -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke raw 

Use the command echo to send and cat to receives messages:

target$ echo "TEST ttymxc3" > /dev/ttymxc3
target$	cat /dev/ttymxc3

Connecting to CAN

The CAN configuration is automatically done by the daemon systemd. You can send messages with cansend or receive messages with candump:

target$ ip link can0 down
target$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
target$ cansend can0 123#ab.cd.ef 
target$ candump can0

Connecting to USB

The driver will detect USB-Devices automatically. To mount a USB-Flash for example, use the following commands:

target$ mount /dev/disk/by-id/usb_san_disk_0:-part1 /mnt/
target$ cd /mnt

Building the BSP

This section will guide you through the general build process of the i.MX 8M Mini BSP using the phyLinux script.

If you want to use our software without phyLinux and the Repo tool managed environment instead, you can find all Git repositories on:

git://git.phytec.de

Used u-boot repository:

git://git.phytec.de/u-boot-imx

Our u-boot version is based on the u-boot-imx and adds only a few patches which will be sent upstream in future releases.

Used Linux kernel repository:

git://git.phytec.de/linux-imx

Our i.MX 8M Mini kernel is based on the linux-imx kernel.

To find out which tag is used for a specific board, have a look at your BSP source folder under:

meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
meta-phytec/recipes-kernel/linux/linux-imx_*.bb

Get the BSP

  • Create a fresh project directory:
host$ mkdir ~/yocto
  • Download and run the phyLinux script:

host$ cd ~/yocto
host$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
host$ chmod +x phyLinux
host$ ./phyLinux init

Basic Set-Up

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

  • Setting up the host: see Yocto Reference Manual "Setting up the Host" and NXP’s documentation i.MX Yocto Project User's Guide "Host Setup". You will need to register on the NXP website to download this information. ( File will download automatically as a .tar.gz archive.)
  • Setting up the Git configuration: see Yocto Reference Manual "Git Configuration"

Finding the Right Software Platform

The i.MX 8M Mini 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 the PHYTEC machine:

#@TYPE: Machine
#@NAME: phygate-tauri-l-imx8mm-2 #@DESCRIPTION: PHYTEC phyGATE-Tauri i.MX8M Mini 2GB RAM
#@ARTICLENUMBERS: PB-02820.A1
#@SUPPORTEDIMAGE: phytec-qt5demoimage-image/yogurt-vendor-xwayland


host:~/yocto$ MACHINE=phygate-tauri-l-imx8mm-2 DISTRO=yogurt-vendor-xwayland source sources/poky/oe-init-build-env

Software Platform Selection

  • To select the correct SoC, BSP version, and platform call:
host$ ./phyLinux init
  • It is also possible to pass this information directly using command line parameters:
host$ MACHINE=phygate-tauri-l-imx8mm-2 ./phyLinux init -p imx8mm -r ALPHA2

Build Process

After you have downloaded all the metadata with phyLinux init, you have to set up the shell environment variables. This needs to be done every time you open a new shell for starting builds. We use the shell script provided by Poky in its default configuration.

  • From the root of your project directory, type:
host$ source sources/poky/oe-init-build-env
  • Now you should be in a sub-folder named 'build' and you can start the first build process:
host:~/yocto/build$ bitbake phytec-headless-image

BSP Images

All images generated by Bitbake are deployed to ~/yocto/build/tmp/deploy/images/phygate-tauri-l-imx8mm-1/.

The following list shows for example all files generated for the i.MX 8M Mini phygate-tauri-l-imx8mm-1 machine:

  • U-Boot: u-boot.bin
  • U-Boot-SPL: u-boot-spl.bin
  • lpddr4 binary files: lpddr4_pmu_train_1d_dmem.bin, lpddr4_pmu_train_1d_imem.bin, lpddr4_pmu_train_2d_dmem.bin, lpddr4_pmu_train_2d_imem.bin
  • Kernel: Image
  • Kernel device tree file: oftree
  • Root filesystem: phytec-headless-image-phygate-tauri-l-imx8mm-1.tar.gz, phytec-headless-image-phygate-tauri-l-imx8mm-1.manifest
  • SD card image: phytec-headless-image-phygate-tauri-l-imx8mm-1.sdcard


Tip

The default Linux image phytec-headless-image will start a Wayland Weston, even if there is no display connected.

System Booting

The default boot source for the i.MX 8M Mini module phyGATE-Tauri is eMMC. But for the alpha release, the BSP is available on SD-Card. To update the software on eMMC, see Updating Software.

Booting from eMMC

To boot from eMMC, make sure that the BSP image is flashed correctly to the flash. 

Booting from SD Card

Booting from the SD card is useful in several situations, e.g. if the board does not start anymore due to a damaged bootloader.

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

  1. A single, prebuilt SD card image
  2. The four individual images (u-boot-, kernel- and device tree image, and root filesystem)

Single, Prebuilt SD Card Image

The first possibility is to use the SD card image built by Bitbake, a tool integrated into Yocto. This image has the ending *.sdcard and can be found under build/deploy/images/phygate-tauri-l-imx8mm-2/phytec-headless-image-phygate-tauri-l-imx8mm-2.sdcard. It contains all BSP files in correctly preformatted partitions and can be copied to the SD card easily using the single Linux command dd.

Tip

The created file phytec-headless-image-phygate-tauri-l-imx8mm-2.sdcard is only a link to a file like phytec-headless-image-phygate-tauri-l-imx8mm-2-<BUILD-TIME>.rootfs.sdcard.


Warning

To create your bootable SD card with the dd command, you must have root privileges. Because of this, you must be very careful when selecting the destination device for the dd command! All files on the selected destination device will be erased immediately without any further query! Consequently, having selected the wrong device can also erase your hard drive!

To create your bootable SD card, you must first find the correct device name of your SD card and possible partitions. Then unmount the partitions before you start copying the image to the SD card.

  • In order to get the correct device name, first remove your SD card and execute ls /dev.
  • Now insert your SD card and execute ls /dev again.
  • Compare the two outputs to find the new device name(s) listed in the second output. These are the device names of the SD card (device and partitions if the SD card is formatted).
  • In order to verify the device names found, execute the command dmesg. Within the last lines of its output, you should also find the device names, for example, sde (depending on your system).

Now that you have the device name /dev/<your_device> (e.g. /dev/sde), you can see the partitions which must be unmounted if the SD card is formatted. In this case, you will also find /dev/<your_device> with an appended number (e.g. /dev/sde1) in the output. These represent the partition(s) that need to be unmounted.

  • Unmount all partitions with:
host$ umount /dev/<your_device><number>
  • After having unmounted all devices with an appended number (<your_device><number>), you can create your bootable SD card with:
host$ sudo dd of=/dev/<your_device> if=phytec-headless-image-phygate-tauri-l-imx8mm-2.sdcard bs=1MB conv=fsync status=progress
  • If you use the image file created by Bitbake instead:
host$ sudo dd of=/dev/<your_device> if=phytec-headless-image-phygate-tauri-l-imx8mm-2-<BUILD-TIME>.sdcard bs=1MB conv=fsync status=progress

Using the device name (<your_device>) without appended number (e.g. sde) which stands for the whole device. The parameter conv=fsync forces a sync operation on the device before dd returns. This ensures that all blocks are written to the SD card and are not still in memory. The parameter status=progress will print out information on how much data is and still has to be copied until it is finished.

<BUILD-TIME> has the format: YYYYMMDDHHMMSS

example: 
    Date = 22.06.2018
    Time = 11:06:36
    <BUILD-TIME> = 20180622110636

Four Individual Images (imx-boot, kernel image, device tree image, root filesystem)

Option two uses u-boot (a kernel and device tree image together with the root filesystem) to create a bootable SD card manually.

For this method, a new card must be set up with 2 partitions and 8 MB of free space at the beginning of the card. Use the following procedure with fdisk under Linux:

  • Create a new FAT partition with partition ID C. When creating the new partition, you must leave 8 MB of free space at the beginning of the card. When you go through the process of creating a new partition, fdisk lets you specify where the first sector starts. During this process, fdisk will tell you where the first sector on the disk begins. For example, if the first sector begins at 1000 and each sector is 512 bytes, then 8 MB / 512 bytes = 16384 sectors. This means your first sector should begin at 17384 to leave 8 MB of free space. The size of the FAT partition needs only be big enough to hold the Linux kernel image, which is only a few megabytes. To be safe, we recommend a size of 64 MB.
  • Create a new Linux partition with partition id 83. Make sure you start this partition after the last sector of partition 1! By default, fdisk will try to use the first partition available on the disk, which in this example is 1000. However, this is our reserved space! You must use the remaining portion of the card for this partition.
  • Write the new partition to the SD card and exit fdisk.

Example:

  • Type:
host$ sudo fdisk -l /dev/sdc
  • You will receive:
Disk /dev/sdc: 4025 MB, 4025483264 bytes
4 heads, 32 sectors/track, 61424 cylinders, total 7862272 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x26edf128
 
Device Boot    Start       End      Blocks   Id  System
  /dev/sdc1     8192     24575        8192    c  W95 FAT32 (LBA)
  /dev/sdc2    24576    655359      315392   83  Linux
  • Remove and reinsert the card. Otherwise, Linux will not recognize the new partitions created in the previous step.
  • Create a file system on the partitions with (replace sde with your device):
host$ sudo mkfs.vfat /dev/sde1
host$ sudo mkfs.ext4 -L "rootfs" /dev/sde2

Now, the images need to be copied to the SD card.

  • Write the bootloader in front of the first partition (replace sde with your device):
host$ dd if=u-boot-phygate-tauri-l-imx8mm-2.bin of=/dev/sde bs=1k seek=33 conv=fsync
  • Mount the first partition (vfat) and copy the Image and oftree file to it:
host$ sudo mount /dev/sd<X>1 /mnt


Warning

Make sure that the images are named exactly as previously mentioned as the bootloader expects them to be named as such.

  • In case you want to boot the whole Linux from the SD card, also mount the ext4 partition.
  • Then untar <IMAGENAME>-<MACHINE>.tar.gz rootfs image to it:
host$ sudo mount /dev/sd<X>2 /media
host$ sudo tar xfz <IMAGENAME>-<MACHINE>.tar.gz -C /media/
  • Do not forget to properly unmount the SD card with:
host$ sudo umount /media

Booting the Kernel from Network

Booting from the network means loading the kernel over TFTP and the root filesystem over NFS. The bootloader itself must already be loaded from another boot device that is available.

Development Host Preparations

On the development host, a TFTP server must be installed and configured. The following tool will be needed to boot the kernel from Ethernet:

  1. A TFTP server
  • For Ubuntu install:
host$ sudo apt-get install tftpd-hpa

After the installation of the packages, you have to configure the TFTP server.

TFTP Server Set-Up

  • Edit /etc/default/tftpd-hpa:
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/tftpboot"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="--secure"
  • Create a directory to store the TFTP files:
host$ sudo mkdir /tftpboot
host$ sudo chmod -R 777 /tftpboot
host$ sudo chown -R nobody /tftpboot
  • Configure a static IP address for the appropriate interface:
host$ ifconfig eth1

You will receive:

eth1      Link encap:Ethernet  HWaddr 00:11:6b:98:e3:47  
          inet addr:192.168.3.10  Bcast:192.168.3.255  Mask:255.255.255.0
  • Restart the services to pick up the configuration changes:
host$ sudo service tftpd-hpa restart
  • Now connect the Ethernet port of the board to your host system, configure the board to network boot, and start it.

Usually, TFTP servers fetch files from the /tftpboot directory. If you built your own images, please copy them from the BSP’s build directory to the /tftpboot directory.

We also need a network connection between the embedded board and the TFTP server. The server should be set to IP 192.168.3.10 and netmask 255.255.255.0.

After the installation of the TFTP server, an NFS server also needs to be installed. The NFS server is not restricted to a certain file system location, so all we have to do on most distributions is modify the file /etc/exports and export our root filesystem to the embedded network. In this example file, the whole work directory is exported and the ”lab network” address of the development host is 192.168.3.10. The IP addresses have to be adapted to local needs:

/home/<user>/<rootfspath> 192.168.3.10/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)

<user> must be replaced with your home directory name. <rootfspath> can be set to a folder that contains a rootfstar.gz image extracted with sudo.Updating Software 

In this section, we explain how to use the u-boot bootloader on target or linux on target/host to update the images in eMMC.

Updating eMMC via Network

i.MX 8M Mini boards have an Ethernet connector and can be updated over a network. Be sure to set up the development host correctly. The IP needs to be set to 192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be available.

From a high-level point of view, an eMMC device is like an SD card. Therefore, it is possible to flash the image <name>.sdcard (or <name>.sdcard.bz2) from the Yocto build system directly to the eMMC. The image contains the bootloader, kernel, device trees, and root filesystem.

Updating eMMC in Linux on Target

You can update the eMMC from your target.

Tip

A working network is necessary!

  • Take an uncompressed or compressed image on the host and send it with ssh through the network (then uncompress it, if necessary) to the eMMC of the target with a one-line command:
target$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-headless-image-phygate-tauri-l-imx8mm-2.sdcard" | dd of=/dev/mmcblk2

Updating eMMC in Linux on Host

It is also possible to update the eMMC from your Linux host. As before, you need a complete image on your host.

Tip

A working network is necessary!

  • Show your available image-files on the host:
host$ ls
phytec-headless-image-phygate-tauri-l-imx8mm-2.sdcard
  • Uncompress and send image with dd command combined with ssh through the network to the eMMC of your device:
host$ dd if=phytec-headless-image-phygate-tauri-l-imx8mm-2.sdcard status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2"

Updating eMMC via SD Card

Even if there is no network available, you can update the eMMC. For that, you only need a ready-to-use image file (*.sdcard) located on the SD card. Because the image file is quite large, you have to enlarge your SD card to use its full space (if it was not enlarged before). To enlarge your SD card, see Resizing ext4 Root Filesystem.

Updating eMMC via SD Card in Linux on Target

You can also update the eMMC under Linux. You only need a complete image saved on the SD card (e.q. phytec-headless-image-phygate-tauri-l-imx8mm-2.sdcard).

  • Show your saved image files on the SD card:
target$ ls
phytec-headless-image-phygate-tauri-l-imx8mm-2.sdcard
  • Show list of available MMC devices:
target$ ls /dev | grep mmc
mmcblk1
mmcblk1p1
mmcblk1p2
mmcblk2
mmcblk2boot0
mmcblk2boot1
mmcblk2p1
mmcblk2p2
mmcblk2rpmb
  • Write the image to the eMMC of phyGATE-Tauri (MMC device 2 WITHOUT partition):
target$ dd if=phytec-headless-image-phygate-tauri-l-imx8mm-2.sdcard of=/dev/mmcblk2
  • After a complete write, your board can boot from eMMC.

RAUC

The Robust Auto-Update Controller (RAUC) mechanism is a new addition to Yogurt. PHYTEC has written an online manual on how we have intergraded RAUC into our BSPs (L-1006e.A0 RAUC Update & Device Management Manual).

Device Tree (DT)

Introduction

The following text briefly describes the Device Tree and can be found in the Linux kernel (linux/Documentation/devicetree/usage-model.txt).

"The "Open Firmware Device Tree", or simply Device Tree (DT), is a data structure and language for describing hardware. More specifically, it is a description of hardware that is readable by an operating system so that the operating system doesn't need to hardcode details of the machine.
Structurally, the DT is a tree or acyclic graph with named nodes, and nodes may have an arbitrary number of named properties encapsulating arbitrary data. A mechanism also exists to create arbitrary links from one node to another outside of the natural tree structure.
Conceptually, a common set of usage conventions called 'bindings', is defined for how data should appear in the tree to describe typical hardware characteristics including data busses, interrupt lines, GPIO connections, and peripheral devices."

The kernel is a really good source for a DT introduction. An overview of the device tree data format can be found on the device tree usage page at devicetree.org:

http://devicetree.org/Device_Tree_Usage

PHYTEC i.MX 8M Mini BSP Device Tree Concept

The following sections explain some rules we have defined on how to set up device trees for our i.MX 8M Mini SoC-based boards.

DT Structure

The module includes file Modul .dtsi which contains all devices which are mounted on the module, such as PMIC and RAM. Devices which come from the i.MX 8M Mini SoC but are just routed down to the carrier board are not part of the Module .dtsi. These devices are included in the Carrierboard .dtsi. The Board .dts includes the carrier board and module nodes. It also adds partition tables and enables all hardware configurable nodes of the carrier board or the module (i.e. the Board .dts shows the special characteristics of the board configuration). For example, there are phyCORE-i.MX 8M Mini SOMs may or may not have a MIPI DSI to LVDS converter mounted. The converter is enabled (if available) in the Board .dts and not in the Module .dtsi.

Accessing Peripherals

To find out which boards and modules are supported by the release of PHYTEC’s i.MX8 BSP described herein, visit our web page at http://www.phytec.de/produkte/software/yocto/phytec-unified-yocto-bsp-releases/ and click the corresponding BSP release. here you can find all hardware supported in the columns "Hardware Article Number" and the correct machine name in the corresponding cell under "Machine Name". (BSP-Yocto_Machines)

For information about all our supported i.MX8 variants, visit our web page at http://www.phytec.de/produkte/nxp/imx-8/.

To achieve maximum software re-use, the Linux kernel offers a sophisticated infrastructure that layers software components into board-specific parts. The BSP tries to modularize the kit features as far as possible. This means that when a customized baseboard or even a customer-specific module is developed, most of the software support can be re-used without error-prone copy-and-paste. The kernel code corresponding to the boards can be found in device trees (DT) under linux/arch/arm64/boot/dts/freescale/*.dts*.

In fact, software re-use is one of the most important features of the Linux kernel, especially of the ARM implementation which always has to fight with an insane number of possibilities of the System-on-Chip CPUs. The whole board-specific hardware is described in DTs and is not part of the kernel image itself. The hardware description is in its own separate binary, called the Device Tree Blob (DTB) (section Device Tree (DT)). 

Please read section PHYTEC i.MX 8M Mini BSP Device Tree Concept to get an understanding of our i.MX8 BSP device tree model. 

The following sections provide an overview of the supported hardware components and their operating system drivers on the i.MX8 platform. Further changes can be ported upon customer request.

i.MX 8M Mini Pin Muxing

The i.MX 8M Mini SoC contains many peripheral interfaces. In order to reduce package size and lower overall system cost while maintaining maximum functionality, many of the i.MX 8M Mini terminals can multiplex up to eight signal functions. Although there are many combinations of pin multiplexing that are possible, only a certain number of sets called IO sets, are valid due to timing limitations. These valid IO sets were carefully chosen to provide many possible application scenarios for the user.

Please refer to the NXP i.MX 8M Mini Reference Manual for more information about the specific pins and the muxing capabilities.

The IO set configuration, also called muxing, is done in the Device Tree. The driver pinctrl-single reads the DT's node fsl,pins, and does the appropriate pin muxing.

The following is an example of the pin muxing of the UART1 device in phytec-imx8mm-phyGATE-Tauri.dtsi:

 pinctrl_uart1: uart1grp {
 	fsl,pins = <
		MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
		MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
		MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
		MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
	>;
};

The first part of the string MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad (in this example SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the desired muxing option for this pad.

The pad setting value (hex value on the right) defines different modes of the pad. For example, if internal pull resistors are activated or not. In this case, the internal resistors are disabled.

Serial TTYs

The i.MX 8M Mini SoC provides up to 4 so-called UART units. PHYTEC boards support different numbers of these UART units.  To use UART1 in the Alpha Kit, the S1 POS3 has to be set to ON.

  • From the command line prompt of Linux userspace, you can easily check the availability of other UART interfaces with:
target$ echo "test" > /dev/ttymxc2

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. The following example shows how to copy all serial settings from ttymxc2 to ttymxc0.

  • First, get the current parameters with:
target$ stty -F /dev/ttymxc2 -g


5500:5:1cb2:a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
  • Now use the output from the stty command above as an argument for the next command:
target$ stty -F /dev/ttymxc0 5500:5:1cb2:a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Device Tree example of phytec-imx8mm-phyGATE-Tauri.dtsi:

/* UART - RS485 */
&uart1 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_uart1>;
        assigned-clocks = <&clk imx8mm_CLK_UART1>;
        assigned-clock-parents = <&clk imx8mm_SYS_PLL1_80M>;
        status = "okay";
        uart-has-rtscts;
};

[...]

&iomuxc {         imx8mm-phyGATE-Tauri {

[...]
                pinctrl_uart1: uart1grp {
                        fsl,pins = <
                                MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
                                MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
                                MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
                                MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
                        >;
                };

[...]
	    };
};

RS-485

UART1 of the phyGATE-Tauri can also be used as RS-485. For this, S1 POS5 and POS3 have to be set to on. We use the same device tree node for UART1 and RS-485. RS-485 mode can be enabled with ioctl TIOCSRS485.

For easy testing, use the linux-serial-test. This tool will call the IOCTL for RS485 and constantly send a stream of data:

  • Execute:
 target$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0

More information about the linux-serial-test tool and its parameters can be found here: https://github.com/cbrake/linux-serial-test

Documentation for calling the IOCTL within c-code is described in the Linux kernel documentation: htthttps://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

Network

A gigabit Ethernet is provided by our module and board. All interfaces offer a standard Linux network port which can be programmed using the BSD socket interface. The whole network configuration is handled by the systemd-networkd daemon. The relevant configuration files can be found on the target in /lib/systemd/network/ and also in the BSP in meta-yogurt/recipes-core/systemd/system-machine-units.

IP addresses can be configured within *.network files. The default IP address and netmask for eth0 are:

eth0: 192.168.3.11/24

The DT Ethernet setup might be split into two files depending on your hardware configuration: the module DT, and the board-specific DT.

Module DT, arch/arm64/boot/dts/freescale/phytec-imx8mm-phycore-som.dtsi:

[…]
#include <dt-bindings/net/ti-dp83867.h>
[…]

&fec1 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_fec1>;
	phy-mode = "rgmii-id";
	phy-handle = <&ethphy0>;
	fsl,magic-packet;
	status = "okay";

	mdio {
		#address-cells = <1>;
		#size-cells = <0>;

		ethphy0: ethernet-phy@0 {
			compatible = "ethernet-phy-ieee802.3-c22";
			reg = <0>;
			interrupt-parent = <&gpio1>;
			interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
			ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
			ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
			ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
			ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
			enet-phy-lane-no-swap;
		};
	};
};

[…]

&iomuxc {
        pinctrl-names = "default";          imx8mm-phycore {

                pinctrl_fec1: fec1grp {
                        fsl,pins = <
                                MX8MM_IOMUXC_ENET_MDC_ENET1_MDC         0x3
                                MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO       0x3
                                MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3   0x1f
                                MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2   0x1f
                                MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1   0x1f
                                MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0   0x1f
                                MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3   0x91
                                MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2   0x91
                                MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1   0x91
                                MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0   0x91
                                MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC   0x1f
                                MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC   0x91
                                MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL     0x91
                                MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL     0x1f
                                MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7               0x19
                                MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1               0x19
                        >;
                };
[…]

};

SD / MMC Card

The i.MX 8M Mini alpha release kit supports a slot for Secure Digital Cards and MultiMedia Cards to be used as general-purpose block devices. These devices can be used in the same way as any other block device.

Warning

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not to unplug the device while it is still mounted. This may result in data loss!

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

/dev/mmcblk1p<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.

Tip

These partition device nodes will only be available if the card contains a valid partition table (”hard disk” like handling). If it does not contain one, the whole device can be used as a file system (”floppy” like handling). In this case, /dev/mmcblk1 must be used for formatting and mounting.

The cards are always mounted as being writable.

DT configuration for the MMC (SD card slot) interface in arch/arm64/boot/dts/freescale/phytec-imx8mm-phyGATE-Tauri.dtsi:

[…]

/* SD-Card */
&usdhc2 {
        vqmmc-supply = <&reg_ldo2>;
        pinctrl-names = "default", "state_100mhz", "state_200mhz";
        pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
        pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
        pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
        cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
        bus-width = <4>;
        status = "okay";
        no-1-8-v;
};

[…]

&iomuxc {         imx8mm-phyGATE-Tauri {

                […]

                pinctrl_usdhc2_gpio: usdhc2grpgpio {
                        fsl,pins = <
                                MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12        0x41
                        >;
                };

                pinctrl_usdhc2: usdhc2grp {
                        fsl,pins = <
                                MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK         0x190
                                MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD         0x1d0
                                MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0     0x1d0
                                MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1     0x1d0
                                MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2     0x1d0
                                MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3     0x1d0
                                MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT  0x1d0
                        >;
                };

                pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
                        fsl,pins = <
                                MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK         0x194
                                MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD         0x1d4
                                MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0     0x1d4
                                MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1     0x1d4
                                MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2     0x1d4
                                MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3     0x1d4
                                MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT  0x1d0
                        >;
                };

                pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
                        fsl,pins = <
                                MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK         0x196
                                MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD         0x1d6
                                MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0     0x1d6
                                MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1     0x1d6
                                MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2     0x1d6
                                MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3     0x1d6
                                MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT  0x1d0
                        >;
                };

                […]
        };
};

DT configuration for the eMMC interface in arch/arm64/boot/dts/freescale/phytec-imx8mm-phycore-som.dtsi:

[…]

&usdhc3 {
        vqmmc-supply = <&reg_sw6>;
        pinctrl-names = "default", "state_100mhz", "state_200mhz";
        pinctrl-0 = <&pinctrl_usdhc3>;
        pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
        pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
        bus-width = <8>;
        non-removable;
        status = "okay";
};

[…]

&iomuxc {         imx8mm-phycore {

                […]

                pinctrl_usdhc3: usdhc3grp {
                        fsl,pins = <
                                MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK               0x190
                                MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD               0x1d0
                                MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0           0x1d0
                                MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1           0x1d0
                                MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2           0x1d0
                                MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3           0x1d0
                                MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4             0x1d0
                                MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5            0x1d0
                                MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6            0x1d0
                                MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7              0x1d0
                                MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE           0x190
                        >;
                };

                pinctrl_usdhc3_100mhz: usdhc3grp100mhz {
                        fsl,pins = <
                                MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK               0x194
                                MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD               0x1d4
                                MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0           0x1d4
                                MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1           0x1d4
                                MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2           0x1d4
                                MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3           0x1d4
                                MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4             0x1d4
                                MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5            0x1d4
                                MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6            0x1d4
                                MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7              0x1d4
                                MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE           0x194
                        >;
                };

                pinctrl_usdhc3_200mhz: usdhc3grp200mhz {
                        fsl,pins = <
                                MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK               0x196
                                MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD               0x1d6
                                MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0           0x1d6
                                MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1           0x1d6
                                MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2           0x1d6
                                MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3           0x1d6
                                MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4             0x1d6
                                MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5            0x1d6
                                MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6            0x1d6
                                MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7              0x1d6
                                MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE           0x196
                        >;
                };

              […]
        };
};

eMMC Devices

PHYTEC modules like phyCORE-i.MX 8M Mini are populated with an eMMC memory chip as main storage. eMMC devices contain raw MLC memory cells combined with a memory controller that handles ECC and wear leveling. They are connected via an MMC/SD interface to the i.MX 8M Mini and are represented as block devices in the Linux kernel like SD cards, flash drives, or hard disks.

The electric and protocol specifications are provided by JEDEC (https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). The eMMC manufacturer's datasheet is relatively short and meant to be read together with the supported version of the JEDEC eMMC standard.

PHYTEC currently utilizes the eMMC chips:

eMMC ChipSizeJEDEC Version
MTFC16GAPALBH-IT 16 GB5.1

Extended CSD Register

eMMC devices have an extensive amount of extra information and settings that are available via the Extended CSD registers. For a detailed list of the registers, see manufacturer datasheets and the JEDEC standard.

  • In the Linux user space, you can query the registers with:
target$ mmc extcsd read /dev/mmcblk2

You will see:

 =============================================
   Extended CSD rev 1.8 (MMC 5.1)
 =============================================
 
 Card Supported Command sets [S_CMD_SET: 0x01]
 [...]

Enabling Background Operations (BKOPS)

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer (FTL) that handles the wear leveling, block management, and ECC of the raw MLC cells. This requires some maintenance tasks (for example erasing unused blocks) that are performed regularly. These tasks are called Background Operations (BKOPS).

By default (depending on the chip), the background operations may or may not be executed periodically which impacts the worst-case read and write latency.

The JEDEC Standard has specified a method since version v4.41 that the host can issue BKOPS manually. See the JEDEC Standard chapter Background Operations and the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in the eMMC datasheet for more details.

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

  • Value 0: The host does not support the manual trigger of BKOPS. Device write performance suffers.
  • Value 1: The host does support the manual trigger of BKOPS. It will issue BKOPS from time to time when it does not need the device.

The mechanism to issue background operations has already been implemented in the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device (see below for details).

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the host to trigger the background operations regularly because the device starts BKOPS itself when it is idle (see the description of bit AUTO_EN in register BKOPS_EN (Reg: 163)).

The userspace tool mmc does not support enabling automatic BKOPS features so far.

  • To check whether BKOPS_EN is set, execute:
target$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN

The output will be, for example:

Enable background operations handshake [BKOPS_EN]: 0x01
#OR
Enable background operations handshake [BKOPS_EN]: 0x00

Where value 0x00 means BKOPS_EN is disabled and device write performance suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue background operations from time to time.

  • To set the BKOPS_EN bit, execute:
target$ mmc bkops enable /dev/mmcblk0
  • To ensure that the new setting is taken over and the kernel triggers BKOPS by itself, shut down the system with:

Tip

The BKOPS_EN bit is a one-time-programmable only. It cannot be reversed.

Reliable Write

There are two different Reliable Write options:

  1. Reliable Write option for a whole eMMC device/partition.
  2. Reliable Write for single write transactions.

Tip

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT partition table (see the previous section).

The first Reliable Write option can be enabled with the mmc tool:

target$ mmc --help
 
[...]
mmc write_reliability set <-y|-n> <partition> <device>

The second Reliable Write option is the configuration bit Reliable Write Request parameter (bit 31) in command CMD23. It has been used in the kernel since v3.0 by file systems, e.g. ext4 for the journal and user space applications such as fdisk for the partition table. In the Linux kernel source code, it is handled via flag REQ_META.

Conclusion: ext4 file system with mount option data=journal should be safe against power cuts. The file system check can recover the file system after a power failure, but data that was written just before the power cut may be lost. In any case, a consistent state of the file system can be recovered. To ensure data consistency for the files of an application, the system functions fdatasync or fsync should be used in the application.

Resizing ext4 Root Filesystem

fdisk can be used to expand the root filesystem. The example works for any block device such as eMMC, SD card, or hard disk.

  • Get the current device size:
target$ fdisk -l /dev/mmcblk2
  • The output looks like:
Disk /dev/mmcblk2: 15 GB, 15913189376 bytes, 31080448 sectors
485632 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device       Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/mmcblk2p1 *  64,0,1      762,2,28          8192      97627      89436 43.6M  c Win)
/dev/mmcblk2p2    768,0,1     1023,3,32        98304     950271     851968  416M 83 Linx
  • Use fdisk to delete and create a partition with a max size of the device:
target$ fdisk /dev/mmcblk2
 
The number of cylinders for this disk is set to 485632.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p
Disk /dev/mmcblk2: 15 GB, 15913189376 bytes, 31080448 sectors
485632 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device       Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/mmcblk2p1 *  64,0,1      762,2,28          8192      97627      89436 43.6M  c Win)
/dev/mmcblk2p2    768,0,1     1023,3,32        98304     950271     851968  416M 83 Linx

Command (m for help): d
Partition number (1-4): 2

Command (m for help): p
Disk /dev/mmcblk2: 15 GB, 15913189376 bytes, 31080448 sectors
485632 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device       Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/mmcblk2p1 *  64,0,1      762,2,28          8192      97627      89436 43.6M  c Win)

Command (m for help): n
Partition type
   p   primary partition (1-4)
   e   extended
p
Partition number (1-4): 2
First sector (16-31080447, default 16): 98304
Last sector or +size{,K,M,G,T} (98304-31080447, default 31080447): 
Using default value 31080447

Command (m for help): p
Disk /dev/mmcblk2: 15 GB, 15913189376 bytes, 31080448 sectors
485632 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device       Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/mmcblk2p1 *  64,0,1      762,2,28          8192      97627      89436 43.6M  c Win)
/dev/mmcblk2p2    1023,3,16   1023,3,16        98304   31080447   30982144 14.7G 83 Linx
 
target$

Increasing the file system size can be done while it is mounted. An on-line resizing operation is performed. But you can also boot the board from an SD card and then resize the file system on the eMMC partition while it is not mounted. Furthermore, the board has to be rebooted so that the new partition table will be read.

Erasing the Device

It is possible to erase the eMMC device directly rather than overwriting it with zeros. The eMMC block management algorithm will erase the underlying MLC memory cells or mark these blocks as discard. The data on the device is lost and will be read back as zeros.

  • After booting from the SD card execute:
target$ blkdiscard --secure /dev/mmcblk2

The option --secure ensures that the command waits until the eMMC device has erased all blocks.

Tip

dd if=/dev/zero of=/dev/mmcblk0 also destroys all information on the device, but this command is bad for wear leveling and takes much longer!

SPI Master

The i.MX 8M Mini controller has a FlexSPI and an ECSPI IP core included. The FlexSPI host controller supports two SPI channels with up to 4 devices. Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip select for each interface. As chip selects should be realized with GPIOs, more than one device on each channel is possible.

SPI NOR flash

phyCORE-i.MX 8M Mini is equipped with a QSPI NOR Flash which connects to the i.MX 8M Mini's FlexSPI interface. The QSPI NOR Flash is suitable for booting.  However, this is not supported in the current hardware revision. From Linux userspace, the NOR Flash partitions are accessible via /dev/mtd<N> devices where <N> is the MTD device number associated with the NOR flash partition to access. To find the correct MTD device number for a partition, run on the target:

mtdinfo --all

It lists all MTD devices and the corresponding partition names. The flash node is defined inside the SPI master node in the module DTS. The SPI node contains all devices connected to this SPI bus which is in this case only the SPI NOR Flash.

Definition of the SPI master node in imx6qdl-phytec-phycore-som.dtsi :

&flexspi {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_flexspi0>;
        status = "okay";

        flash0: mt25qu256aba@0 {
                reg = <0>;
                #address-cells = <1>;
                #size-cells = <1>;
                compatible = "micron,mt25qu256aba";
                spi-max-frequency = <80000000>;
                spi-nor,ddr-quad-read-dummy = <6>;
        };
};

[...]

&iomuxc {
        pinctrl-names = "default";          imx8mm-phycore {

[...]
               pinctrl_flexspi0: flexspi0grp {
                        fsl,pins = <
                                MX8MM_IOMUXC_NAND_ALE_QSPI_A_SCLK               0x1c2
                                MX8MM_IOMUXC_NAND_CE0_B_QSPI_A_SS0_B            0x82
                                MX8MM_IOMUXC_NAND_DATA00_QSPI_A_DATA0           0x82
                                MX8MM_IOMUXC_NAND_DATA01_QSPI_A_DATA1           0x82
                                MX8MM_IOMUXC_NAND_DATA02_QSPI_A_DATA2           0x82
                                MX8MM_IOMUXC_NAND_DATA03_QSPI_A_DATA3           0x82
                        >;
                };
[...]
        };
};

GPIOs

The phyGATE-Tauri has a set of pins especially dedicated as user I/Os. Those pins are connected directly to i.MX 8M Mini pins and are muxed as GPIOs. They are directly usable in Linux userspace. The processor has organized its GPIOs into five banks of 32 GPIOs each (GPIO1 – GPIO5) and one bank with 32 GPIOs. gpiochip0gpiochip32gpiochip64gpiochip96, and gpiochip128 are the sysfs representation of these internal i.MX 8M Mini GPIO banks GPIO1 – GPIO5.

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> is being counted from 0 to 31 (32 GPIOs on each bank).

By contrast, the Linux kernel uses a single integer to enumerate all available GPIOs in the system. The formula to calculate the right number is:

Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>

Accessing GPIOs from userspace will be done using the libgpiod. It provides a library and tools for interacting with the Linux GPIO character device. Examples of the usage for some of the tools:

  • Detecting the gpiochips on the chip:
target$ gpiodetect
gpiochip0 [30200000.gpio] (32 lines)
gpiochip1 [30210000.gpio] (32 lines)
gpiochip2 [30220000.gpio] (32 lines)
gpiochip3 [30230000.gpio] (32 lines)
gpiochip4 [30240000.gpio] (32 lines)
  • Show detailed information about the gpiochips. Like their names, consumers, direction, active state, and additional flags:
target$ gpioinfo gpiochip0
  • Read the value of a gpio (e.g gpio 20 from chip0):
target$ gpioget gpiochip0 20
  • Set value of gpio 20 on chip0 to 0 and exit tool:
target$ gpioset --mode=exit gpiochip0 20=0
  • The help text of gpioset shows possible options:
target$ gpioset --help
Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
Set GPIO line values of a GPIO chip

Options:
  -h, --help:           display this message and exit
  -v, --version:        display the version and exit
  -l, --active-low:     set the line active state to low
  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
                tell the program what to do after setting values
  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time
)
  -b, --background:     after setting values: detach from the controlling terminal

Modes:
  exit:         set values and exit immediately
  wait:         set values and wait for user to press ENTER
  time:         set values and sleep for a specified amount of time
  signal:       set values and wait for SIGINT or SIGTERM


Warning

Some of the user IOs are used for special functions. Before using a user IO, refer to the schematic or the hardware manual of your board to ensure that it is not already in use.

Pinmuxing of some GPIO pins in the device tree phytec-imx8mm-phyGATE-Tauri.dtsi:

                pinctrl_leds: leds1grp {
                        fsl,pins = <
                                MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0       0x16
                                MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
                                MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
                        >;
                };

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 thus 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
led-yellow@  led-red@

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyGATE-Tauri.

  • To toggle the LEDs ON, use:
target$ echo 255 > /sys/class/leds/led-red/brightness
  • To toggle OFF:
target$ echo 0 > /sys/class/leds/led-red/brightness
  • User I/O configuration in device tree file arch/arm64/boot/dts/freescale/phytec-imx8mm-phyGATE-Tauri.dtsi:
/ {
        leds {
                compatible = "gpio-leds";
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_leds>;

                led-red {
                        label = "red-emmc";
                        gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
                        linux,default-trigger = "mmc0";
                };

                led-blue {
                        label = "blue-mmc";
                        gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
                        linux,default-trigger = "mmc1";
                };

                led-green {
                        label = "green-heartbeat";
                        gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>;
                        linux,default-trigger = "heartbeat";
                };
        };

        […]

};

&iomuxc {        imx8mm-phyGATE-Tauri {
			    
				[…]
                
				pinctrl_leds: leds1grp {
                        fsl,pins = <
                                MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0       0x16
                                MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
                                MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
                        >;
                };

				[…]
};

I2C Bus

The i.MX 8M Mini contains three Multimaster fast-mode I²C modules called I2C1, I2C2, I2C3, and I2C4. PHYTEC boards provide plenty of different I²C devices connected to the I²C modules of the i.MX 8M Mini. This chapter will describe the basic device usage and its DT representation of some of the I²C devices integrated on our phyGATE-Tauri.

General I²C1 bus configuration (e.g. phytec-imx8mm-phycore-som.dtsi):

&i2c1 {
        clock-frequency = <400000>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_i2c1>;
        status = "okay";
        [...]
};

&iomuxc {         imx8mm-phycore {
                pinctrl_i2c1: i2c1grp {
                        fsl,pins = <
                                MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL                  0x400001c3
                                MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA                  0x400001c3
                        >;
                };
        };
};

General I²C2 bus configuration (e.g. phytec-imx8mm-phyGATE-Tauri.dtsi):

&i2c2 {
        clock-frequency = <400000>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_i2c2>;
        status = "okay";
};

&iomuxc {         imx8mm-phyGATE-Tauri {
                pinctrl_i2c2: i2c2grp {
                        fsl,pins = <
                                MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL          0x400001c3
                                MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA          0x400001c3
                        >;
                };
        };
};

EEPROM

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

cat /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
  • To read and print the first 1024 bytes of the EEPROM as a hex number, execute:
target$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/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-0/device/0-0051/eeprom bs=4096 count=1

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

DT representation, e.g. in phyCORE-i.MX 8M Mini file phytec-imx8mm-phycore-som.dtsi:

&i2c1 {
        clock-frequency = <400000>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_i2c1>;
        status = "okay";

        […]
        
	    eeprom: m24c32@51 {
                compatible = "atmel,24c32";
                reg = <0x51>;
                status = "okay";
        };
};

[…]

&iomuxc {         imx8mm-phycore {

                […]

                 pinctrl_i2c1: i2c1grp {
                        fsl,pins = <
                                MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL                  0x400001c3
                                MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA                  0x400001c3
                        >;
                };

                […]

        };
};

RTC

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than one RTC, there might be more than one RTC device file.

  • To find the name of the RTC device, you can read its sysfs entry with:
target$ cat /sys/class/rtc/rtc*/name
  • You will get, for example:
rtc-rv3028 0-0052
snvs_rtc 30370000.snvs:snvs-rtc-lp


Tip

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device IDs based on the device tree/aliases entries if present.

Date and time can be manipulated with the hwclock tool, using the -w (systohc) and -s (hctosys) options. To set the date, first use date and then run hwclock -w -u to store the new date into the RTC. For more information about this tool, refer to the manpage of hwclock.

DT representation for I²C RTCs: phytec-imx8mm-phycore-som.dtsi:

        rv3028: rv3028@52 {
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_rtc>;
                compatible = "microcrystal,rv3028";
                reg = <0x52>;
                interrupt-parent = <&gpio1>;
                interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
                wakeup-source;
                trickle-resistor-ohms = <1000>; /* maps to 3 kOhm setting */
                enable-level-switching-mode;
        };

USB Host Controller

The USB controller of the i.MX 8M Mini SoC provides a low-cost connectivity solution for numerous consumer portable devices by providing a mechanism for data transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed 'HS'). The USB subsystem has two independent USB controller cores. Both cores are On-The-Go (OTG) controller cores and capable of acting as a USB peripheral device or a USB host. Each is connected to a USB 2.0 PHY.

The unified BSP includes support for mass storage devices and keyboards. Other USB-related device drivers must be enabled in the kernel configuration on demand.

Due to udev, all mass storage devices connected get unique IDs and can be found in /dev/disks/by-id. These IDs can be used in /etc/fstab to mount the different USB memory devices in different ways.

User USB2 (host) configuration is in the kernel device tree phytec-imx8mm-phyGATE-Tauri.dtsi:

[…]

&usbotg2 {
        dr_mode = "host";
        picophy,pre-emp-curr-control = <3>;
        picophy,dc-vol-level-adjust = <7>;
        status = "okay";
};

[…]

USB OTG

Most PHYTEC boards provide a USB OTG interface. USB OTG ports automatically act as a USB device or USB host. The mode depends on the USB hardware attached to the USB OTG port. If, for example, a USB mass storage device is attached to the USB OTG port, the device will show up as /dev/sda.

USB Device

In order to connect the board's USB device to a USB host port (for example a PC), you need to configure the appropriate USB gadget. With USB configfs you can define the parameters and functions of the USB gadget. The BSP includes USB configfs support as a kernel module.

target$ modprobe libcomposite

Example:

  • First, define the parameters such as the USB vendor and product IDs and set the information strings for the English (0x409) language:
target$ cd /sys/kernel/config/usb_gadget/
target$ mkdir g1
target$ cd g1/
target$ echo "0x1d6b" > idVendor
target$ echo "0x0104" > idProduct
target$ mkdir strings/0x409
target$ echo "0123456789" > strings/0x409/serialnumber
target$ echo "Foo Inc." > strings/0x409/manufacturer
target$ echo "Bar Gadget" > strings/0x409/product
  • Next create a file for the mass storage gadget:
target$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
  • Now you should create the functions you want to use:
target$ cd /sys/kernel/config/usb_gadget/g1
target$ mkdir functions/acm.GS0
target$ mkdir functions/ecm.usb0
target$ mkdir functions/mass_storage.0
target$ echo /tmp/file.img > functions/mass_storage.0/lun.0/fi

- acm: Serial gadget, creates serial interface like /dev/ttyGS0.
- ecm: Ethernet gadget, creates ethernet interface, e.g. usb0
- mass_storage: The host can partition, format, and mount the gadget mass storage the same way as any other USB mass storage.

  • Bind the defined functions to a configuration with:
target$ cd /sys/kernel/config/usb_gadget/g1
target$ mkdir configs/c.1
target$ mkdir configs/c.1/strings/0x409
target$ echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
target$ ln -s functions/acm.GS0 configs/c.1/
target$ ln -s functions/ecm.usb0 configs/c.1/
target$ ln -s functions/mass_storage.0 configs/c.1/
  • Finally, start the USB gadget with the following commands:
target$ cd /sys/kernel/config/usb_gadget/g1
target$ ls /sys/class/udc/
ci_hdrc.0
target$ echo "ci_hdrc.0" >UDC

If your system has more than one USB Device or OTG port, you can pass the right one to the USB Device Controller (UDC).

  • To stop the USB gadget and unbind the used functions execute:
target$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC

User USB OTG configuration in the kernel device tree phytec-imx8mm-phyGATE-Tauri.dtsi:

/ {

[...]  
      reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_usbotg1pwrgrp>;
                compatible = "regulator-fixed";
                regulator-name = "usb_otg1_vbus";
                regulator-min-microvolt = <5000000>;
                regulator-max-microvolt = <5000000>;
                gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
                enable-active-high;
        };
[...]
};

&usbotg1 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_usbotg1grp>;
        vbus-supply = <®_usb_otg1_vbus>;
        dr_mode = "otg";
        picophy,pre-emp-curr-control = <3>;
        picophy,dc-vol-level-adjust = <7>;
        status = "okay";
};

[...]

&iomuxc {         imx8mm-phyGATE-Tauri {
[...]
                pinctrl_usbotg1pwrgrp: usbotg1pwrgrp {
                        fsl,pins = <
                                MX8MM_IOMUXC_GPIO1_IO12_GPIO1_IO12      0x00
                        >;
                };

                pinctrl_usbotg1grp: usbotg1grp {
                        fsl,pins = <
                                MX8MM_IOMUXC_GPIO1_IO13_USB1_OTG_OC     0x80
                        >;
                };
[...]
        };
};

CAN

CAN is not functional in the current hardware revision.

TPM

The phyBOARD-i.MX 8M Mini has a SLB 9670XQ2.0 Trusted Platform Module (TPM) compliant with the TCG TPM 2.0 standard. The TPM is connected over the SPI interface. Currently, we support a basic driver implementation.

Bootlog output:

tpm_tis_spi spi1.0: 2.0 TPM (device-id 0x1B, rev-id 16)

TPM configuration in the kernel device tree phytec-imx8mm-phyGATE-Tauri.dtsi:

/* TPM */
&ecspi2 {
        #address-cells = <1>;
        #size-cells = <0>;
        fsl,spi-num-chipselects = <1>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>;
        cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
        status = "okay";

        tpm: tpm_tis@0 {
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_tpm>;
                compatible = "tcg,tpm_tis-spi";
                reg = <0>;
                spi-max-frequency = <38000000>;
#if 0 /* IRQ support is not properly implemented in the driver */
                interrupt-parent = <&gpio2>;
                interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
#endif
        };
};

PCIe

The phyCORE-i.MX 8M Mini has one Mini-PCIe slot. In general, PCIe autodetects new devices on the bus. After connecting the device and booting up the system, you can use the command lspci to see all PCIe devices recognized.

  • Type:
target$ lspci -v
  • You will receive:
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0, IRQ 218
        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
        I/O behind bridge: None
        Memory behind bridge: 18100000-181fffff [size=1M]
        Prefetchable memory behind bridge: None
        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
        Capabilities: [70] Express Root Port (Slot-), MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [148] L1 PM Substates
        Kernel driver in use: dwc3-haps

01:00.0 Network controller: Intel Corporation WiFi Link 5100
        Subsystem: Intel Corporation WiFi Link 5100 AGN
        Flags: fast devsel
        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
        Capabilities: [c8] Power Management version 3
        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [e0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
        Kernel modules: iwlwifi

In this example, the PCIe device is the Intel Corporation WiFi Link 5100.

For PCIe devices, you have to enable the correct driver in the kernel configuration. This WLAN card, for example, is manufactured by IntelKconfig. The option for the driver, which must be enabled, is named CONFIG_IWLWIFI and can be found under Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat in the kernel configuration.

  • In order to activate the driver, use:
host$ bitbake virtual/kernel -c menuconfig

For some devices like the WLAN card, additional binary firmware blobs are needed. These firmware blobs have to be placed in /lib/firmware/ before the device can be used.

  • Type:
host$ scp -r <firmware> root@192.168.3.11:/lib/firmware
  • For example, if you try to bring up the network interface with:
target$ ip link set up wlp1s0
  • You will get the following output on the serial console:
[   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready


Tip

Some PCIe devices, e.g. the Ethernet card, may function properly even if no firmware blob is loaded from /lib/firmware/ and you received an error message as shown in the first line of the output above. This is because some manufacturers provide the firmware as fall-back on the card itself. In this case, the behavior and output depend strongly on the manufacturer's firmware.

CPU Core Management

The i.MX 8M Mini SoC can have multiple processor cores on the die. The i.MX 8M Mini Quad, for example, has 4 ARM Cores which can be turned on and off individually at runtime.

  • To see all available cores in the system, execute:
target$ ls /sys/devices/system/cpu  -1
  • This will show, for example:
cpu0    cpu1   cpu2   cpu3   cpufreq
[...]

Here the system has four processor cores. By default, all available cores in the system are enabled to get maximum performance.

  • To switch off a single-core, execute:
target$ echo 0 > /sys/devices/system/cpu/cpu3/online

As confirmation, you will see:

[  110.502295] CPU3: shutdown
[  110.505012] psci: CPU3 killed.

Now the core is powered down and no more processes are scheduled on this core.

  • You can use top to see a graphical overview of the cores and processes:
target$ htop
  • To power up the core again, execute:
target$ echo 1 > /sys/devices/system/cpu/cpu3/online

Thermal Management

The Linux kernel has integrated thermal management which is capable of monitoring SoC temperatures, reducing the CPU frequency, driving fans, advising other drivers to reduce the power consumption of devices, and – worst-case – shutting down the system gracefully (https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

This section describes how the thermal management kernel API is used for the i.MX 8M Mini SoC platform. The i.MX8 has internal temperature sensors for the SoC.

  • The current temperature can be read in millicelsius with:
target$ cat /sys/class/thermal/thermal_zone0/temp
  • You will get, for example:
49000

There are two trip points registered by the imx_thermal kernel driver:

trip_point_0: 85 °C type: passive

trip_point_1: 95 °C type: critical

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

These trip points are used by the kernel thermal management to trigger events and change the cooling behavior. The following thermal policies (also named thermal governors) are available in the kernel: Step WiseFair ShareBang Bang, and Userspace. The default policy used in the BSP is step_wise.  If the value of the SoC temperature in the sysfs file temp is above trip_point_0 (greater than 85 °C), the CPU frequency is set to the lowest CPU frequency. When the SoC temperature drops below trip_point_0 again, the throttling is released.

Revision History

Date

Version #

Changes in this manual

25.02.2021

Manual L-1011e.A0

New Release