I.Mx8M Mini Reference Manual | Embedded Linux Training (I.Mx8M Mini): First Steps With Yocto # 1. Building A Yocto Image And Sdk 57 개의 정답

당신은 주제를 찾고 있습니까 “i.mx8m mini reference manual – Embedded Linux Training (I.MX8M Mini): first steps with Yocto # 1. Building a Yocto Image and SDK“? 다음 카테고리의 웹사이트 https://ro.taphoamini.com 에서 귀하의 모든 질문에 답변해 드립니다: ro.taphoamini.com/wiki. 바로 아래에서 답을 찾을 수 있습니다. 작성자 SoMLabs 이(가) 작성한 기사에는 조회수 5,587회 및 좋아요 94개 개의 좋아요가 있습니다.

Table of Contents

i.mx8m mini reference manual 주제에 대한 동영상 보기

여기에서 이 주제에 대한 비디오를 시청하십시오. 주의 깊게 살펴보고 읽고 있는 내용에 대한 피드백을 제공하세요!

여기에서 동영상 보기

d여기에서 Embedded Linux Training (I.MX8M Mini): first steps with Yocto # 1. Building a Yocto Image and SDK – i.mx8m mini reference manual 주제에 대한 세부정보를 참조하세요

First part of webinar focused on first steps with Linux Yocto and VisionSOM-8Mmini SOM modules.
The online workshop has been prepared for engineers who are interested in using a microprocessor with Linux. SoMLabs Evaluation Kit is the training platform – info about eval kit: https://www.tme.eu/pl/details/visionstk-8m-tr01/zestawy-do-ukladow-nxp/somlabs/.
Agenda \u0026 details:
https://techdays.pl/events/linux-and-i-mx-8m-mini-soc-hands-on-training/
Technical details of VisionSOM-8Mmini:
https://somlabs.com/product/visionsom-8mmini-sls23/
and
https://wiki.somlabs.com/index.php?title=VisionSOM-8Mmini
Source codes of examples:
http://ftp.somlabs.com/Trainings/Hands-on-Linux-Academy-2020/ExcercisesDirectory-Linux-Workshop-10-2020.zip

i.mx8m mini reference manual 주제에 대한 자세한 내용은 여기를 참조하세요.

i.MX 8M Mini Hardware Developer’s Guide

This document supports the i.MX 8M Mini (14 x 14 mm package). NXP Semiconductors. Document Number: IMX8MMHDG. User’s Gue. Rev. 1 , 08/ …

+ 여기를 클릭

Source: www.zlgmcu.com

Date Published: 8/26/2022

MCM-iMX8M-Mini – CompuLab

MX8M Mini Reference manual for additional details. The table below summarizes the MIPI-CSI interface signals.

+ 여기에 더 보기

Source: www.compulab.com

Date Published: 9/22/2021

VAR-SOM-MX8M-MINI : NXP i.MX 8M Mini – Variscite

MX 8M Mini with up to 1.8GHz Quad-core ARM Cortex-A53 plus 400MHz Cortex-M4 real-time CPU. … Reference Manuals. VAR-SOM-MX8M-MINI Brief …

+ 여기를 클릭

Source: www.variscite.com

Date Published: 5/15/2022

i.MX 8M Mini LPDDR4 EVK Board Hardware User’s Guide

Table 1 lists the features of the i.MX 8M Mini. LPDDR4 EVK board. NXP Semiconductors. Document Number: IMX8MMEVKHUG. User’s Gue. Rev. 0 , 02/ …

+ 여기를 클릭

Source: static6.arrow.com

Date Published: 2/20/2021

i.MX 8M Mini Applications Processor Datasheet for Consumer …

MX 8M Mini Applications Processor Reference Manual. (IMX8MMRM) for details. FlexSPI. FlexSPI. The FlexSPI module acts as an interface to external serial …

+ 자세한 내용은 여기를 클릭하십시오

Source: datasheet.octopart.com

Date Published: 7/18/2022

i.MX8M Mini EVK Reference Manual – Industrial News – Forlinx

MX 8M Mini series chips are now available. OKMX8MM-C board offers a we range of … MX8M Mini EVK Reference Manual. In recent years, with the evolution of …

+ 여기를 클릭

Source: www.forlinx.net

Date Published: 4/23/2022

Customer Area – TX8M – Ka-Ro electronics GmbH

MX8M Mini\Processor Reference Manual\IMX8MMRM.pdf Updated: 234214 2021/05/05 09:52:46 Datasheets\i.MX8M Nano\Chip Errata\IMX8MN_0N14Y.pdf Updated: 1334087 …

+ 여기에 자세히 보기

Source: www.karo-electronics.com

Date Published: 5/17/2021

L-1002e.A0 i.MX 8M Mini BSP Manual – PHYTEC Wiki

Look at the NXP documentation i.MX Yocto Project User’s Gue for more information. PHYTEC Documentation. PHYTEC proves a variety of hardware and software …

+ 여기에 더 보기

Source: wiki.phytec.com

Date Published: 5/7/2022

주제와 관련된 이미지 i.mx8m mini reference manual

주제와 관련된 더 많은 사진을 참조하십시오 Embedded Linux Training (I.MX8M Mini): first steps with Yocto # 1. Building a Yocto Image and SDK. 댓글에서 더 많은 관련 이미지를 보거나 필요한 경우 더 많은 관련 기사를 볼 수 있습니다.

주제에 대한 기사 평가 i.mx8m mini reference manual

Author: SoMLabs
Views: 조회수 5,587회
Likes: 좋아요 94개
Date Published: 2020. 11. 25.
Video Url link: https://www.youtube.com/watch?v=sw9GyKTVyHo

VAR-SOM-MX8M-MINI : NXP i.MX 8M Mini ARM System on Module (SoM)

The VAR-SOM-MX8M-MINI is a highly scalable, low power System on Module (SoM) / Computer on Module (CoM) , offering a mainstream solution to fit a wide range of applications and cost requirements.

Based on NXP’s i.MX 8M Mini with up to 1.8GHz Quad-core ARM Cortex-A53™ plus 400MHz Cortex-M4™ real-time processor and up to 4 GB DDR4, the VAR-SOM-MX8M-MINI supports advanced features and a variety of connectivity options, including integrated HW engines supporting 1080p video encoding and decoding, 2D and 3D graphics, HQ audio, integrated certified single band 802.11 b/g/n or dual-band 802.11 ac/a/b/g/n, integrated CAN bus, LVDS, and a variety of additional interfaces.

The VAR-SOM-MX8M-MINI is a pin2pin platform compatible with the ‘VAR-SOM Pin2Pin’ products family, providing a maximum scalability range; from the entry-level i.MX6UL/6ULL platform, through the i.MX 6 platforms, i.MX 8X, and up to the i.MX 8QuadMax. For the complete Pin2pin product list, check the Variscite Pin2Pin System on Module families.

** The Pin2Pin compatibility depends on pinmux options; please verify the detailed pinout table in the related SoM to confirm compatibility is maintained in your specific design.

Forlinx Embedded Technology Co., Ltd.

In recent years, with the evolution of AIOT technology and the rapid development of industry 4.0, strong performance, cost leadership, long leading delivery cycle of embedded board has become a common demand for the development of these two types of equipment hardware.

iMX8M series core board and development board, i.MX 8M Mini series chips are now available. OKMX8MM-C board offers a wide range of audio interfaces, including I2S, AC97, TDM, PDM and SPDIF. A wide range of peripheral interfaces are available, such as MIPI-CSI, MIPI-DSI, USB, PCIe, UART, eCSPI, IIC and Gigabit Ethernet, while System-on-Module is cost-effective in bulk and has a stable lead time of up to 10 years.

Let’s take a look at what a cost-effective development platform looks like:

First, high-performance low-power “core”

NXP’s i.MX 8M Mini series processor is NXP’s new embedded multicore application processor built with advanced 14LPC FinFET process technology to deliver faster speeds and higher power efficiency. Supported by commercial and industrial certifications and NXP’s 10-year supply program, it can be used in a wide range of general industrial and IoT applications.

Chip system block diagram:

Second, rich hardware and software resources of development board

In order to meet the functional needs of various product equipment, OKMX8MM-C SBC provides a wealth of peripheral interface, can maximize the use of core board resources and provide users with reliable reference circuits for hardware development, simplifying development difficulty and time.

OKMX8MP-C board block diagram:

Adopt i.MX8M Mini quad-core processor, combined with 2G DDR4 plus 8G eMMC high-capacity memory, makes the system faster and smoother, with industrial-grade temperatures and a ten-year product program.

Multimedia interface: MIPI-DSI-MIPI-CSI, up to 1080p60, support hi-fi audio input and output, greatly enrich the user’s digital multimedia design applications.

Communication interface: WIFI/Bluetooth module, Gigabit Ethernet, 4G LTE, to provide a stable and rapid connection to industrial Internet of Things and AIOT products.

Support for SSD storage extensions for M.2 PCI-E interfaces, making data storage faster.

Companion software resources:

Android 9.0

Linux 4.14,

QT5.10

Third, the core board with great cost-effective advantages

The FETMX8MM-C core board features NXP’s i.MX8M Mini family processors, 4-core ARM Cortex A53 processors up to 1.8G HZ main frequency, and integrated power management chips, DDR4, eMMC, QSPI FLASH, Gigabit Ethernet PHY, and 240 PIN signal expansion connectors for complex applications and industrial-grade temperature requirements.

Four, a wide range of applications

Forlinx iMX8MM core boards and development boards for industrial control of high-performance board requirements and the Internet of Things, enabling computing and real-time processing tasks to be released from the cloud to the edge, accelerating industrial IoT and AIOT product landing applications.

Products can be widely used in intelligent charging piles, smart light poles, advertising machines, new retail vending / ticket machines, human-machine interactive inquiries and business processing machines, car networking (V2X), general power Internet of Things, high-performance instrumentation (industrial and medical), industrial control and human-machine interactive devices, intelligent transportation, intelligent fire, smart cities, smart buildings and other fields.

Customer Area – TX8M

Welcome to the Ka-Ro customer area!

You are not logged in at the moment!

If you already have a login or would like to register, please go to Login.

As a registered customer, you have access to the latest data on your Ka-Ro products after you have activated your account. The activation is product-related.

In case of problems please contact [email protected]

Your sales contact will be happy to help you if you would like to gain access to further product areas.

L-1002e.A0 i.MX 8M Mini BSP Manual

Document Title L-1002e.A0 phyCORE-i.MX 8M Mini BSP Manual

Document Type BSP Manual Yocto Page L-813e.A9 Yocto Reference Manual Article Number L-1002e.A0 Release Date 02.07.2020 Is Branch of L-1002e.Ax phyCORE-i.MX 8M Mini BSP Manual Head

Compatible BSP’S BSP Release Type BSP Release Date BSP Status BSP-Yocto-FSL-i.MX8MM-PD20.1.0 Major 01.07.2020 Released

Yocto Introduction

Please read L-813e.A9 Yocto Reference Manual for a better understanding of Yocto and this BSP. Furthermore, the meta-yogurt layer cannot be used for the alpha release. Look at the NXP documentation i.MX Yocto Project User’s Guide for more information.

PHYTEC Documentation

PHYTEC provides a variety of hardware and software documentation for all of our products. This includes any or all of the following:

QS Guide : A short guide on how to set up and boot a phyCORE board along with brief information on building a BSP, the device tree, and accessing peripherals.

Hardware Manual : A detailed description of the System on Module and accompanying carrier board.

Yocto Guide : A comprehensive guide for the Yocto version the phyCORE uses. This guide contains an overview of Yocto; introducing, installing, and customizing the PHYTEC BSP; how to work with programs like Poky and Bitbake; and much more.

BSP Manual : A manual specific to the BSP version of the phyCORE. Information such as how to build the BSP, booting, updating software, device tree, and accessing peripherals can be found here.

Development Environment Guide : This guide shows how to work with the Virtual Machine (VM) Host PHYTEC has developed and prepared to run various Development Environments. There are detailed step-by-step instructions for Eclipse and Qt Creator, which are included in the VM. There are instructions for running demo projects for these programs on a phyCORE product as well. Information on how to build a Linux host PC yourself is also a part of this guide.

Pin Muxing Table: phyCORE SOMs have an accompanying pin table (in Excel format). This table will show the complete default signal path, from processor to carrier board. The default device tree muxing option will also be included. This gives a developer all the information needed in one location to make muxing changes and design options when developing a specialized carrier board or adapting a PHYTEC phyCORE SOM to an application.

On top of these standard manuals and guides, PHYTEC will also provide Product Change Notifications, Application Notes, and Technical Notes. These will be done on a case by case basis. Most of the documentation can be found in the applicable download page of our products.

BSP Introduction

Supported Hardware

The phyBOARD-Polis with 2GB RAM and the alpha kit with 1GB are supported. Visit our web page at https://www.phytec.de/produkt/system-on-modules/phycore-imx-8m-mini-nano-phyboard-polis-download/. Click the corresponding BSP release and look for the article number of your module in the column “Article Number”. Finally, look for the correct machine name in the corresponding cell under “Machine Name”.

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 is based on the u-boot-imx and adds only a few patches which will be sent upstream in future updates. 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 checked out BSP source folder:

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 on the manifest file:

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.

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).

#@TYPE: Machine #@NAME: phyboard-polis-imx8mm-3 #@DESCRIPTION: PHYTEC phyBOARD-POLIS i.MX8M Mini 2GB RAM, 16GB eMMC #@ARTICLENUMBERS: PB-02820.A1 #@SUPPORTEDIMAGE: phytec-qt5demoimage-image/yogurt-vendor-xwayland

Software Platform Selection

To set the correct SoC, BSP version, and platform:

host$ ./phyLinux init

MACHINE=phyboard-polis-imx8mm-3 ./phyLinux init -p imx8mm -r PD20.1.0

Please read Initialization for more information.

Starting the Build Process

Refer to Start the Build.

BSP Images

All images generated by Bitbake are deployed to ~/yocto_imx8m/build/deploy/images/. The following list shows for example all files generated for the i.MX 8M Mini phyboard-polis-imx8m-2 machine:

U-Boot: u-boot.bin

U-Boot-SPL: u-boot-spl.bin

imx-boot: imx-boot

Kernel: Image

Kernel configuration: Image.config

Kernel device tree file: imx8mm-phyboard-polis-rdk-phyboard-polis-imx8mm-3.dtb

root filesystem: phytec-qt5demo-image-phyboard-polis-imx8mm-3.tar.gz

SD card image: phytec-qt5demo-image-phyboard-polis-imx8mm-3.sdcard

Tip The default linux image phytec-qt5demo-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 phyBOARD-Polis is the eMMC.

Booting from eMMC

To boot from eMMC, make sure that the BSP image is flashed correctly to the flash. Dip switch S1 Pos1 needs to be set to off. To update the software of the eMMC, see Updating Software.

Booting from SD Card

Booting from an SD card is useful in several situations, e.g. if the board does not start anymore due to a damaged bootloader. To boot from an SD card, switch S1 POS1 has to be set to ON.

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

– a single prebuild SD card image, or

– the four individual images (imx-boot-, kernel- and device tree image, and root filesystem)

Single, Prebuild SD Card Image

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

You can also find ready-to-use *.sdcard images on our FTP server.

Tip The created file phytec-qt5demo-image-phyboard-polis-imx8mm-3.sdcard is only a link to a file like phytec-qt5demo-image-phyboard-polis-imx8mm-3-.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 out 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/ (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/ with an appended number (e.g. /dev/sde1) in the output. These represent the partition(s) that need to be unmounted.

Unmount all partitions:

host$ umount /dev/

After having unmounted all devices with an appended number (), you can create your bootable SD card:

host$ sudo dd if=–.sdcard of=/dev/ bs=1M conv=fsync status=progress

If you use the image file created by Bitbake instead:

host$ sudo dd if=––.rootfs.sdcard of=/dev/ bs=1M conv=fsync status=progress

Using the device name () 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.

has the format: YYYYMMDDHHMMSS

example: Date = 22.06.2018 Time = 11:06:36 = 20180622110636

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

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

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 zImage, 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 (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=imx-boot of=/dev/sde bs=1k seek=33 conv=fsync

Mount the first partition (vfat) and copy the linuximage and oftree file to it:

host$ sudo mount /dev/sd1 /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, mount the ext4 partition as well.

Then untar – . tar.gz rootfs image to it:

host$ sudo mount /dev/sd2 /media host$ sudo tar jxf –.tar.gz -C /media/

Do not forget to properly unmount the SD card:

host$ sudo umount /media

Booting the Kernel from a Network

Booting from 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.

Host Preparation Developments

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

A TFTP server

For Ubuntu, install:

host$ sudo apt-get install tftpd-hpa xinetd

After the installation, there are two ways to configure the TFTP server.

TFTP Server Setup

As a stand-alone daemon Controlled and handled by xinetd

First, create a directory to store the TFTP files:

host$ sudo mkdir /tftpboot host$ sudo chmod -R 777 /tftpboot host$ sudo chown -R nobody /tftpboot

Then copy your BSP image files to this directory. You also need to configure a static IP address for the appropriate interface. The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

host$ ifconfig eth1

You will receive:

eth1 Link encap:Ethernet HWadr 00:11:6b:98:e3:47 inet addr:192.168.3.10 Bcast:192.168.3.255 Mask:255.255.255.0

TFTP as a Stand-alone Daemon

Create or edit /etc/default/tftpd-hpa:

# /etc/default/tftpd-hpa TFTP_USERNAME=”tftp” TFTP_DIRECTORY=”/tftpboot” TFTP_ADDRESS=”:69″ TFTP_OPTIONS=”-s -c”

Set TFTP_DIRECTORY to your TFTP server root directory

Set TFTP_ADDRESS to the host address the server is listening to (set to 0.0.0.0:69 to listen to all local IPs)

Set TFTP_OPTIONS, the following command shows the available options:

host$ man tftpd

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 needs to be installed, too. 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 directory is exported and the “lab network” address of the development host is 192.168.3.10. The IP address has to be adapted to the local needs:

/home// 192.168.3.11/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)

must be replaced with your home directory name.

can be set to a folder which contains a rootfs tar.gz image extracted with sudo.

Embedded Board Preparations

To find the Ethernet settings in the target bootloader:

u-boot=> printenv ipaddr serverip netmask ethaddr netargs netboot

With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, the target should return:

ipaddr=192.168.3.11 netmask=255.255.255.0 serverip=192.168.3.10 ethaddr=xx:xx:xx:xx:xx:xx netargs=setenv bootargs console=${console} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp netboot=echo Booting from net …; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${loadaddr} ${image}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then booti ${loadaddr} – ${fdt_addr}; else echo WARN: Cannot load the DT; fi; else booti; fi;

If you need to make any changes:

u-boot=> setenv
should be one of ipaddr, netmask, gateway, or severip.

will be the actual value of the chosen parameter.

Make your changes and hit ‘Enter’.

The changes you made are temporary for now. To save these:

u-boot=> saveenv

Here you can also change the IP address to DHCP instead of using a static one.

Configure:

u-boot=> setenv ip dhcp

Set up paths for TFTP and NFS. A modification could look like this:

u-boot=> setenv nfsroot /home/user/nfssrc

Please note that these modifications will only affect the bootloader settings.

Booting from an Embedded Board

To boot from network, call:

u-boot=> run netboot

Booting from SPI NOR Flash

The phyCORE-i.MX8MM modules are optionally equipped with SPI NOR Flash. To boot from SPI Flash, set Switch S1 POS1 and POS2 to ON. The SPI Flash is usually quite small. The phyBOARD-Polis-i.MX8MM kit only has 32MB SPI NOR flash populated. Only the bootloader and the environment can be stored. The kernel, device tree, and filesystem are taken from eMMC by default.

The MTD partition setup:

Range MTD Partition Name 0x000000000000-0x000000400000 u-boot 0x000000400000-0x000000500000 env 0x000000500000-0x000002000000 none

The SPI NOR flash partition table is defined in the U-Boot environment. It can be printed with:

target$ printenv mtdparts mtdparts=30bb0000.flexspi:4M(u-boot),1M(env),-(none)

The partition table is passed via device tree fixup to the kernel. Flashing the SPI NOR is described in the section Updating SPI NOR Flash from Network.

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 and SPI NOR flash.

Updating eMMC from 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 .sdcard (or .sdcard.bz2) from the Yocto build system directly to the eMMC. The image contains the bootloader, kernel, device trees, and root filesystem.

Updating eMMC from Network in u-boot on Target

These steps will show how to update the eMMC via a network. However, they only work if the size of the image file is less then 1GB. If the image file is larger, go to the section Updating eMMC from SD card in Linux on Target. Configure the boot switch to boot from SD Card (Switch S1 is ON) and put in an SD card. Power on the board and stop in u-boot.

Tip A working network is necessary!

Load your image via network to RAM:

u-boot=> tftp ${loadaddr} phytec-qt5demo-image-phyboard-polis-imx8mm-3.sdcard Using ethernet@30be0000 device TFTP from server 192.168.3.10; our IP address is 192.168.3.11 Filename ‘phytec-qt5demo-image-phyboard-polis-imx8mm-3.sdcard’. Load address: 0x40480000 Loading: ################################################################# ################################################################# ################################################################# … … … ################################################################# ############# 11.2 MiB/s done Bytes transferred = 911842304 (36599c00 hex)

Write the image to the eMMC:

u-boot=> mmc dev 2 switch to partitions #0, OK mmc2(part 0) is current device u-boot=> mmc write ${loadaddr} 0x0 0x1B2CCE # number of blocks to write. In this case 911842304 bytes / 512 = 0x1B2CCE MMC write: dev # 2, block # 0, count 1780942 … 1780942 blocks written: OK

Updating eMMC from USB in u-boot on Target

These steps will show how to update the eMMC via USB device, but they only work if the size of the image file is less then 2GB. If the image file is larger, go to the section Updating eMMC from SD card in Linux on Target. Configure the boot switch to boot from SD Card (Switch S1 is ON) and put in an SD card. Power on the board and stop in u-boot. Insert a USB device with the proper *.sdcard image to the micro USB slot.

Load your image from the USB device to RAM:

u-boot=> usb start starting USB… USB0: USB EHCI 1.00 scanning bus 0 for devices… 2 USB Device(s) found scanning usb for storage devices… 1 Storage Device(s) found u-boot=> fatload usb 0:1 ${loadaddr} *.sdcard 497444864 bytes read in 31577 ms (15 MiB/s)

Write the image to the eMMC:

u-boot=> mmc dev 2 switch to partitions #0, OK mmc2(part 0) is current device u-boot=> mmc write ${loadaddr} 0x0 0xFA000 MMC write: dev # 2, block # 0, count 1024000 … 1024000 blocks written: OK u-boot=> setenv mmcdev 2 u-boot=> boot

Updating eMMC via Network in Linux on Target

You can update the eMMC from your target.

Tip A working network is necessary!

Take a compressed or uncompressed 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 @192.168.3.10 “dd if=/phytec-qt5demo-image-phyboard-polis-imx8mm-3.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 host:

host$ ls phytec-qt5demo-image-phyboard-polis-imx8mm-3.sdcard

Send the image with dd command combined with ssh through the network to the eMMC of your device:

host$ dd if=phytec-qt5demo-image-phyboard-polis-imx8mm-3.sdcard status=progress | ssh [email protected] “dd of=/dev/mmcblk2”

Updating eMMC from 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 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 from SD card in u-boot on Target

Configure SD Card for Flashing

First, create a new partition on the SD card to store the image in it.

On your host, insert the SD card and use dmesg to see which one it is:

host$ dmesg | tail … [30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB) [30436.179846] sdb: sdb1 sdb2 …

Create a new partition with sudo fdisk /dev/sd:

host$ sudo fdisk /dev/sdb Welcome to fdisk (util-linux 2.27.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/sdb: 29,8 GiB, 31976325120 bytes, 62453760 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 Disklabel type: dos Disk identifier: 0xd28c31b9 Device Boot Start End Sectors Size Id Type /dev/sdb1 16384 81919 65536 32M c W95 FAT32 (LBA) /dev/sdb2 81920 3375103 3293184 1,6G 83 Linux Command (m for help): n Partition type p primary (2 primary, 0 extended, 2 free) e extended (container for logical partitions) Select (default p): p Partition number (3,4, default 3): 3 First sector (2048-62453759, default 2048): 3440640 Last sector, +sectors or +size{K,M,G,T,P} (3440640-62453759, default 62453759): Created a new partition 3 of type ‘Linux’ and of size 28,1 GiB. Command (m for help): t Partition number (1-3, default 3): 3 Partition type (type L to list all types): c Changed type of partition ‘Linux’ to ‘W95 FAT32 (LBA)’. Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks.

Give the new partition a name and mount it:

host$ sudo mkfs.vfat -n “data” /dev/sdb3 mkfs.fat 3.0.28 (2015-05-16) mkfs.fat: warning – lowercase labels might not work properly with DOS or Windows host$ sudo mount /dev/sdb3 /mnt

Copy your image to the new partition and unmount it afterward:

host$ sudo cp phytec-qt5demo-image-phyboard-polis-imx8mm-3.sdcard /mnt/ ; sync

Flash eMMC from u-boot

Tip This step only works if the size of the image file is less then 1GB. If the image file is larger, go to Updating eMMC from SD card in Linux on Target.

Configure the boot switch to boot from the SD Card ( Switch S1 is ON) and insert the SD card.

Power on the board and stop in u-boot.

Flash your .sdcard image (for example small_test-image.sdcard) from the SD card to eMMC. This will partition the card and copy imx-boot, Image, dtb, and root filesystem to eMMC:

u-boot=> fatload mmc 1:3 ${loadaddr} phytec-qt5demo-image-phyboard-polis-imx8mm-3.sdcard reading 911842304 bytes read in 39253 ms (22.2 MiB/s) u-boot=> mmc dev 2 switch to partitions #0, OK mmc0(part 0) is current device u-boot=> mmc write ${loadaddr} 0x0 0x1B2CCE # number of blocks to write. In this case 911842304 bytes / 512 = 0x1B2CCE MMC write: dev # 2, block # 0, count 1780942 … 1780942 blocks written: OK

Reset the board.

Stop in u-boot again and check that the partition table for eMMC is as expected:

u-boot=> reset … u-boot=> mmc dev 2 switch to partitions #2, OK mmc2(part 0) is current device u-boot=> mmc part Partition Map for MMC device 2 — Partition Type: DOS Part Start Sector Num Sectors UUID Type 1 8192 89436 f221c2be-01 0c Boot 2 98304 1682638 f221c2be-02 83

Updating eMMC from 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.g. phytec-qt5demo-image-phyboard-polis-imx8mm-3.sdcard).

Show your saved image files on the SD card:

target$ ls phytec-qt5demo-image-phyboard-polis-imx8mm-3.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 phyCORE-i.MX 8M Mini eMMC (MMC device 2 WITHOUT partition):

target$ dd if=phytec-qt5demo-image-phyboard-polis-imx8mm-3.sdcard of=/dev/mmcblk2

After a complete write, your board can boot from eMMC.

Before this will work, you need to toggle Switch S1 to OFF. If you don’t, the board will boot from SD card again.

Updating SPI NOR Flash from Network

The SPI NOR can contain the bootloader and environment to boot from. The arm64 kernel can not decompress itself, the images size extends the SPI NOR flash populated on the phyCORE-i.MX 8M Mini.

Updating SPI NOR from Network in u-boot on Target

Similar to updating the eMMC 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. Before reading and writing is possible, the SPI-NOR flash needs to be probed:

u-boot=> sf probe SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB

A specially formatted u-boot image for the SPI NOR flash is used. Ensure you use the correct image file. Load the image over tftp, erase and write the bootloader to the flash:

u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mm-3-fspi.bin-flash_evk_flexspi u-boot=> sf erase 0 0x400000 u-boot=> sf write ${loadaddr} 0 0x400000

Erase the environment partition as well. This way, the environment can be written after booting from SPI NOR flash:

u-boot=> sf erase 0x400000 0x100000

Warning Erasing the complete SPI NOR flash when it is fully written will take quite some time. This can trigger the watchdog to reset. Due to this, erase the full flash in Linux.

Updating SPI NOR from Network in kernel on Target

First, copy the image from host to target:

host$ scp imx-boot-phyboard-polis-imx8mm-3-fspi.bin-flash_evk_flexspi [email protected]:/root

Find the number of erase blocks of the u-boot partition:

target$ mtdinfo /dev/mtd0 mtd0 Name: u-boot Type: nor Eraseblock size: 65536 bytes, 64.0 KiB Amount of eraseblocks: 64 (4194304 bytes, 4.0 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:0 Bad blocks are allowed: false Device is writable: true

Erase the u-boot partition and flash it:

target$ flash_erase /dev/mtd0 0x0 64 target$ flashcp imx-boot-phyboard-polis-imx8mm-3-fspi.bin-flash_evk_flexspi /dev/mtd0

Updating SPI NOR Flash from SD Card

The bootloader on SPI NOR flash can be also updated with SD Card.

Updating SPI NOR from SD Card in u-boot on Target

Copy the SPI NOR flash u-boot image imx-boot-phyboard-polis-imx8mm-3-fspi.bin-flash_evk_flexspi to the FAT partition on the SD Card. Before reading and writing is possible the SPI-NOR flash needs to be probed:

u-boot=> sf probe SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB

A specially formatted u-boot image for the SPI NOR flash is used. Ensure you use the correct image file. Load the image from the SD Card, erase and write the bootloader to the flash:

u-boot=> mmc dev 1 u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mm-3-fspi.bin-flash_evk_flexspi u-boot=> sf erase 0 0x400000 u-boot=> sf write ${loadaddr} 0 0x400000

Erase the environment partition as well. This way, the environment can be written after booting from SPI NOR flash:

u-boot=> sf erase 0x400000 0x100000

Warning Erasing the complete SPI NOR flash when it is fully written will take quite some time. This can trigger the watchdog to reset. Due to this, erase the full flash in Linux.

Updating SPI NOR from SD Card in kernel on Target

First, mount the SD Card:

host$ mount /dev/mmcblkp1 /mnt

Find the number of erase blocks of the u-boot partition:

target$ mtdinfo /dev/mtd0 mtd0 Name: u-boot Type: nor Eraseblock size: 65536 bytes, 64.0 KiB Amount of eraseblocks: 64 (4194304 bytes, 4.0 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:0 Bad blocks are allowed: false Device is writable: true

Erase the u-boot partition and flash it:

target$ flash_erase /dev/mtd0 0x0 64 target$ flashcp /mnt/imx-boot-phyboard-polis-imx8mm-3-fspi.bin-flash_evk_flexspi /dev/mtd0

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:

PHYTEC i.MX 8M Mini BSP Device Tree Concept

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

DT Structure

The module includes the file Modul .dtsi which contains all devices mounted on the module, such as PMIC and RAM. Devices that 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 which 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.MX 8 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 much 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.MX 8 BSP device tree model.

The following sections provide an overview of the supported hardware components and their operating system drivers on the i.MX 8 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-phyboard-polis.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 UART units. PHYTEC boards support different numbers of these UART units.

From the command line prompt of Linux userspace, you can easily check the availability of other UART interfaces:

target$ echo “test” > /dev/ttymxc2

Be sure that the baud rate is set correctly on the 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:

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 imx8mm-phyboard-polis.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 { […] 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 phyBOARD-Polis can also be used as RS-485. For this, Switch S1 POS 4 needs to be set to on. We use the same device tree node for RS-232 and RS-485. RS-485 mode can be enabled with ioctl TIOCSRS485. For easy testing, use the linux-serial-test. This tool is called the IOCTL for RS485 and sends a constant 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: https://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 that 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/ as well as 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 is:

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/imx8mm-phycore-som.dtsi:
[…] #include […] &fec1 { pinctrl-names = “default”; pinctrl-0 = <&pinctrl_fec1>; phy-mode = “rgmii-id”; phy-handle = <ðphy0>; phy-reset-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>; phy-reset-active-high; phy-reset-post-delay = <1>; phy-reset-duration = <1>; 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 = ; ti,tx-internal-delay = ; ti,fifo-depth = ; ti,clk-output-sel = ; enet-phy-lane-no-swap; }; }; }; […] &iomuxc { pinctrl-names = “default”; 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 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 as:

/dev/mmcblk1p

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 no partition tabe is present, 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/imx8mm-phyboard-polis.dtsi:
[…] /* SD-Card */ &usdhc2 { vqmmc-supply = <®_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”; }; […] &iomuxc { […] 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/imx8mm-phycore-som.dtsi:
[…] &usdhc3 { vqmmc-supply = <®_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 { […] 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 the 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 SD/MMC 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 Chip Size JEDEC Version MTFC16GAPALBH-IT 16 GB 5.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:

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 manual trigger of BKOPS. Device write performance suffers.

Value 1: The host does support 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 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 currently support enabling automatic BKOPS features.

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:

target$ poweroff

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

eMMC Boot Partitions

An eMMC device contains four different hardware partitions: user, boot1, boot2, and rpmb.

The user partition is called the User Data Area in the JEDEC standard and is the main storage partition. The partitions boot1 and boot2 can be used to host the bootloader and are more reliable. Which partition the i.MX 8M Mini uses to load the bootloader is controlled by the boot configuration of the eMMC device. The partition rpmb is a small partition and can only be accessed via trusted mechanism.

Furthermore, the user partition can be divided into four user-defined General Purpose Area Partitions. An explanation of this feature exceeds the scope of this document. For further information, see the JEDEC Standard chapter 7.2 Partition Management.

Tip Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT partition table.

The current PHYTEC BSP does not use the extra partitioning feature of eMMC devices. The u-boot is flashed at the beginning of the user partition. The u-boot environment is placed at a fixed location after the u-boot. An MBR partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs partition. They are located right after the u-boot and the u-boot environment. The FAT32 boot partition contains the kernel and device tree.

There are two ways to flash the bootloader to one of the two boot partitions and to switch the boot device: via bootloader or via userspace commands as shown in the following examples.

1. Via bootloader

Detect the eMMC if not already done:

bootloader$ mmc rescan

List all detected MMC devices:

bootloader$ mmc list FSL_SDHC: 1 (SD) FSL_SDHC: 2

Select eMMC device:

bootloader$ mmc dev 2 switch to partitions #0, OK mmc2(part 0) is current device

Query some information about the eMMC device:

bootloader$ mmc info

The output will look like this:

switch to partitions #0, OK mmc2(part 0) is current device u-boot=> mmc info Device: FSL_SDHC Manufacturer ID: 13 OEM: 14e Name: S0J56 Bus Speed: 52000000 Mode : MMC DDR52 (52MHz) Rd Block Len: 512 MMC version 5.1 High Capacity: Yes Capacity: 14.8 GiB Bus Width: 8-bit DDR Erase Group Size: 512 KiB HC WP Group Size: 8 MiB User Capacity: 14.8 GiB WRREL Boot Capacity: 31.5 MiB ENH RPMB Capacity: 4 MiB ENH

Reliable Write

There are two different Reliable Write options:

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

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

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

target$ mmc –help […] mmc write_reliability set <-y|-n>

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 886,1,22 8192 113461 105270 51.4M c Win95 FAT32 (LBA) /dev/mmcblk2p2 896,0,1 1023,3,32 114688 1764495 1649808 805M 83 Linux

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 886,1,22 8192 113461 105270 51.4M c Win95 FAT32 (LBA) /dev/mmcblk2p2 896,0,1 1023,3,32 114688 1764495 1649808 805M 83 Linux 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 886,1,22 8192 113461 105270 51.4M c Win95 FAT32 (LBA) 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 886,1,22 8192 113461 105270 51.4M c Win95 FAT32 (LBA) /dev/mmcblk2p2 1023,3,16 1023,3,16 98304 31080447 30982144 14.7G 83 Linux

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 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/mmcblk2 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 devices where 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:

target$ mtdinfo –all Count of MTD devices: 1 Present MTD devices: mtd0 Sysfs interface supported: yes mtd0 Name: 30bb0000.flexspi Type: nor Eraseblock size: 65536 bytes, 64.0 KiB Amount of eraseblocks: 1024 (67108864 bytes, 64.0 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:0 Bad blocks are allowed: false Device is writable: true

It lists all MTD devices and the corresponding partition names. The flash node is defined inside of 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 imx8mm-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”; […] 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 phyBOARD-Polis 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. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are the sysfs representation of these internal i.MX 8M Mini GPIO banks GPIO1 – GPIO5.

The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO bank and counts from 1 to 5, while stands for the GPIO within the bank. 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: = ( – 1) * 32 +

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

Help text of gpioset shows possible options:

target$ gpioset –help Usage: gpioset [OPTIONS] = = … 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 Note: the state of a GPIO line controlled over the character device reverts to default when the last process referencing the file descriptor representing the device file exits. This means that it’s wrong to run gpioset, have it exit and expect the line to continue being driven high or low. It may happen if given pin is floating but it must be interpreted as undefined behavior.

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 imx8mm-phyboard-polis.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 will just be turned on by all non-zero brightness settings.

Below is a simple example.

To get all available LEDs, type:

target$ ls /sys/class/leds blue-mmc@ mmc0::@ mmc2::@ green-heartbeat@ mmc1::@ red-emmc@

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Polis.

To toggle the LEDs ON:

target$ echo 255 > /sys/class/leds/red-emmc/brightness

To toggle OFF:

target$ echo 0 > /sys/class/leds/red-emmc/brightness

User I/O configuration in device tree file arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.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 { […] 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 section describes the basic device usage and its DT representation of some I²C devices integrated on our phyBOARD-Polis.

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

&i2c1 { clock-frequency = <400000>; pinctrl-names = “default”; pinctrl-0 = <&pinctrl_i2c1>; status = “okay”; […] }; &iomuxc { 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. imx8mm-phyboard-polis.dtsi):

&i2c2 { clock-frequency = <400000>; pinctrl-names = “default”; pinctrl-0 = <&pinctrl_i2c2>; status = “okay”; }; &iomuxc { 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 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 as the EEPROM is relatively slow.

DT representation, e.g. in phyCORE-i.MX 8M Mini file 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 { […] 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: imx8mm-phycore-som.dtsi:

&i2c1 { […] 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 imx8mm-phyboard-polis.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:

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 imx8mm-phyboard-polis.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 { […] 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 FD

The phyBOARD-Polis is populated with an mcp2518fd SPI to CAN FD chip. The chip is supported with the Linux standard CAN framework which builds upon then the Linux network layer. Using this framework, the CAN interfaces behave like an ordinary Linux network device, with some additional features special to CAN. More information can be found in the Linux Kernel documentation:

https://www.kernel.org/doc/html/latest/networking/can.html

Use:

target$ ip link

to see if the interface is up or down. The given MAC and IP addresses, however, are arbitrary and obsolete.

To get information on can0, such as bit rate and error counters, type:

target$ ip -d -s link show can0

The information for can0 will look like:

2: can0: mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT gro up default qlen 10 link/can promiscuity 0 minmtu 0 maxmtu 0 can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 bitrate 500000 sample-point 0.875 tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1 mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1 mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1 clock 20000000 re-started bus-errors arbit-lost error-warn error-pass bus-off 0 0 0 0 0 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 RX: bytes packets errors dropped overrun mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 0 0 0 0 0 0

The output contains a standard set of parameters also shown for Ethernet interfaces, so not all of these are necessarily relevant for CAN (for example the MAC address). The following output parameters contain useful information:

Field Description can0 Interface Name NOARP CAN cannot use ARP protocol MTU Maximum Transfer Unit RX packets Number of Received Packets TX packets Number of Transmitted Packets RX bytes Number of Received Bytes TX bytes Number of Transmitted Bytes errors… Bus Error Statistics

The CAN configuration is done in the systemd configuration file /lib/systemd/system/can0.service. For a persistent change of (as an example, the default bitrates), change the configuration in the BSP under ./meta-yogurt/recipes-core/systemd/systemd-machine-units/can0.service in the root filesystem and rebuild the root filesystem.
[Unit] Description=can0 interface setup [Service] Type=simple RemainAfterExit=yes ExecStart=/sbin/ip link set can0 up type can bitrate 500000 ExecStop=/sbin/ip link set can0 down [Install] WantedBy=basic.target

The can0.service is started by default after boot. You can start and stop it using:

target$ systemctl stop can0.service target$ systemctl start can0.service

The bitrate can also be changed manually, for example, to make use of the flexible bitrate:

target$ ip link set 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

You can send messages with cansend or receive messages with candump:

target$ cansend can0 123#45.67 target$ candump can0

To generate random CAN traffic for testing purpose, use cangen:

target$ cangen

cansend –help and candump –help provide help messages for further information on options and usage.

Warning The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. Slower rates can be selected but may not work correctly.

Device Tree configuration of imx8mm-phyboard-polis.dtsi:

/{ […] &ecspi1 { #address-cells = <1>; #size-cells = <0>; pinctrl-names = “default”; pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1_cs>; cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; status = “okay”; assigned-clocks = <&clk IMX8MM_CLK_ECSPI1_ROOT>; assigned-clock-rates = <18181819>; can0: can@0 { compatible = “microchip,mcp25xxfd”; reg = <0>; spi-max-frequency = <10000000>; pinctrl-names = “default”; pinctrl-0 = <&pinctrl_can_int>; interrupt-parent = <&gpio1>; interrupts = <8 IRQ_TYPE_LEVEL_LOW>; clocks = <&can_osc_20m>; xceiver-supply = <®_can_en>; }; }; &iomuxc { pinctrl-names = “default”; pinctrl_can_en: can-engrp { fsl,pins = < MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x00 >; }; pinctrl_can_int: can-intgrp { fsl,pins = < MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x00 >; }; pinctrl_ecspi1: ecspi1grp { fsl,pins = < MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK 0x82 MX8MM_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI 0x82 MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO 0x82 >; }; pinctrl_ecspi1_cs: ecspi1csgrp { fsl,pins = < MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x00 >; }; […] }

WLAN

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This module supports 2,4 GHz bandwidth and can be run in several modes, like client mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More information about the module can be found at https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

Enabling WLAN

The firmware should be loaded by the kernel. The country code needs to be set before WIFI can be used. It can be changed under:

target$ vi /lib/firmware/brcm/brcmfmac43430-sdio.txt … ccode= …

More information about how to set up a WIFI connection can be found in Changing the Wireless Network Configuration.

Bluetooth

Bluetooth is connected with UART2 interface. More information about the module can be found at https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. The Bluetooth device needs to be set up manually:

target$ hciconfig hci0 up target$ hciconfig hci0: Type: Primary Bus: UART BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN RX bytes:1392 acl:0 sco:0 events:76 errors:0 TX bytes:1198 acl:0 sco:0 commands:76 errors:0 target$ hciconfig -a hci0: Type: Primary Bus: UART BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN RX bytes:3179 acl:8 sco:0 events:104 errors:0 TX bytes:1599 acl:8 sco:0 commands:85 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: ‘phyboard-polaris-imx8m-2’ Class: 0x200000 Service Classes: Audio Device Class: Miscellaneous, HCI Version: 4.1 (0x7) Revision: 0x60 LMP Version: 4.1 (0x7) Subversion: 0x2209 Manufacturer: Broadcom Corporation (15)

Now you can scan your environment for visible Bluetooth devices. Bluetooth is not visible during a default startup.

target$ hcitool scan Scanning … XX:XX:XX:XX:XX:XX

Visibility

To activate visibility:

target$ hciconfig hciX piscan

To disable visibility:

target$ hciconfig hciX noscan

Change Class Property

target$ hciconfig hci0 class

Connect

target$ bluetoothctl [bluetooth]# discoverable on Changing discoverable on succeeded [bluetooth]# pairable on Changing pairable on succeeded [bluetooth]# agent on Agent registered [bluetooth]# default-agent Default agent request successful [bluetooth]# scan on [NEW] Device XX:XX:XX:XX:XX:XX [bluetooth]# connect XX:XX:XX:XX:XX:XX

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 [email protected]:/lib/firmware

For example, if you try to bring up the network interface:

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 a fall-back on the card itself. In this case, the behavior and output depend strongly on the manufacturer’s firmware.

Video

Videos with Gstreamer

The video is installed by default in the BSP:

target$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm #OR target$ gst-launch-1.0 -v filesrc location= \ ! qtdemux ! h264parse ! queue ! vpudec ! waylandsink async=false enable-last-sample=false \ qos=false sync=false #OR target$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm

kmssink Plugin ID Evaluation

The kmssink plugin needs a connector ID. To get the connector ID, you can use the tool modetest.

target$ modetest -c

The output will show something like:

trying to open device ‘i915’…failed trying to open device ‘amdgpu’…failed trying to open device ‘radeon’…failed trying to open device ‘nouveau’…failed trying to open device ‘vmwgfx’…failed trying to open device ‘omapdrm’…failed trying to open device ‘exynos’…failed trying to open device ’tilcdc’…failed trying to open device ‘msm’…failed trying to open device ‘sti’…failed trying to open device ‘tegra’…failed trying to open device ‘imx-drm’…done Connectors: id encoder status name size (mm) modes encoders 33 32 connected LVDS-1 216×135 1 32 modes: name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) 1280×800 60 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver props: 1 EDID: flags: immutable blob blobs: value: 2 DPMS: flags: enum enums: On=0 Standby=1 Suspend=2 Off=3 value: 0 5 link-status: flags: enum enums: Good=0 Bad=1 value: 0 6 non-desktop: flags: immutable range values: 0 1 value: 0 20 CRTC_ID: flags: object value: 31

Display

The 10″ Display is always active. If the PEB-AV-Connector is not connected, an error message may occur at boot.

With the phytec-qt5demo-image, Weston with the phytec-qt5demo starts during boot. The phytec-qt5demo can be stopped with:

target$ systemctl stop phytec-qtdemo

To start the demo again, run:

target$ systemctl start phytec-qtdemo

To disable autostart of the demo run:

target$ systemctl disable phytec-qtdemo

To enable autostart of the demo, run:

target$ systemctl enable phytec-qtdemo

Weston can be stopped with:

target$ systemctl stop weston

imx8mm-phyboard-polis-peb-av-010.dtsi:

/ { backlight: backlight { compatible = “pwm-backlight”; pinctrl-names = “default”; pinctrl-0 = <&pinctrl_lcd>; default-brightness-level = <6>; pwms = <&pwm4 0 50000>; enable-gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>; brightness-levels= <0 4 8 16 32 64 128 255>; status = “okay”; }; panel: panel { compatible = “edt,etml1010g0dka”; backlight = <&backlight>; status = “okay”; port { panel_in: endpoint { remote-endpoint = <&bridge_out>; }; }; }; }; &pwm4 { status = “okay”; pinctrl-names = “default”; pinctrl-0 = <&pinctrl_pwm4>; }; &sn65dsi83_port0 { bridge_out: endpoint { remote-endpoint = <&panel_in>; }; }; &sn65dsi83_port1 { bridge_in: endpoint { remote-endpoint = <&dsi_out>; }; }; &lcdif { status = “okay”; max-res = <1920>, <1080>; }; &mipi_dsi { status = “okay”; as_bridge; sync-pol = <1>; pwr-delay = <10>; }; &mipi_dsi_ports { port@1 { reg = <1>; dsi_out: endpoint { remote-endpoint = <&bridge_in>; }; }; }; &iomuxc { pinctrl_pwm4: pwm4grp { fsl,pins = < MX8MM_IOMUXC_SAI3_MCLK_PWM4_OUT 0x12 >; }; pinctrl_lcd: lcd0grp { fsl,pins = < MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1 0x12 >; } };

Framebuffer

This driver gains access to displays connected to PHYTEC carrier boards by using an emulated framebuffer device /dev/fb0.

To run a simple test of the framebuffer feature, execute:

fbtest -f /dev/fb0

This will show various test patterns on the display.

Information about the framebuffer’s resolution can be obtained:

fbset

which will return something like:

mode “1280×800-0” # D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz geometry 1280 800 1280 800 32 timings 0 0 0 0 0 0 0 accel true rgba 8/16,8/8,8/0,0/0 endmode

To query the color depth of the framebuffer emulation, type:

target$ cat /sys/class/graphics/fb0/bits_per_pixel

Backlight Control

If a display is connected to the PHYTEC board, you can control its backlight with the Linux kernel sysfs interface. All available backlight devices in the system can be found in the folder /sys/class/backlight. Reading the appropriate files and writing to them allows you to control the backlight.

To get, for example, the maximum brightness level (max_brightness) execute:

target$ cat /sys/class/backlight/backlight/max_brightness

which will result in:

7

Valid brightness values are 0 to .

To obtain the current brightness level, type:

target$ cat /sys/class/backlight/backlight/brightness

you will get for example:

6

Write to the file brightness to change the brightness:

target$ echo 0 > /sys/class/backlight/backlight/brightness

turns the backlight off,

target$ echo 5 > /sys/class/backlight/backlight/brightness

sets the brightness to the third-highest brightness level. For documentation of all files, see https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

Power Management

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

Suspend to RAM

The phyCORE-i.MX8MM supports basic suspend and resume. Different wake-up sources can be used.

Basically, suspend/resume is possible with:

target$ echo mem > /sys/power/state #resume with pressing on/off button

To wakeup with serial console run:

target$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup target$ echo mem > /sys/power/state

Thermal Management

The Linux kernel has integrated thermal management that 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 Wise, Fair Share, Bang 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.

GPIO Fan

A GPIO fan can be connected to the phyBOARD-Polis-i.MX8M Mini. The SoC only contains one temperature sensor which is already used by the thermal frequency scaling. The fan can not be controlled by the kernel. We use lmsensors with hwmon for this instead. lmsensors reads the temperature periodically and enables or disables the fan in a configurable threshold. For the phyBOARD-Polis-i.MX8M Mini this is 60°C.

The settings can be configured in the configuration file:

/etc/fancontrol

Fan control is started by a systemd service during boot. This can be disabled with:

target$ systemctl disable fancontrol

Watchdog

The PHYTEC i.MX8MM modules include a hardware watchdog that is able to reset the board when the system hangs. This section explains how to enable the watchdog in Linux using systemd to check for system hangs and during reboot. By default, the watchdog is enabled in the Linux kernel but disabled in systemd.

Watchdog Support in systemd

Systemd has included hardware watchdog support since version 183.

To activate watchdog support, the file system.conf in /etc/systemd/ has to be adapted by enabling the options:

RuntimeWatchdogSec=60s ShutdownWatchdogSec=10min

RuntimeWatchdogSec defines the timeout value of the watchdog, while ShutdownWatchdogSec defines the timeout when the system is rebooted. For more detailed information about hardware watchdogs under systemd can be found at http://0pointer.de/blog/projects/watchdog.html.

On-Chip OTP Controller (OCOTP_CTRL) – eFuses

The i.MX 8M Mini provides one-time programmable fuses to store information such as the MAC address, boot configuration, and other permanent settings (“On-Chip OTP Controller (OCOTP_CTRL)” in the i.MX 8M Mini Reference Manual). The following list is an abstract from the i.MX 8M Mini Reference Manual and includes some useful registers in the OCOTP_CTRL (at base address 0x30350000):

Name Bank Word Memory offset to 0x30350000 Description OCOTP_MAC_ADDR0 9 0 0x640 contains lower 32 bits of ENET0 MAC address OCOTP_MAC_ADDR1 9 1 0x650 contains upper 16 bits of ENET0 MAC address and the lower 16 bits of ENET1 MAC address OCOTP_MAC_ADDR2 9 2 0x660 contains upper 32 bits of ENET1 MAC address

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and the boot/mac/… configuration are available in the section “Fuse Map” of the i.MX 8M Mini Reference Manual.

Reading Fuse Values in uBoot

You can read the content of a fuse using memory-mapped shadow registers. To calculate the memory address, use the fuse Bank and Word in the following formula:

OCOTP_MAC_ADDR:

bootloader$ fuse read 9 0

Tip The shadow registers hold only values that were fused in. For example, it is not possible to read the current boot configuration from the shadow registers, only if it was fused before. Instead, the current boot configuration can read from the SRC_SBMR1 register.

Burning MAC Address

Warning Fuses can only be written once! You can brick your board easily by burning a wrong boot configuration. It cannot be reversed!

To burn the MAC address, you have to fill the fuse manually. The following sequence shows how to use it. Replace the in the following commands with a valid MAC address from your pool of addresses.

Check values:

bootloader$ fuse read 9 0 Reading bank 9: Word 0x00000000: 00000000 bootloader$ fuse read 9 1 Word 0x00000001: 00000000 bootloader$ fuse read 9 2 Word 0x00000002: 00000000

Finally burn the MAC address:

키워드에 대한 정보 i.mx8m mini reference manual

다음은 Bing에서 i.mx8m mini reference manual 주제에 대한 검색 결과입니다. 필요한 경우 더 읽을 수 있습니다.

이 기사는 인터넷의 다양한 출처에서 편집되었습니다. 이 기사가 유용했기를 바랍니다. 이 기사가 유용하다고 생각되면 공유하십시오. 매우 감사합니다!

사람들이 주제에 대해 자주 검색하는 키워드 Embedded Linux Training (I.MX8M Mini): first steps with Yocto # 1. Building a Yocto Image and SDK

동영상
공유
카메라폰
동영상폰
무료
올리기

Embedded #Linux #Training #(I.MX8M #Mini): #first #steps #with #Yocto ## #1. #Building #a #Yocto #Image #and #SDK

YouTube에서 i.mx8m mini reference manual 주제의 다른 동영상 보기

주제에 대한 기사를 시청해 주셔서 감사합니다 Embedded Linux Training (I.MX8M Mini): first steps with Yocto # 1. Building a Yocto Image and SDK | i.mx8m mini reference manual, 이 기사가 유용하다고 생각되면 공유하십시오, 매우 감사합니다.